Zombies
Stories of zombies originated in the African Caribbean spiritual belief system of Voodoo, which told of the people being controlled as laborers by a powerful wizard.

backups, encryption and some very interesting databases.

Posted: November 18th, 2009 | Author: Matt | Filed under: InfoSec, mac | Tags: , , , | 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…


iPhones and Pooping

Posted: September 25th, 2009 | Author: Matt | Filed under: Brain Dump | Tags: , , | No Comments »

I saw this t-shirt and had to have it. There has been alot of hype and general douchery about the iPhone for a while now and it’s gotten a bit old. I did notice something about having an iPhone, other than having my monthly bill triple in size.

I’ve always been a huge advocate of free software and the Linux way of doing things, but since having a Mac and indeed an iPhone, I have noticed this attitude of mine swing a little the other way. It started with a couple of free downloads of useless applications from the iStore (directly from my phone mind you). Then, after a while I moved on to the 99c applications, mostly because “hey, it’s 99c…that’s nothing” and also because 95% of the free applications are crap. No biggie, we’re still fairly safe..

But lately, I’ve been into the expensive applications. I just spent $13.95 on stuff for the phone. All in one foul swoop, without even leaving my bed. Without even turning my notebook on. And therein lies the problem dear friends. The iPhone may not have changed how I poop, but it has influenced my spending habits. Slightly and over time, without me really thinking about it.
Now, I consider purchasing applications where before I would have spent days searching out a decent open source alternative on Freshmeat and the like.

What’s the point to all this ? Apple is making it very easy to spend money without the need for a web browser or even a physical component like a credit card or better yet, cold hard cash. It’s changing peoples perceptions of what’s safe and “the right thing to do” when purchasing items online. I fear the day when people start sending credit card details over clear text again, simply because the big apple has taught them that’s it’s the norm…


Of iPhones and Wifi

Posted: August 18th, 2009 | Author: Matt | Filed under: Brain Dump, InfoSec | Tags: , , , | 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.