Posted: November 18th, 2009 | Author: Matt | Filed under: InfoSec, mac | Tags: backups, encryption, forensics, iphone | 1 Comment »
Encrypting backups on the iphone is now crucial. The following was taken from my personal phone which
I backup to my local machine sans encryption. As you can see there is a scary amount of personal
data that can be garnered with even the most basic knowledge of forensics. I say forensics in the
loosest terms here as all I really did was play around with a few commands that I always run
when I find files I know nothing about.
Let’s get started..
The backups are located in ~/Library/Application Support/MobileSync/Backup/xxxx… there xxxx…
is the unique identifier for your current mobile device. How this ID is made up I couldn’t
say. It’s not based on the EMEI number or anything like that, although at a glance it does
certainly look like a SHA1 hash of something…
Moving on. In the root directory you will see many, many files, mostly made up of the following
files:
xxxx.mddata
xxxx.mdinfo
These files seems to be SHA1 hashed file names to perhaps mask the original file name, although I
can’t say for sure as I no longer have a jail broken iPhone.
There are also three plist files:
Info.plist
Manifest.plist
Status.plist
We will take a look at these files later on. But first, let’s take a look at those “mddata” and “mdinfo”
files. There is just far too much “noise” coming from them to ignore.
Within my backup directory there are 957 .mddata files and 956 .mdinfo files. Purely out of habit
I ran a simple “file *.mddata” and “file *.mdinfo” on the directory and lo and behold we had something
interesting. Very interesting in fact….
All the .mdinfo files are in fact Apple “binary property list” files (or plist files) [1]. These files seem
to point to data files on the actual phone itself. Running the “strings” command on some of them
gives some pretty interesting (although probably boring in the long run) results [2].
Not really a dead end, but the “.mddata” files are FAR more interesting….
Lots of different files to pick through
—————————————
A quick scan with the “file” command comes up with the following file types for all the 957 samples I have
in my backup directory:
ASCII text
ASCII text, with no line terminators
Apple binary property list
DOS executable (device driver)
GIF image data, version 89a, 596 x 542
HTML document text
JPEG image data, EXIF standard
JPEG image data, EXIF standard 2.21
JPEG image data, JFIF standard 1.01
JPEG image data, JFIF standard 1.01, comment
PDF document, version 1.3
PDF document, version 1.4
PNG image, 310 x 400, 8-bit/color RGBA, non-interlaced
PNG image, 320 x 460, 8-bit/color RGBA, non-interlaced
PNG image, 320 x 480, 8-bit/color RGB, non-interlaced
PNG image, 320 x 480, 8-bit/color RGBA, non-interlaced
PNG image, 480 x 320, 8-bit colormap, non-interlaced
PNG image, 805314566 x 396263525, 0-bit grayscale,
SQLite 3.x database
SQLite 3.x database, user version 3
SQLite 3.x database, user version 327686
XML document text
data
Out of this list, the SQLite databases were probably the most fun. Most of the images in the samples were
from my photos library, either the originals that I took with the iPhones’ camera, images that I had taken
and added to my iPhoto database or they were the thumbnails that the iPhone or iTunes generated for
display.
Databases, it’s always about the databases
——————————————–
Let’s take a look at the SQLite databases. There were 37 different databases on my phone. Going through
each of them manually was a little tiresome but more than that a little scary.
Some of the more “entertaining” things stored in these _unencrypted_ databases include the following:
Calls (incoming, outgoing and missed) [3] [4]
Contact List [5]
SMS messages [6]
Getting the data
—————-
All of this information could be gathered using the built in sqlite3 command and either running
“.dump” or using SQL “select” statements if you wanted a more specific data set.
There is more than enough reason here to encrypt your backups. I don’t really have anything to hide
in terms of state secrets or such like, but the thoughts of having personal information and
messages hanging “out in the wind” like they are in these databases is a very scary though.
But wait, we have forgotten something
————————————-
What about those three .plist files in amongst all those other juicy files ?
Info.plist
———-
The Info.plist file contains a whole bunch of useful information about the phone including:
Device name
IMEI Number
Last Backup Date
Phone Number of the device
Serial Number
Build Version
Calendars
Contact Groups
Itunes Version
As well as a bunch of other references to what look like Base64 encoded files within the XML file.
Lots of useful information here….
Manifect.plist
————–
The Kicker
———–
1password / password hashes….
References:
[1] mdinfo_screenshot_1.png
[2] mdinfo_screenshot_2.png
[3] calls_dump.png
[4] calls_select.png
[5] contacts_dump.png
[6] sms_dump.png
It’s common knowledge that I have an iPhone. I love the damn thing. Even when it bumps my monthly debit orders up to around the R1300 mark. It’s just damn awesome to be in touch 100% of the time. Who I am in touch with I don’t really know…
The following was taken from my personal phone which I backup to my local machine sans encryption. As you can see there is a scary amount of personal data that can be garnered with even the most basic knowledge of forensics. I say forensics in the loosest terms here as all I really did was play around with a few commands that I always run when I find files I know nothing about.
Before we get started, let’s imagine for a second that I am Joe Bloggs in the street with a rudementary knowledge of computers. That basically means I know how to turn it on, “use” iTunes, connect my iPhone and sync that bad boy…I know nothing about encryption save for the fact that “My bank uses it to protect me from evil hackers…”
Let’s get started.
The backups are located in ~/Library/Application Support/MobileSync/Backup/xxxx… where xxxx…is the unique identifier for your current mobile device. How this ID is made up I couldn’t say. It’s not based on the EMEI number or anything like that, although at a glance it does certainly look like a SHA1 hash of something…
Moving on. In the root directory you will see many, many files, mostly made up of the following files:
xxxx.mddata
xxxx.mdinfo
These files seems to be SHA1 hashed file names to perhaps mask the original file name, although I can’t say for sure as I no longer have a jail broken iPhone.
There are also three plist files:
Info.plist
Manifest.plist
Status.plist
We will take a look at these files later on. But first, let’s take a look at those “mddata” and “mdinfo” files. There is just far too much “noise” coming from them to ignore.
Within my backup directory there are 957 .mddata files and 956 .mdinfo files. Purely out of habit I ran a simple “file *.mddata” and “file *.mdinfo” on the directory and lo and behold we had something interesting. Very interesting in fact….
All the .mdinfo files are in fact Apple “binary property list” files (or plist files) . These files seem to point to data files on the actual phone itself. Running the “strings” command on some of them gives some pretty interesting (although probably boring in the long run) results.
Not really a dead end, but the “.mddata” files are FAR more interesting….
Lots of different files to pick through
A quick scan with the “file” command comes up with the following file types for all the 957 samples I have in my backup directory:
ASCII text
ASCII text, with no line terminators
Apple binary property list
DOS executable (device driver)
GIF image data, version 89a, 596 x 542
HTML document text
JPEG image data, EXIF standard
JPEG image data, EXIF standard 2.21
JPEG image data, JFIF standard 1.01
JPEG image data, JFIF standard 1.01, comment
PDF document, version 1.3
PDF document, version 1.4
PNG image, 310 x 400, 8-bit/color RGBA, non-interlaced
PNG image, 320 x 460, 8-bit/color RGBA, non-interlaced
PNG image, 320 x 480, 8-bit/color RGB, non-interlaced
PNG image, 320 x 480, 8-bit/color RGBA, non-interlaced
PNG image, 480 x 320, 8-bit colormap, non-interlaced
PNG image, 805314566 x 396263525, 0-bit grayscale,
SQLite 3.x database
SQLite 3.x database, user version 3
SQLite 3.x database, user version 327686
XML document text
data
Out of this list, the SQLite databases were probably the most fun. Most of the images in the samples were from my photos library, either the originals that I took with the iPhones’ camera, images that I had taken and added to my iPhoto database or they were the thumbnails that the iPhone or iTunes generated for display.
Databases, it’s always about the databases
Let’s take a look at the SQLite databases. There were 37 different databases on my phone. Going through each of them manually was a little tiresome but more than that a little scary.
Some of the more “entertaining” things stored in these _unencrypted_ databases include the following:
Calls (incoming, outgoing and missed)
Contact List
SMS messages
Getting the data
All of this information could be gathered using the built in sqlite3 command and either running ”.dump” or using SQL “select” statements if you wanted a more specific data set.
There is more than enough reason here to encrypt your backups. I don’t really have anything to hide in terms of state secrets or such like, but the thoughts of having personal information and messages hanging “out in the wind” like they are in these databases is a very scary though.
But wait, we have forgotten something
What about those three .plist files in amongst all those other juicy files ?
Before we go into that it’s useful to mention that 90% of the time you can simply read these files with a text editor of some sort or the more common less/most/more option on the CLI. The are simply XML formatted files with all the goodies in there for the world to see.
Info.plist
The Info.plist file contains a whole bunch of useful information about the phone including:
Device name
IMEI Number
Last Backup Date
Phone Number of the device
Serial Number
Build Version
Calendars
Contact Groups
Itunes Version
As well as a bunch of other references to what look like Base64 encoded files within the XML file.
Lots of useful information here.
Manifest.plist
The Manifest.pl file isn’t very interesting at first glance. It is again an XML file with two rather interesting looking keys, namely AuthSignature and AuthVersion. Both of which are base64 encoded files of what looks like garbage, although I am sure on closer inspection they won’t be…If anyone can find me 3 more hours in a day for me to mess around with fun stuff like this, please contact me at godiwishihadmorefreetime@gmail.com
Status.plist
The final “normal” .plist file in the backup root directory is a file called (very imaginatively) Status.plist. It contains a rather cryptic key “Backup Success“. No points for guessing what this file is about.
The Kicker
There is always one kicker isn’t there ? That one little piece of the pie that makes you go “Dammit” or “Oh hell yes” depending on which side of the fence you park your rear…
So I use 1password to store my plethora of passwords that I use for various sites, servers etc. I like it because it works very well and most of all syncs between my MacBook and my iPhone. We know how much we love to sync stuff.
So yes, naturally when I backup my iPhone to my Mac it backups up the current state of my 1password database. It does this into a very neat little SQLite database with my 1password data right there in neat little columns. Ok, so it’s not in plain site, the entries for username and password etc. are hashed, presumably with something like SHA1. I am not a cryptanalyst so at a glance I couldn’t say for certain what the algorithm is. Gun to my head I would say SHA1.
At this point I would like to point out the work being done on SHA1 collisions but I am unable to find anything decent to link to. Perhaps next time…
Posted: August 18th, 2009 | Author: Matt | Filed under: Brain Dump, InfoSec | Tags: endpoint, InfoSec, iphone, Late Night Rambling | 2 Comments »
Alternative Title: If I “rm -fr /” my iPhone, does Steve Jobs kill a kitten ?
Setup.
So I haven’t had a chance to really get “hands on” with this simply because I have zero free time at the moment so bare with me on this one.
We all know at least one annoying person with an Apple iPhone right. I know, I am that annoying person with an iPhone. They really have changed the game entirely when it comes not only to mobile handsets, but also mobile PC’s that can be placed within an environment and used as a device to pivot or maintain your foothold on that network.
Next.
Right, we have our iPhone (or I guess even your iPod touch, but I haven’t played with one of those), it has wireless. It has a nifty little power cable (or at least mine does) that’s pretty small and can be used to power the device from under a desk, in a random closet somewhere nearby or in that cable tray with a stray power box. What does that mean to you and I ? Right now ? Not much. But jailbreak the phone, stick on OpenSSH (or simply enable it in my case) and hey..what’s that ? Metasploit ?? No..surely not. Yes, ladies and gentlemen, you now have Metasploit installed and running from your iPhone. Think about that for a second. Let it really sink in.
Next.
So are you with me so far ? We have a very small device, with fairly decent WiFi capability that has the ability to stay on until such time as it’s found or the attacker decides to come back and pick it up. What can an attacker do with this ? Well, they could run any one (or many) of the built in web browser exploits and just wait. This would allow the attacker to spam anyone within the target business (anyone for a spot of spear whaling ?) and no doubt get at least one machine compromised on the network. How is this useful to the attacker ?
1. We have a remote shell on a compromised machine within the target network.
2. We could now use Meterpreter to maintain access and harvest as much information on that network as is physically possible. Believe me, this is a scary amount of information.
3. With that compromised host and the information gleaned from it, we can now deepen the foothold we have on the organization.
Next.
All of this is very scary. I’ve been experimenting with Metasploit and Meterpreter and I can say that it’s trivial to exploit the older versions of Internet Explorer. That’s one thing, but add to this the post exploitation bliss that is Meterpreter and you have a very nasty combination. The WinEnum script by Dark0perator pulls in so much useful information from the victim machine it becomes even more trivial to start building very comprehensive maps and other useful information on the target network. And the ringer ? Meterpreter runs completely from memory. It’s not going to be detected by Anti-Virus either. Fine, I will see the broken IE process and kill it ! Wrong, simply migrate the Meterpreter process from IE to something a little less suspect with the Migrate script. Beige coloured mold could do this stuff….
Done.
Yes, we’re done. We have an extremely portable device that can be used to leverage a foot hold into a target network and then not only maintain but increase that foothold. What does this mean to security professionals ? It means the attack surface is growing and generally there isn’t anything we can do about it. Why ? Have you ever tried to tell your C-level exec to switch off the WiFi on his handset ? You’re going to have another vector to worry about and it’s going to be the biggest worry of them all.
To sum it all up, end point security is tough. Very tough. But hopefully this post will do one thing (and hopefully it’s not make me look like an insane ranting person) and that’s get the thought processes going on what we can do. What policies and procedures can we implement to at least mitigate these issues ? Can we separate these devices off into their own networks ? Is this even viable in your environment ?
Unfortunately I don’t have any of the answers for this. I probably only have more questions, but to me, that’s what this is about. Asking the right questions to at least get to the answers.