iOS 4 Security Evaluation

This year’s BlackHat USA was the 12th year in a row that I’ve attended and the 6th year in a row that I’ve participated in as a presenter, trainer, and/or co-organizer/host of the Pwnie Awards. And I made this year my busiest yet by delivering four days of training, a presentation, the Pwnie Awards, and participating on a panel. Not only does that mean that I slip into a coma after BlackHat, it also means that I win at conference bingo.

Reading my excuses for the delay in posting my slides and whitepaper, however, is not why you are reading this blog post. It is to find the link to download said slides and whitepaper:

Attacker Math 101

At SOURCE Boston this year, I gave my first conference keynote presentation. I really appreciate the opportunity that Stacy Thayer and the rest of the SOURCE crew gave me. The presentation was filmed by AT&T and you can watch it on the AT&T Tech Channel. Another thanks goes out to Ryan Naraine for inviting me to give an encore presentation of it for Kaspersky’s SAS conference in Malaga, Spain.

If slides are more your style, you can check out the more recent version from Kaspersky’s SAS 2011: Attacker Math 101.

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)

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.

Advanced Mac OS X Rootkits

At BlackHat USA 2009, I presented “Advanced Mac OS X Rootkits” covering a number of Mach-based rootkit techniques and some tools that I have developed to demonstrate them.  While the majority of Mac OS X rootkits employ known and traditional Unix-based rootkit techniques, these Mach-based techniques show what else is possible using the powerful Mach abstractions in Mac OS X.  My presentation covered a number of Mach-based rootkit tools and techniques including user-mode Mach-O bundle injection, Mach RPC proxying, in-kernel RPC server injection/modification, and kernel rootkit detection.

User-mode DLL injection is quite common on Windows-based operating systems and is facilitated by the CreateRemoteThread API function.  The Mach thread and task calls support creating threads in other tasks, however, they are much more low-level.  The inject-bundle tool demonstrates the steps necessary to use injected memory and threads to load a Mach-O bundle into another task.  A number of injectable bundles are included to demonstrate the API (test), capture an image using the iSight camera (iSight), log instant messages from within iChat (iChatSpy), and log SSL traffic sent through the Apple Secure Transport API (SSLSpy).

The majority of Mach kernel services (task and thread system calls, for example) are implemented as RPC services.  The Mach message format was designed to be host-independent, which facilitates transferring them across the network.  Machiavelli demonstrates using Mach RPC proxying in order to transparently perform Mach RPC to a remote host. Machiavellian versions of ps and inject-bundle are included in order to demonstrate how this technique may be used for remote host control by rootkits.

Most of the public kernel rootkits for Mac OS X load as kernel extensions and remove their entries from the kernel’s kmod list in order to hide themselves from kextstat and prevent themselves from being unloaded. The uncloak tool examines the kernel memory regions looking for loaded Mach-O objects.  If any of these objects do not correspond to a known kernel extension, they may be dumped to disk using kernel-macho-dump.

Mach IPC messages to the in-kernel Mach RPC servers are dispatched through the mig_buckets table.  This table stores function pointers to the kernel RPC server routines and is analogous to the Unix systent system call table.  A kernel rootkit may directly modify this table in order to inject new kernel RPC servers or interpose on in-kernel RPC server routines.  The KRPC kernel extension shows how a kernel rootkit may directly modify this table in order to dynamically inject a new in-kernel RPC subsystem.

These tools are deliberately released as ‘non-hostile’
proof-of-concept tools that meant to demonstrate techniques and are
not suitable for use in actual rootkits or attack tools.  The IM and
SSL logging bundles log to the local system’s disk in an obvious
fashion and Machiavelli opens up the controlling host to some obvious
attacks.  The non-Machiavelli version of inject-bundle, however, is
fully functional and useful for a variety of system-level tasks.
Using the other tools outside of a closed network or test virtual
machine is not recommended.

These tools are deliberately released as ‘non-hostile’ proof-of-concept tools that meant to demonstrate techniques and are not suitable for use in actual rootkits or attack tools.  The IM and SSL logging bundles log to the local system’s disk in an obvious fashion and Machiavelli opens up the controlling host to some obvious attacks.  The non-Machiavelli version of inject-bundle, however, is fully functional and useful for a variety of system-level tasks.  Using the other tools outside of a closed network or test virtual machine is not recommended.

Here are the goods:

No More Free Bugs

No More Free Bugs

Alex and I holding "No More Free Bugs" sign during Charlie's Lighting Talk at CanSecWest

A few weeks ago, Charlie Miller, Alex Sotirov, and I arrived on a new meme: No More Free Bugs.  We started talking about it publicly at CanSecWest where Charlie Miller notably announced it for his Lightning Talk and in his ZDNet interview.  It is now making its way through Twitter and the rest of the tubes.  It is understandable that this may be a controversial position, so I’m going to give some more background on the argument here.

First, this is neither advocating non-disclosure nor any disclosure at all.  That decision is left to the discoverer of the vulnerability.  I’m not even going to touch the anti/partial/full disclosure argument.

Second, this philosophy is primarily regarding vulnerabilities in products sold for profit by for profit companies, especially those that already employ security engineers as employees or consultants.  Vulnerabilities discovered in open source projects or Internet infrastructure deservedly require different handling.

The basic argument is as follows:

  • Vulnerabilities place users and customers at risk.  Otherwise, vendors wouldn’t bother to fix them.  Internet malware and worms spread via security vulnerabilities and place home users’ and enterprises’ sensitive data at risk.
  • Vulnerabilities have legitimate value.  Software vendors pay their own employees and consultants to find them and help them fix them in their products during development.  Third-party companies such as Verisign (iDefense) and ZDI will pay researchers for exclusive rights to the vulnerability so that they may responsibly disclose it to the vendor but also share advance information about it to their customers (Verisign/iDefense) or build detection for it into their product (ZDI).  Google is even offering a cash bounty for the best security vulnerability in Native Client.  Donald Knuth personally pays for bugs found in his software and Dan Bernstein paid $1000 personally as a bounty for a vulnerability in djbdns.
  • Reporting vulnerabilities can be legally and professionally risky.  When a researcher discloses the vulnerability to the vendor, there is no “whistle blower” protection and independent security researchers may be unable to legally defend themselves.  You may get threatened, sued, or even thrown in jail.  A number of security researchers have had their employers pressured by vendors to whom they were responsibly disclosing security vulnerabilities.  Vendors expect security researchers to follow responsible disclosure guidelines when they volunteer vulnerabilities, but they are under no such pressure to follow responsible guidelines in their actions towards security researchers.  Where are the vendors’ security research amnesty agreements?
  • It is unfair to paying customers.  Professional bug hunting is a specialized and expensive business.  Software vendors that “freeload” on the security research community place their customers at risk by not putting forth resources to discover vulnerabilities in and fix their products.

Therefore, reporting vulnerabilities for free without any legal agreements in place is risky volunteer work.  There are a number of legitimate alternatives to the risky proposition of volunteering free vulnerabilities and I have already mentioned a few (I don’t want to turn this into an advertisement or discussion on the best/proper way to monetize security research).   There just need to be more legal and transparent options for monetizing security research.  This would provide a fair market value for a researcher’s findings and incentivize more researchers to find and report vulnerabilities to these organizations.  All of this would help make security research a more widespread and legitimate profession.  In the meantime, I’m not complaining about its current cachet and allure.


Get every new post delivered to your Inbox.

Join 43 other followers