In the AV industry, one of the golden rules is to make sure that, during analysis, we do not in any way help the malware authors and/or propagate their offspring.

This requires special care in the case of malware for mobile phones, because, on the one hand, many of them won’t run if the phone is offline, but on the other hand, if the phone is online, the malware is free to call or send SMS messages in the wild without any way to block those actions. So, we thought building our own local GSM operator, using a USRP coupled with a Linux box running OpenBTS and Asterisk.

USRP connected to OpenBTS in our lab

Actually, this is what I presented at Virus Bulletin Conference [paper] [slides], in Barcelona, a few weeks ago. If you missed it, I also showed a video comparing how much we see when analyzing a Symbian sample of Zitmo on an offline phone and the same sample when the phone is registered to our OpenBTS-based jail. Without OpenBTS, there are quite a few details we could have missed, such as the use of UCS2 encoding for SMS messages…

– the Crypto Girl

The file, located in /private/var/root/Library/Caches/locationd/consolidated.db, is easily accessible on jailbroken phones (ssh or any file transfer tool) and readable by any SQLite3 tool.

This issue has recently re-surfaced as two researchers, Pete Warden and Alasdair Allan, wrote a MacOS tool to generate maps from the locations recorded in that database, and are presenting this at Where 2.0 in San Francisco today.

If you don’t have a Mac, then there is an online tool here (in French) or you can use Firefox4 SQLiteManager plugin + Google Fusion to do the trick (which is actually the solution I used for the maps below).

I would also encourage you read Mikko Hypponen’s post. It offers an interesting explanation as to why Apple designed such a database. In short, Hypponen’s idea is that it reduces the costs of renting an external location database.

The few things I would like to add to the story are:

• the consolidated.db is a ‘standard’ SQLite3 database, so you can query it like any SQLite database, there is no need for sophisticated tools (but they are cool). Data is directly usable:

  sqlite> .dump CellLocation
  PRAGMA foreign_keys=OFF;
  BEGIN TRANSACTION;
  CREATE TABLE CellLocation (MCC INTEGER, MNC INTEGER,
  LAC INTEGER, CI INTEGER, Timestamp FLOAT,
  Latitude FLOAT, Longitude FLOAT, HorizontalAccuracy FLOAT,
  Altitude FLOAT, VerticalAccuracy FLOAT, Speed FLOAT, Course FLOAT,
  Confidence INTEGER, PRIMARY KEY (MCC, MNC, LAC, CI));
  INSERT INTO "CellLocation" VALUES(208,10,49802,21036492,314034125.866114,
  43.60604608,7.06016272,1211.0,0.0,-1.0,-1.0,-1.0,70);
  ...

• The WifiLocation table tries to make up your location based on the wifi access points your iPhone sees, and for which Apple knows the location. If your iPhone sees a wifi access point known to be located by the Eiffel Tower, well, you probably are located close to the Eiffel Tower. This is done without using GPS.
• The CellLocation table does basically the same, but based on the GSM access points your phone sees.

  Now, in my case, I noticed neither table mentioned I had gone to Poland with the iPhone. Why ? Well, obviously, when you restore an old image of your phone, you overwrite the database :) By the way, the iPhone also made a poor estimation of my altitude and thinks I work at sea level (which is not the case).

• Comparing the cell location with the wifi location (see maps below) may release interesting information. First of all, it shows that Apple does successfully associate our workplace wifi with its physical location (I believe the several locations in Sophia Antipolis – where we are located – are just various approximations). It also shows that our lab iPhone (well, the backup I restored) only accessed wifi from our office , that we did a trip to Toulon, but that we did not use wifi there.
  

  CellLocation

  WifiLocation

• On a security point of view, it should be noted [thanks Guillaume for raising the point] that consolidated.db’s integrity is not guaranteed at all. It is easy to modify it to say I was in Greenland last month. Or I could hack into someone’s else iPhone and alter it so as to show that this person was on a crime scene when the crime happened. Thus, this should be handled carefully by forensics experts.
• The ‘untrackerd‘ application cleans the database regularly.
• Finally, you might have noted the iPhone stores the MCC (Mobile Country Code) and MNC (Mobile Network Code) of the SIM. It is interesting to note it did notice I sometimes use a fake SIM (208/30). This is when I use a local OpenBTS replication jail I will talk about at VB 2011 – patience :) In that case, it is unable to locate my position as it is not aware of this fake operator (as it is only valid within the walls of our lab) :)

  INSERT INTO "CellLocation" VALUES(208,30,1000,10,314034365.532726,
  0.0,0.0,-1.0,0.0,-1.0,-1.0,-1.0,0);

There is no official definition of what a smartphone is compared to a feature phone. Steve Litchfield already mentioned the fact in an interesting article and lists several definitions:

• a phone that can be extended with hundreds of add-on applications
• a phone with a proper OS
• a phone with more advanced abilities than a feature phone
• a phone with a keyboard
• a phone with a big touchscreen
• a phone that is always connected
• etc…

By the way, note all those definitions are vague: what is a ‘proper’ OS? what size must the touchscreen be? etc.

Companies running statistics often use their own definitions. For example,  AdMob “considers a smartphone to run an identifiable Operating System, a feature phone to be mobile phone that does not fit into the smartphone category, and a mobile Internet device to be a handheld device that connects to the mobile Internet but is not a phone” .  Nielsen Wire seems to have several definitions: “cellphones with app-based, web-enabled operating systems” or “run full operating systems” or “allow users to access the web and email as well as run thousands of apps and share text and picture messages“. I wish I could find a clear list of smartphones vs feature phones.

Geographic distribution of smartphone OS is uneven, so what makes an accurate title in one country may be absolutely wrong in another. For example, Symbian accounts for only 2% of smartphones in the US in Q2 2010 (source: Nielsen Wire), but 52% of subscribers in Germany in July 2010 (source: ComScore).
In addition, geography is full of surprises: in November 2010, Gfk’s reports lead to news titles such as ‘Android overtakes Symbian in Asia’, but a close look to the report shows this so-called Asia does not include China, nor India, nor Japan ?!

Studies take their figures from different sources: market sales, mobile subscriptions, mail / email surveys, website hits, ads etc. Actually, all those sources make sense, but caution is required because they taint results. For example, AdMob measure the number of ads mobile phone request and/or click on. Fine, why not. But I have seen several iPhone applications with the AdMob footer banner, but far less on Symbian. So, if this is true, there will obviously be more hits for iPhones than Symbian on AdMob servers. Another example: market sales are a good indication for the favorite OS, but how does this relate to mobile phones people actually own? Statistics of Nielsen Wire show Android ranks first for the US Q3 2010 sales (32%) but only third (19%) for owners during the same period. But are sales to retailers taken int account? do old-timers use their phones as much as new buyers or is their phone stored in a cupboard? are new phones all immediately activated?

Reality is always complicated.

– the Crypto Girl

]]> http://blog.fortinet.com/security-landscape-do-it-yourself-crimeware-botnet-kits/feed/ 0 http://blog.fortinet.com/you-cant-judge-a-book-by-its-cover/ http://blog.fortinet.com/you-cant-judge-a-book-by-its-cover/#comments Tue, 07 Sep 2010 15:49:33 +0000 Axelle http://blog.fortinet.com/?p=1545 Last week, a lady from the sales department dropped in to see me for some help with her iPhone. She was worried because she had “suddenly” lost all of her contacts, music and emails. She had turned to a neighbor of hers, an “expert” who had told her she had “a Trojan on her iPhone”.

Whaow. A Trojan on an iPhone: that was definitely very interesting, as I know of none yet. I know a worm (Eeki) and a couple of spyware (Trapsms, MobileSpy) or other questionable software, but no real Trojan.

But, I’m sure you’ve guessed I am being slightly sarcastic and, of course, there was no Trojan at all on her iPhone (which is, altogether, good news anyway). Indeed, it turned out that she had had problems syncing with two different computers and had accidentally erased all her data. Now, I do sympathize because, personally, I have so many difficulties understanding how to use iTunes myself…

Reciprocally, I recall a while ago I scanned my dad’s USB key, although he told me it was certainly virus free because he was “very cautious”. That time, I was right to be suspicious, I had hardly started scanning it that the AV software started blinking in excitement, having found three different samples…

My point here is that end users obviously have difficulties identifying whether they are infected or not: the lady told me her iPhone was infected though it was not, and my dad told me he wasn’t although he was…

If you are in the same case, I would like to help you out with a very simple statement:

if you notice any damage (hard/ soft/) on your phone (or computer), it is unlikely to be infected

(but of course, there might be a hardware or a software failure – which is different).

On the other hand, if you start noticing problems on your bank account, then, be alarmed

(check with your kids or spouse first ;)).

Of course, this is not a 100% guarantee; a few mobile malware do actually cause malfunction, but it’s a general idea to keep in mind: nowadays, malware authors try to make money (or silently grab private data they re-use later), not to misconfigure your phone. Why would they? This would only cause you to notice it’s infected and possibly perform a hardware reset, thereby depriving the malware authors or cybercriminals from a source of revenue.

The graph below shows the number of mobile malware families per threat category. Note there hasn’t been any new annoyware (i.e malware whose main goal is to annoy/cause malfunction) created since 2008. New mobile malware try to make money, or target your privacy, much like desktop computer malware.

– the Crypto Girl

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 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)

Consequently, most people remind/advise iPhone owners to customize root’s password or not to jailbreak their iPhone. This is correct, but it is nonetheless worth adding that:

• all passwords should be customized: for instance, change the password of the mobile account too (i.e. the default user account).
• never use a default password whether it is ‘alpine’ or anything else. iPhones with old firmwares (older than 1.1) use default password ‘dottie’. True, they are not vulnerable to the worms we encountered, but the modification would be so basic…
• do not use simple passwords. This is true for PCs, it is true for iPhones too. It would be easy to modify the worms to brute force passwords. Incidentally, that’s how Sophos found iPhoneOS/Eeki.B changes the password to ‘ohshit’. By the way, thanks to Scott McIntyre (xs4all) for sharing his sample with us.

With this in mind, I reached over for our lab’s iPhone and placed myself in the situation of a typical iPhone owner trying to secure his device. I turned the iPhone on, disabled wifi, connected the iPhone to a lab’s PC via USB and set up a SSH tunnel (I like iUSB Tunnel, because it’s simple).

At this stage, either the iPhone hasn’t been compromised and login succeeds with default password (alpine): please jump to “Changing passwords” below, or it has been compromised and root’s password consequently changed: then, logging in with the default password will fail.

In that case, I would probably recommend you completely re-install the iPhone, because one never knows what the intruder did to the phone. Remember he/she had root access to the device, he/she could do anything.

For now, let’s suppose you decide just to change the passwords, inspect the iPhone and re-install later.

To customize a password, the current one is required. If you know the password (‘alpine’ by default, ‘ohshit’ if compromised), then no problem, change the password (jump to ‘changing passwords’). If you don’t know what the old password is, the easiest solution consists in editing /etc/master.passwd with a text editor that runs as root. For instance, install iFile (eu.heinelt.ifile), browse to the /etc directory and open master.passwd for edition.

Temporarily reset root’s password to ‘alpine’ (default):

root:/smx7MYTQIi2M:0:0::0:0:System Administrator:/var/root:/bin/sh

Sidenote. I find it quite dangerous such text editors run with root privileges!

Then, login as root using password alpine and change it. See below.

Changing passwords

As a side note, I realized that picking up a nice (and secure) password was quite difficult on mobile phones, because even if the iPhone’s virtual keyboard is handy, you usually don’t feel like entering a long and complicated password (e.g. special characters are not immediately accessible on the virtual keyboard). iPhone developers, we’d certainly love to have a thumbprint authentication application, or an application where the password is a few secret gestures on the touchscreen, perhaps like a handwritten signature (but a secret one). Those gestures could translate into a long and complicated key we would not generally need to enter.

Once I changed passwords, it occurred to me that, anyway, any login attempts should be logged. I searched /var/log and /var/logs but couldn’t find any log concerning SSH. So, I opened the SSH daemon configuration file (/etc/ssh/sshd_config) and uncommented those lines:

#SyslogFacility AUTH
#LogLevel INFO

Restarted the SSH daemon, and re-logged in: still no logs ! Yes, actually, the iPhone ships with no syslog daemon ! So, I downloaded and installed a syslog daemon (com.) and configured /etc/syslog.conf:

*.*;auth.info /var/log/syslog

After restarting syslog and ssh, this time I finally get my logs in /var/log/syslog:

Nov 24 14:29:15 iPhone-de-axelle sshd[6270]: Failed password for mobile from 127.0.0.1 port 56304 ssh2
Nov 24 14:29:18 iPhone-de-axelle sshd[6270]: Accepted password for mobile from 127.0.0.1 port 56304 ssh2

Actually, logs are rather useful before one gets compromised, to see the failed login attempts, because once an intruder has successfully logged in as root, he/she can stop the syslog daemon or erase /var/log/syslog…

Finally, I ought to point out allowing root login via SSH is usually considered as insecure. Disable it in /etc/ssh/sshd_config (check out other security options) :

PermitRootLogin no

– The Crypto Girl (with her iPhone)

Mobile phones are just the perfect platform for spying because they are portable (iPhones are such beauties one hates to leave them behind!) and seen as private devices (would you share your nice iPhone, huh?). Depending on functionalities, mobile spyware record and forward incoming and outgoing SMS, MMS, voice calls, geographic location etc.

Recently, I finally laid my hands on an iPhone spyware sample. Actually, it has probably been out for a while, but I was surprised to discover nobody seemed to detect it yet. The spyware installs on any jailbroken iPhone. In Cydia (an iPhone front-end to help installing third-party applications), you first add the URL of the spyware’s repository and then install the two spyware packages:

SmsTrapUI: a user interface package to assist the spy into installing the spyware. Once the spyware is configured, the spy can erase this package:

Std: the spyware daemon. It installs in /usr/sbin and does not display any new icon on the iPhone’s springboard. This daemon collects information on SMS (phone number, text, timestamp and incoming/outgoing indicator) and sends it to a SQL database of the spyware’s website.

Okay, so the spyware installs and works. As an antivirus analyst, my next task then consisted in getting original samples onto my work host (the host where I work out detections for malware). I could have connected onto the iPhone via SSH iPhone Tunnel Suite, but then I would have had to parse all directories the packages had installed files into, and retrieve them. I settled for a simpler solution: Cydia uses Debian-style repositories, so I directly downloaded the samples from there. Debian-style repositories typically include two files:

Release and Packages (or Packages.bz2). So, I first downloaded Release:
$ wget http://xxxxx/x/Release
$ cat Release
Origin: ST
Label: ST
Suite: stable
Version: 1.0
Codename: st
Architectures: iphoneos-arm
Components: main
Description: ST Main repository
248bf63c4e179ef82d4fe4ba86a42c03 547 main/binary-iphoneos-arm/Packages
3b6d6f28d5346f9d911a067fccb64f5f 335 main/binary-iphoneos-arm/Packages.bz2

The Release file mentions both Packages and Packages.bz2 exist, so I then downloaded Packages:
$ wget http://xxxxx/x/Packages
$ cat Packages
MD5Sum: 762bf733c5a9b03b787c23ffc64d63a7
Maintainer: ST Team
Description: ST Daemon.
Package: com.st.std
Section: Utilities
Author: ST Team
Filename: ./std-1.1-1_iphoneos-arm.deb
Version: 1.1-1
Architecture: iphoneos-arm
Size: 11634
Name: STD

MD5Sum: bed10acddc436a5dfdb77a35dc6e74ad
Maintainer: ST Team
Description: SmsTrap User Interface
Package: com.st.SmsTrapUI
Section: Utilities
Author: ST Team
Filename: ./SmsTrapUI-1.1-1_iphoneos-arm.deb
Depends: com.st.std, quickload
Version: 1.1-1
Architecture: iphoneos-arm
Size: 26184
Name: SmsTrap

The Packages file provides the name of the 2 packages:
$ wget http://xxxxx/x/SmsTrapUI-1.1-1_iphoneos-arm.deb
$ wget http://xxxxx/x/std-1.1-1_iphoneos-arm.deb

I can now unpack the .deb packages, and detect the relevant parts of the spyware.

To summarize our discussion, tomorrow, MobileMe is releasing three novelties:

• locating your iPhone, for example, when it is lost
• displaying a message or a sound onto your iPhone
• remotely wiping your iPhone so a thief won’t find read any sensitive data

All of these are quite appealling at first, but they raise a few questions:

Security: which security measures are taken to make sure one cannot remotely wipe or send messages/sounds to another iPhone? I hope this is secure, otherwise attackers are going to have a lot of fun…

Price: all of these features require sending commands to the iPhone. How is the mobile device receiving commands? Are they sent over the 3G network? Is the phone receiving an SMS? And who’s paying for this? Is it included in your MobileMe subscription?

Eficiency: those features are probably helpful if you lose your iPhone, but I doubt they will help when your iPhone is stolen. From MobileMe’s screenshot, it looks like locating an iPhone only works if you have previously installed MobileMe and enabled the “Find my iPhone” option. The thief can probably disable this option, uninstall MobileMe or even reset your iPhone if he/she intends to keep it…

Privacy: I am uncertain of how legal tracking your iPhone is. In France, geolocalization is regulated by law and the CNIL has hard work enforcing it. To my understanding, the CNIL finds locating a stolen device acceptable as long as the feature cannot be turned into a spying / tracking device. And indeed, this is difficult to guarantee: you never know when your iPhone is going to be stolen, do you? So, you have to enable the localization all the time, and consequently, your iPhone (thus you?) can be tracked all the time too… unless Apple has thought of some special trick so your iPhone will only release localization data to you, its rightful owner.

We’re going to be busy after tomorrow…