2010
02.25

Phishing, $bank and the South African Connection..

We all know about it to some degree or other. If my mother, who fears computers with her life, can give me a vague idea about why these “nasty hackers” are trying to steal our money then we, as a security community, must be doing something right. Unfortunately, where phishing is concerned, that seems to be where it ends. But more on that later. This entry is an attempt to give a little more information on phishing attacks. It is based entirely on my experiences online and has very little scientific or black magic behind it. If I’ve gone wrong somewhere, please feel free to call me out on it…

The Setup

So, you receive an email in your inbox claiming to be from the Security/Anti-Fraud/Accounts division of $bank and most of the time the contents will be fairly alarming. Alarming enough that you will want to login via their provided link to update your details/reactivate your account/check for missing money. At first glance the emails look legitimate. The sender address looks correct. It’s only once you dig through the email headers that you’ll find that the sender isn’t really $bank but rather $compromised_server. Thankfully we have had it drilled into our heads by security people at work and by $bank officials that they will never ask for things like your PIN/account number etc. Or so we hope. With the prevalence of these attacks, it seems that this particular attack vector is still very much a bread winner.

But wait…how do these sites come into existance ?

This is where I am going to make the grave mistake of “assuming”. I don’t think I’m far wrong, but you never know.

So the emails you receive in your inbox contain links to $bank. But if you check the actual URL you’ll see that it actually links you to somethng like http://www.mysitesbeenhacked.com/content/images/$bank/login.html The actual landing page will look quite close to the real thing depending on how good the phishers are. The images will all be in the right place, only because they are directly linked from the original site. Sometimes these images are broken for whatever reason which should be give away #3413. Your first give away should be the URL. It’s not $banks URL and more importantly it’s not HTTPS. Which is why bookmarking the login page for your $bank of choice is probably a good thing…

I  realise none of this explains how these pages get there in the first place. You will have to excuse me. Through $attack_vector_x attackers will upload a phishing kit to a compromised server and extract and set it up for use. How these sites are compromised is anyones guess. It could start from somehthing as simple as a remote file include which is then escalated to either a basic shell or even worse, complete root compromise. Regardless of the exact vector, the phishing kit has now been uploaded, extracted and the site is now live. From here the phishing emails are sent out with links to this siteN. Now it’s simply a game of waiting to see what comes through…

Hook, line and sinker…

We’re going to take the bait on one of these emails. Most of the time, you’ll click on a link and your web browser will tell you that the site is a web forgery or some such big, red warning sign ‘o doom. However, let’s just pretend for a second that the site works. You will land on a page that looks exactly like $bank login and for all intents and purposes it is – except for one little line of code that’s been added. From the kits I’ve seen, the line will look something like this:

<form name=”theForm” method=”POST” action=”logon1.php”…>

This should be a dead give away. Posting to a php file ? On a site that doesn’t use PHP ?  But what gets posted ? Information about the server the kit is hosted on and some other miscellaneous information, but most importantly, the information you just entered into the account number and PIN fields of their login page. Depending on the login process of $bank there will be another step to grab the OTP or other out of band authentication token, but this too is simply a POST to a php page. All of this information is then neatly dumped and mailed out to an email address on the web somewhere. I didn’t see any preference for webmail service nor did I see any address more than once. What this says about the phishers, I’ll leave up to you.

It’s a very simple process. Take an existing site framework, modify the code slightly to get the users information back to you and you’re A for away. I would really like to know how much this still works. I think the $bank fraternity in South Africa has done a really good job with user education on phishing. The fact that my mother can spot a phishing email says alot. The down side ? There is still a very scary amount of phishing going on. This says that there are still people who fall prey or that the phishers don’t really care and are just carpet bombing email address space with their hooks.

SARS + Bank = Phishing double whammy


I’ve noticed lately that there has been an increase in the SARS/Bank phish here in South Africa. The email goes that SARS is going to give you money back (heaven forbid) and that you now need to login to your bank for reason X. The link takes you to a rather fancy looking SARS page with links to $banks. You can thne pick which bank you wish to log into. Process X then applies and your details are emailed out as described above. My question is, are these kits locally made ? Or is there a group out there who caters for all banks and you just pay them for specifics ? Either way, $banks have their work cut out for them to keep on top of this lot…

And there inlies the problem. As with things like IDS, Anti-Virus etc. combating phishing is very reactive. You’ll get the phish email, go to $site and try and get it removed. That can be very idifficult when 9 times of of 10, the site is not hosted in South Africa. Yes, things like OpenDNS and $browser checks do help, but at the end of the day, neither solution is ideal. There are groups of people doing what they can to assist and speed up the process, but with the prevalence of vectors like SQL injection still being used heavily, I feel we may be fighting a losing battle.

2009
12.07

There has been a few posts of late with various “10 things” topics being thrown around. Most of the topics I pay attention to are of the “geek” variety even though there are many things I would consider myself, a geek not appearing in that list. But that’s a story for another day. What I am really trying to get at is my stab at the top ten “things to be thankful for in Information Security”. I haven’t seen one of these out yet so I thought I’d add my 0.02c worth..

So without any further ado.

the TOP 10 THINGS TO BE THANKFUL FOR IN INFORMATION SECURITY

(list not in order, i’m not that dumb)

nmap

Let’s be honest. We’re not supposed to tie ourselves down to one as was very well pointed out by Carlos Perez but let’s just be honest here. Nmap is the defacto standard for not just network sweeping, port scanning and banner grabbing but with the Nmap Scripting Engine there are so many more options available.

twitter

No, I’m not talking about the spate of Britney pwnage or that cat with more followers that Britney. I’m talking about getting near real time information about the latest and greatest from many sources around the globe. Just make sure your pooh filters are enabled as the signal/noise ratio is very dependent on the mood of the “Tweeple” (I loathe that word).

scripting language X

Do you think I’d be stupid enough to go down the python/lua/perl/ruby road ? But no matter what your poison, rest assured that the scripting language makes mince meat of those tedious tasks we do daily. But mostly you should all use Python because it rocks :)

s/vmware\ fusion/your vm_app\ of\ choice

I’ve gone the Vmware Fusion route simply because it out performs Parallels. At the end of the day it’s fantastic to be able to fire up an operating system and mess around with code/malcode/scripts knowing that if something goes horribly wrong you’re just a “Revert to Snapshot” away from being back in happy land.

scapy

Ok so I could have lumped this into “scripting language X” but that would be silly. When you need to create a custom packet or 10 (thousand) Scapy is your man (or woman). It’s easy to use and more versatile than that girl in Vegas that one time after Jeopardy…er..

rss

What better way is there to consolidate the many many news sources out there into a easy to sift through, organised chaos. “Knowledge is power (But only if you know how to acquire it).”

books

Yes, good, old school, murdering the trees books. I am sorry but I cannot for the life of me read a PDF of a 600+ page book on my PC. I have read more since starting my Information Security career than I have in my entire life. The difference between now and High School is that the topic is interesting and holds my attention more than the teacher with the low cut blouse..

the 15″ macbook pro

Ok so this is more for me personally than anything else. It seems that most of the people I know in Information Security have a shiny Apple under their arm. I’m lucky enough to have a 13″ MacBook Pro and I have to be honest and say that I can never go back to a normal PC. Just a pity about the price tag….

podcasts

Another tricky one. Yes this could have been put in with RSS feeds as a source of news but more of the podcasts I listen to are more than just a simple news feed. So Pauldotcom, ExoticLiability, Eurotrash Security, Network Security Blog, Securabit, Security Justice and DiscussIT thank you for doing what you do….

the human race

Without Joe Bloggs, Bob, Auntie Sue, Jeff from down the road or that guy that clicks on EVERYTHING, we would not have a job. No users doing dumb things (just getting through the day mostly) would mean no security holes for us tinker with..So, this last one is for you (who clicks links without checking), and you  (who writes “code” that’s secure and validated) and most of all you (who doesn’t bother to learn anything other than the blue E is for internet)

2009
11.26

start part 1/3

#include disclaimer.h

I am by no means an expert at this sort of thing. Nor am I very good at it. This post is just about what I found today and some of the steps I took in my investigation of the problem. If you see where I have gone wrong or spot a mistake, please let me know. It’s the only way I learn.

background


Someone was doing some research on a famous designer named Dieter Rams. In particular there was a blue hair dryer that caught said someones eye. This is mostly because his search terms brought the hair dryer to the number one result in Google Image Search. So wanting to know more about the hair dryer the user clicked on the image. It went steadily downhill from there.

javascript


The image result to him to a blog post which has the photo, along with some hidden javascript in the page source which looked a little like so:

Embedded Javascript

Embedded Javascript

Unfortunately that little piece of the puzzle seems to be completely missing as it’s since been removed from the site. I am also a little confused as to how it got there in the first place. It wasn’t in a comment, nor was it an upload. My only thought is that it’s an existing link to a site which has since been compromised and is hosting malicious javascript…

the scan.

The first time I followed the link to the “Blue Hair Dryer of Doom” ™ I was redirected to pcmedicalbilling.com which then proceeded to tell me my machine was infected and needed to be scanned. I believe the redirection was handled by the above Javascript but without having the original source it’s hard to say. The scary thing about this is that I checked with Google and F-Secure and both said the link was good. It was only toward the end of the day that it finally got marked as malicious.

So upon loading the page you will get presented with a neat little warning claiming shenanigans afoot on your PC. I love the fact that my browser now knows when my PC is infected with malware. Great work Safari !

Warning !

Warning !

This will then kick off into a “scan” of your machine where it will find enough infections of various flavours to warrant you downloading something to deal with the problem.

Scanning your machine for infection

Scanning your machine for infection

Here you can see your machine is truly infected and in desparate need of some software assisted cleansing.

Oh noes!!! I'm infected....

Oh no..I'm infected....

And what do you know ? They have just the application to help you out with this…

Help is on the way

Help is on the way

Looking at the “scan” results page you can see how easily it would dupe Joe Bloggs. It’s pretty convincing. What bothers me most about this incident is that while the search terms may have been fairly specific to the user, who’s to say that this doesn’t happen much more often. There was no dodgy links being followed, no search for pornography, just a guy trying to do research for his job…

so we have an executable


We now have an executable downloaded to our machine. I haven’t had the time to reverse engineer it yet. Mostly because I haven’t had the chance to learn reverse engineering of PE files. Yet. There was a lot more code involved here. Some very interesting javascript which was fairly obfuscated. I will be posting about this once I have had the time to sit down and analyze the code. Look out for the follow up in the next couple of days…

end of part 1/3

2009
11.18
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…

2009
10.31

zaCon

SO, zaCon is coming.

It’s a conference without all the fluff and hubub of commercial vendors. It’s being put on by people who live, eat, breathe and sometimes poop information security. It’s going to give people who wouldn’t usually have this platform to talk about new cool stuff they might be working on. New tools, new ideas, just about anything that’s going keeps us up at night.

There isn’t going to be any corporate sponsorship. It’s going to be very ad-hoc and probably very chaotic, but that’s a good thing. Nothing like this has happened in South Africa before (as far as I am aware).

So keep an eye on the website. The speaker list is up and running. The venue has been locked down and it’s happening.

If you have any questions, comments or general ideas, please feel free to contact people@zacon.org.za

But mostly, come along. It’s going to be alot of fun.