by RSS Axelle Apvrille  |  Aug 05, 2010  |  Filed in: Security Research

Unless you're on a trek in the Himalayas, by now you've probably heard one way or another that the infamous "Jailbreakme" website is back to free iPhones (including iPhones 4 running iOS 4.0.1) and iPads : it's just everywhere on the web, even with videos and tutorials.

However, fewer resources address the technical aspect of jailbreaking. You might have found out that the online jailbreaking tool is resorting to a drive-by-script exploiting a 0-day vulnerability. We'll try and provide a few other technical findings below.

First, let's connect to the site with a proper user-agent (i.e. iPhone's Safari). It gives us a nice Javascript, whose interesting part is:

function get_page(){return model==null?null:("/_/"+model+"_"+firmware+".pdf"}

That is to say, the user is automatically redirected to a malicious pdf based on the model of the device and the firmware version.

As directory listing is enabled, we were able to list all the files in the corresponding repository:

pdflist

The file "iPhone3,1_4.0.pdf", for instance, features an encoded PDF Type1C font (Compressed Font Format) stream that looked suspicious enough for us to decode it (thanks to the excellent pdf-parser tool from Didier Stevens). In the now clear-text stream, we could identify at least one manifest (offset 0xbcd - see below) and an iOS executable (offset 0x1109, we will get back to it later on).

xml-manifest

Note the large values for IOSurfaceBytesPerRow, IOSurfacePixelFormat, IOSurfaceHeight and IOSurfaceWidth in the manifest above.

The corresponding system API framework is basically not documented, but we can easily guess there is an allocation issue in an IOSurface object. As IOSurface objects run in kernel space, the process can bypass usual security restrictions.

It is highly likely this 0-day exploit can be used for other means than jailbreaking an iPhone/ iPod/ iPad. Consequently, Will Strafach wrote an iPhone application that detects suspicious PDFs and warns end-users when they are at risk.

As for the binary in the decoded PDF stream, essentially, it pilots the jailbreaking. The executable starts by checking it can access /bin/bash or not via a BrowserController object (see figure below): if bash is accessible, it concludes the device is already jailbroken and recommends not to jailbreak it again. Otherwise, it considers the device is not jailbroken:

BrowserAccess-cut

If the device is not jailbroken, the executable then downloads hxxp://jailbreakme.modmyi.com/wad.bin into a buffer of type NSMutableData, named wad (itself member of a class the author called "Dude"). Before going any further, the executable checks that the downloaded version of the file wad.bin starts with the four bytes 0x42424242 ('BBBB'), then followed by its length.

The wad.bin file is exactly 3909273-byte long, i.e 0x3BA699. This length is stored in bytes 4, 5, 6 and 7:

$ hexdump -C wad.bin | head
00000000  42 42 42 42 99 a6 3b 00  15 b5 01 00 78 9c ec 7d  |BBBB..;.....x..}|
00000010  0d 9c 54 c5 95 ef bd dd  3d 43 33 34 70 81 46 87  |..T.....=C34p.F.|

This pattern may be used in the frame of counter-measures (eg: Snort signatures, etc...), to prevent jailbreaking from one's network, for some reasons. Additionally, it is worth noting a cookie keeps information regarding the jailbreaking attempts (date and time of access to jailbreakme.com, PDF file downloaded etc).

At this point, parts of the buffered wad.bin are dumped in inflated format on the device in /tmp/install.dylib. The dynamic library is then opened, and the do_install symbol is called. This is likely where the actual jailbreaking occurs.

Afterwards, the remaining XZ compressed data contained in wad.bin is then uncompressed, which can be reproduced manually (credits to Gecko_UK):

$ dd if=./wad.bin skip=111905 of=./wad.xz bs=1 count=3797368
$ 7zr x wad.xz
$ mv wad wad.tar
$ tar xvf wad.tar
...2009-04-27 16:34 Applications/
...2009-04-27 16:34 Applications/Cydia.app/
...2010-07-30 10:55 Applications/Cydia.app/commercial.png
...2010-08-01 20:52 Applications/Cydia.app/Modes/
...2009-08-09 11:55 Applications/Cydia.app/Modes/REMOVE.png
...2009-08-09 11:55 Applications/Cydia.app/Modes/INSTALL.png
...2010-08-01 20:52 Applications/Cydia.app/Modes/NEW_INSTALL.png -> INSTALL.png
...

And the jailbroken environment (Cydia applications, etc...) is installed on the device.

-- the Crypto Girl (Axelle Apvrille) and the Vulnerability Guy (David Maciejak)

by RSS Axelle Apvrille  |  Aug 05, 2010  |  Filed in: Security Research

comments powered by Disqus