Upcoming Events in 2011

I’m going to start out 2011 pretty busy on the information security events circuit.  Here are some of the events that I’ll be participating in over the first few months in 2011:

So there you have it: a workshop, a presentation, a round-table, a panel, a training, and a keynote on both coasts of North America and both sides of the Atlantic.  I win at conference bingo!  I’m pretty excited about giving my first ever conference keynote presentation at SOURCE.  I’ll be giving a food-for-thought type of presentation, not the technical sort that I’m used to.  However, just to keep things interesting, I might randomly drop some 0day in the middle of the presentation anyway.

Hacking at Mach 2!

At BayThreat last month, I gave an updated (and more much sober) version of my “Hacking at Mach Speed” presentation from SummerC0n.  Now, since the 0day Mach RPC privilege de-escalation vulnerability has been fixed, I can include full details on it.  The presentation is meant to give a walkthrough on how to identify and enumerate Mach RPC interfaces in bootstrap servers on Mac OS X.  Why would you want to do this?  Hint: there are other uses for these types of vulnerabilities besides gaining increased privileges on single-user Mac desktops.  Enjoy!

  • “Hacking at Mach 2!” (PDF)

Memory Corruption, Exploitation, and You

At the NY/NJ OWASP meeting last week, I gave an experimental high-level (i.e. not really technical) talk that I call “Memory Corruption, Exploitation, and You.” The talk is essentially a few rants stapled together, all relating to exploits, but also trying to predict where attackers in the wild will be headed in the next couple of years. One of the points that I tried to make (and will be trying to make in upcoming talks as well) is that the threat environment has changed from what I call “getting hacked by accident” (non-targeted mass malware attacks) to an increased prevalence and awareness of targeted attacks in the wild, often using 0day vulns/exploits and custom malware. Responding to this requires changing several aspects of our mindset about network defense and vulnerability handling.

I gave an earlier version of the talk at BSidesSF (video here) and here are the updated slides that I gave at OWASP.

KARMA Demo on the CBS Early Show

Although I haven’t done any development on KARMA for a little over 5 years at this point, many of the weaknesses that it demonstrates are still very present, especially with the proliferation of open 802.11 Hotspots in public places. A few weeks ago, I was invited to help prepare a demo of KARMA for CBS News and the segment actually aired a few weeks ago. If you’re like me and don’t have one of those old-fashioned tele-ma-vision boxes, you can check out the segment here.

Unfortunately, they weren’t able to use the full demo that I prepared. The full demo used a KARMA promiscuous access point to lure clients onto my rogue wireless network with a rogue network’s gateway routed outbound HTTP traffic through a transparent proxy that injected IFRAMEs in each HTML page. The IFRAMEs loaded my own custom “Aurora” exploit, which injected Metasploit’s Meterpreter into the running web browser. From there, I could use the Meterpreter to sniff keystrokes as they logged into their SSL-protected bank/e-mail/whatever. The point was that even if a victim only uses the open Wi-Fi network to log into the captive portal webpage, that’s enough for a nearby attacker to exploit their web browser and maintain control over their system going forward. Perhaps that was a little too complicated for a news segment that the average American watches over breakfast.

As it has been quite a while since I have talked about KARMA, here are a few updates on the weaknesses that it demonstrated:

  • Windows XP SP2 systems with 802.11b-only wireless cards would “park” the cards when the user is not associated to a wireless network by assigning them a 32-character random desired SSID. Even if the user had no networks in their Preferred Networks List, the laptop would associate to a KARMA Promiscuous Access Point and activate the network stack while the GUI would still show the user as not currently associated to any network. This issue was an artifact of 802.11b-only card firmwares (PrismII and Orinoco were affected) and is not present on most 802.11g cards, which is what everyone has these days anyway.
  • Even with a newer card, Windows XP SP2 will broadcast the contents of its Preferred Networks List in Probe Request frames every 60 seconds until it joins a network. Revealing the contents of the PNL allows an attacker to create a network with that name or use a promiscuous access point to lure the client onto their rogue network. Windows Vista and XP SP3 fixed this behavior.
  • Mac OS X had the same two behaviors, except that Apple’s AirPort driver would enable WEP on the wireless card when it had “parked” it. However, the WEP key was a static 40-bit key (0x0102030405 if I recall). Apple issued a security update in July 2005 and credited me for reporting the issue.
  • On 10/17/2006, Microsoft released a hotfix to fix both of the previous issues on Windows XP SP2 systems that Shane Macaulay and I had discovered and presented at various security conferences over the previous two years.
  • Newer versions of Windows (XP SP3, Vista, 7) are only affected if the user manually selects to join the rogue wireless network or the rogue network beacons an SSID in the user’s Preferred Networks List.

Although the leading desktop operating systems found on most laptops have addressed the issue, most mobile phones now support 802.11 Wi-Fi, which may give KARMA a chance to live again!

BlackHat USA 2010

BlackHat is going to be a busy one for me this year because I am still trying to quit my nasty over-committing habit. But hopefully, I should have something that interests just about everybody.

If you love/hate Macs and like hacking, you should check out the Mac Hacking Class training that I am giving with Vincenzo Iozzo. We’ll be covering a lot of material including discovering and exploiting vulnerabilities, Mac OS X and Mach internals, and writing exploit payloads.

If Windows is more your style, you should check out my presentation, Return-Oriented Exploitation. I’ll be talking about using a variety of return-oriented techniques to bypass DEP/NX and ASLR on modern Windows operating systems, using my exploit for the “Operation Aurora” Internet Explorer vulnerability as an example and live demo. My presentation will be on Thursday at 1:45pm in the Exploitation Track (Augustus 1-2).

Finally, if you don’t really care about Macs or Windows, but do love security vulnerabilities and/or the infosec drama circus (b/c who really cares about the actual work we do?), you should check out the Pwnie Awards. For the 4th year in a row, Alex Sotirov and I have organized the Pwnie Awards to celebrate the achievements and failures of the information security industry. Along with our fellow esteemed judges (Dave Aitel, Mark Dowd, Halvar Flake, Dave Goldsmith, and HD Moore), we will be hosting the Pwnie Awards at 6:00pm on Wednesday, July 28th or July 29th (there seems to be some confusion on exactly which day it’ll be on and where currently). Follow the Pwnie Awards on Twitter for late-breaking updates.

Mac OS X Return-Oriented Exploitation

In The Mac Hacker’s Handbook and a few Mac-related presentations last year, I described my return-oriented exploitation technique for Mac OS X Leopard (10.5) for x86. This technique involved returning into the setjmp() function within dyld (the Mac OS X dynamic linker, which is loaded at a static location) to write out the values of controlled registers to a chosen location in writable and executable memory. By subsequently returning into that location, a few bytes of chosen x86 instructions could be executed. Performing this sequence twice will allow the attacker to execute enough chosen instructions to copy their traditional machine code payload into executable memory and execute it. In Snow Leopard (10.6), Apple has removed setjmp() from dyld, so I had to go back to the drawing board.

For my talk at REcon this year, Mac OS X Return-Oriented Exploitation, I applied my recent research in return-oriented programming and exploitation to Mac OS X to develop a few techniques against Snow Leopard x86 (32-bit) processes. I also talk about why attackers don’t really have to care about 64-bit x86_64 processes on Snow Leopard just yet. If you missed REcon this year (and why would you ever allow that to happen?!), you can download my slides here: Mac OS X Return-Oriented Exploitation.

Hacking at Mach Speed!

The first ever NYC SummerCon last weekend was a blast and everyone seemed to have a great time. As promised, there was 0day at the conference and hopefully no one remembered it because they were too drunk. Here are the slides for my presentation, (they are really no substitute for the live SummerCon experience). This presentation was a mix of some technical background on local Mach RPC on Mac OS X, a bug I found the day before the conference, and some miscellaneous rants from my presentation at BSidesSF.

It was awesome bringing the conference up to NYC and I had a great time opening up for Dr. Raid’s “Busticating DEP” presentation/freestyle busticati rap.

Practical Return-Oriented Programming

At a number of conferences this spring, I am presenting “Practical Return-Oriented Programming.” The talk is about taking the academic and applying it in the real world to developing exploits for Windows that bypass Permanent DEP using my BISC (Borrowed Instructions Synthetic Computer) library.  In the talk, I demonstrate exploitation of the Internet Explorer “Operation Aurora” vulnerability on Windows 7.  These techniques are not at all new, only my implementation is, and it owes much to previous research by Sebastian Krahmer’s “Borrowed Code Chunks” technique , Hovav Shacham’s Return-Oriented Programming, and Pablo Sole’s DEPLIB.

Assured Exploitation Training

This year, Alex Sotirov and I will be teaching our first “Assured Exploitation” training class at CanSecWest.  This training class is focused on various topics in advanced exploitation of memory corruption vulnerabilities.  This includes a thorough understanding of exploitation mitigations (where they are effective and where they aren’t), heap manipulation, return-oriented programming, and ensuring a clean continuation of process execution so that the application does not crash.

Over the course of the training, the hands-on exercises will be oriented around taking the students through the steps of fully understanding the “Aurora” Internet Explorer vulnerability and developing their own reliable and robust exploit for Internet Explorer 8 on Windows 7, just like the exploit demonstrated in this video demo of my exploit:

One Exploit Should Not Ruin Your Day

Now that the media excitement of the aftermath of Operation Aurora has calmed down and we are all soothing ourselves to sleep by the sound of promptly applying Windows Updates, it is a good time to take a look back and try and figure out what the changing threat landscape means for real-world information security (besides Selling! More! Security! Products!) and what lessons can be learned from it.

First off, the threat landscape has not changed at all, only the perception of it.  If you have done or been around any high-level incident response, you would know that these advanced persistent threats have been going on in various sectors for years.  Nor is it a new development that the attackers used an 0day client-side exploit along with targeted social engineering as their initial access vector.  What is brand new is the fact that a number of large companies have voluntarily gone public with the fact that they were victims to a targeted attack.  And this is the most important lesson: targeted attacks do exist and happen to a number of industries besides the usual ones like credit card processors and e-commerce shops.

For the last decade of the information security industry, almost all of the products and solutions have been designed to stop casual opportunistic attackers and mass Internet-scale attacks.  Moreover, these products are absolutely worthless in protecting you from an Aurora-style attack.  Your software vendor doesn’t have a patch for the vulnerability, your anti-virus and/or network intrusion prevention systems don’t have signatures for the exploit or agent it installs, and the 3rd-party software that your business needs to run prevents you from upgrading your desktops to the latest and greatest operating system and/or browser with the most complete exploit mitigations due to a lack of compatibility.  How many of these large security product vendors employ even one full-time person to play the role of a dedicated attacker attempting to bypass or defeat their defensive systems?  Or have even hired one attack-oriented consultant on a contract for an independent assessment of the efficacy of their product or solution?  Don’t let the same product vendors who failed to protect the victims of Operation Aurora turn right around and sell you those same products as a solution to “the APT threat.”

Second, Operation Aurora has no bearing on the vulnerability disclosure debate.  This particular vulnerability was apparently reported to Microsoft in August and scheduled to be patched in February.  Some are arguing that had this vulnerability been reported via full-disclosure to everyone all at once, it would not have been used in these attacks.  They are right.  The reality, however, is that another vulnerability would have been used instead.  These attacks show that the vulnerability disclosure debate and responsible disclosure process is simply a distraction that prevents us from actually improving security.  Remember, a vulnerability never owned anyone — an exploit did.  I am not arguing that vulnerabilities should not be fixed, simply that it is impossible to find and fix every security vulnerability so we should not let that obsession monopolize our efforts and prevent us from implementing more secure application and network designs.

Finally, the larger problem is that it only took one exploit to compromise these organizations.  One exploit should never ruin your day.  Isn’t that why we build DMZ networks with firewalls in front and behind them?  The point of doing that is so that it requires more than one server-side exploit to get into your organization.  Thanks to rich Internet client applications, it now only requires one client-side exploit to get into your organization.  Ideally, it should require around three or four: a remote code execution exploit, a sandbox escape or integrity level escalation exploit, and finally a local privilege escalation exploit in order to be able to install and hide a remote access backdoor on the system.  Also, workstations that receive e-mail and instant messages from strangers, visit random web sites, and download/install whatever software from the Internet should probably not be on the same network as something like your lawful intercept system.

Take this time to review which exploit mitigations such as DEP and ASLR are enabled in your web browser based on your operating system, browser release, and web plugins.  Take ‘/NoExecute=AlwaysOn’ for a spin in your boot.ini and see what (if anything) breaks.  Use this opportunity to get buy-in for placing users’ Internet-enabled workstations onto DMZ-like subnets where you can closely monitor data going in and out.  Give developers remote desktop access to VMs on a separate development network for working on your products (they will be happy as long as you give the VMs more RAM than their workstations so their builds are quicker).  Give everyone access to an external Wi-Fi network to use with their personal Internet-enabled devices.  Get started implementing some internal network segmentation.  Never let a good crisis go to waste.


Get every new post delivered to your Inbox.

Join 3,915 other followers