Heres how we do that voodoo that we do (iPhone Hacking)

The Internet was buzzing a few weeks ago with Charlie Miller’s iPhone SMS exploit. Reading the vague details available in different news stories it reminded me of some work I had done many months ago that involved a USRP, OpenBTS, and several different phones. The results were pretty spectacular for the same reason Wifi fuzzing found tons of problems: when a developer assumes that there is strict control over both ends of a transaction they don’t do as much error checking as they should. After all, since it's only your code (or other code from friendly people) sending data, then the code receiving data doesn't have to check input.

LORCON helped disprove that idea with Wifi. The USRP+OpenBTS combo is doing the same for GSM based handsets.

The crinkly bits is that to find bugs with OpenBTS, you have to trick a cellphone into connecting your hostile base-station rather than a commercial cellphone tower. This is why I found Charlie Miller's and Collin Mulliner's research interesting: they claim they discovered a way to inject SMS locally for testing that wouldn’t be seen by your provider, making fuzz testing easier. I have seen local SMS injection exploits before but never for the iPhone, so I thought i’d spend a day poking around and see what I could come up with. The rest of the blog post is an accounting of how I spent the time searching for this vuln, how I duplicated a vuln that fits their description, and what to do next.

The first thing I needed was an iPhone. I have one I use everyday, but I'm afraid of bricking it. Instead I dug up an old first-gen iPhone. I assumed that executing the fuzzing code mentioned in the abstract would require jailbreaking the phone since it seems impossible to accomplish that task within the iPhone SDK. I was delightfully surprised to find that using redsn0w made jailbreaking the 3.0 firmware a snap. I installed some basic apps I thought I would need, including the iPhone toolchain (you can compile code directly on the iPhone), ruby, OpenSSH, and the mobile terminal. After looking through the Cydia repository I saw there were some apps that allowed for the sending and receiving of SMS messages. These seemed to be a great place to start. The first example I found is called "aSMS", which has a Google Code project: http://code.google.com/p/iphone-sms/

The aSMS app is a bit odd, the front-end is in the browser, and the backend is a built-in webserver on the iPhone. I spent a few minutes going through the source and found it used what appears to be a baseband debug trick to send messages. The word "baseband" is one way of referring to the separate CPU and operating-system that runs the cellular radio. "Baseband hacking" is were do things like unlocking a mobile phone so it can run on any carrier, and enable features a carrier doesn't want you to use (like tethering or MMS). More specifically the trick uses the device /dev/tty.debug. Googling for "tty.debug" and iPhone led me to another Google Code site and a tool called sendmodem: http://code.google.com/p/iphone-elite/downloads/list

Sendmodem came with a makefile, a .c source file, and a compiled binary. As a side note: this is the best possible situation for a person like myself. If I can’t find the answers I want in the source I can reverse the binary to look at additional items that get added at build time. If that doesn’t yield the answers I am looking for, I can compile my own version and debug it. Something I found funny was the note of the sendmodem wiki that states this code come from the aSMS app I started out with. The wiki also sent me here (http://www.developershome.com/sms/howToSendSMSFromPC.asp) which provided information on how to send a SMS using AT commands and a cellular modem. And finally the wiki provided me a list of undocumented AT commands (http://code.google.com/p/iphone-elite/wiki/UndocumentedATcommands)

With all this information, I started poking around my iPhone. The first thing I wanted to do is see if all the information I had been reading about was still around in the newest v3.0 OS my test phone is running. Nothing would be worse than spending hours on an assumption only to find that the feature you need was removed a few revisions ago. The first thing I tried was using the tty.debug trick to send a text message. I wrote a small ruby script for that:



It worked. I then tried to send a test message to my own number. I figured this could be the simplest way to achieve the functionality for fuzzing. However, this didn't work so well. Every time I sent a text message to the same number it originated from the baseband would disconnect and no longer receive text messages until the device get a reboot.

After a little over two hours into this exercise, I had a lot of information but a lot more epic fail. I'm the king of Thomas Edison's quote of "I have not failed, I've just found 10,000 ways that won't work". Feeling the path I was on was fruitless, I tried another direction: I looked through the filesystem for anything called "sms". Although I got a lot of hits, but the most interesting thing is "sms.db" in "/private/var/mobile/Library/SMS". Using the "file" command I discovered the database is a SQLite3 database. Since that is a fairly well documented database, and there are tons of tools to view the contents, I copied it off the phone and to my MacBook. The used "SQLite Manager", a Firefox plugin which can be found here: https://addons.mozilla.org/en-US/firefox/addon/5817


The sms.db overview and structure as seen in SQLite Manager.


The result of the SQL query "SELECT * FROM message"

After examining the different tables and data it seems that this is where SMS messages are stored to be later retrieved for viewing and such. Using this as a ending point I can work my way backwards to where the messages come from.

Next I enabled syslog debugging, so I can information while sending a SMS message to the device, this should help identify processes that are involved in receiving and processing messages.

The last message in the log reads "CommCenter[30]: removing received message 2147483653".

CommCenter is involved in receiving and processing SMS messages to some degree. Searching the disk for CommCenter gives a lot of results but one catches my eye: /private/var/CommCenter/spool. The word "spool" looks similar to the Unix "mailspool", and is likely the place to store files that are being sent or received by the device. The spool directory has two subdirectories MobileOrginated and MobileTerminated. Both directories were empty, but if the Unix style spool architecture is being used, temp files will be created as messages are sent and received and removed when no longer needed. I wrote a quick and dirty Ruby script that will monitor the directory and copy any files it finds, even if they live for only a second.


Simple Ruby script to check and see if Directory is empty, if not copy the contents to /tmp/

I then run the script and send a SMS to the target phone. I get the expected output that a file has been created and moved to /tmp. The file is named r.sms.2147483652


The contents of the /private/var/CommCenter/spool/MobileTerminated direcotry.

Examining the contents its pretty easy to see that this is the incoming message I sent from another from. I ha the phone number that the message was sent from, the message, and some unprintable characters. I then copied this file off the iphone to my macbook and used hexdump to view the message to see what the unprintable characters are.


The text message in hexdump.

Doing the same for the MobileOriginated directory got a file called p.sms.58. The structure seems almost the same with the destination phone number and the message surrounded by a few unprintable characters. The message I sent was "What up Homey!"


The p.sms.58 message in hexdump.

I now know an intermediary point in the SMS delivery process. I attempted to create my own file in the MobileTerminated directory to see if it would be delivered as an SMS message, but no luck. Something is copying the files there then notifying CommCenter there are messages to be processed. The next step was to analyze the CommCenter binary and find any clues on how it operates and where the signal to process messages comes from.

I created a tar file of the iPhone filesystem with the command "tar czvf /tmp/fs.tgz /" and let it run. Although this is not the most efficient way to do this (a copy of the tar file is going to end up in the tar file) is it pretty fast. I then used WinSCP to copy the file down to a VMWare Fusion image of Windows XP running on my Macbook. My Windows image has most of my reverse engineering tools, including IDA Pro and HexWorksop. It also has the Windows version of Ruby installed because Ruby is pretty useful for reverse engineering binaries. The fs.tgz file is unzipped with WinRAR and the search for CommCenter begins. CommCenter is located in /System/Library/PrivateFrameworks/CoreTelephony.framework/Support

I loaded the file, selected the CPU (ARM), and configured my analyze options. Although IDA Pro is the best tool for this type of work it sometimes doesn't get everything, so I had to go through the disassembled code and fix a few things. The problems were pretty forward and easily fixed. An example problem was this:


This will become more readable like this:


After a few minutes of analysis it seems clear that the baseband module receives the message, and then CommCenter reads it using an AT command. At this point we can break testing into two different parts: CommCenter and MobileSMS.

CommCenter Testing: Fuzz From SMS.db to MobileSMS UI

MobileSMS is the application that handles reading the files from the database and displaying them. Testing MobileSMS is as simple as writing malformed messages to sms.db and then running the SMS application. Well, it would be simple if it wasn't for the database triggers. Trying just to insert a message ends with an error. The is answer is to delete the triggers then recreate them. Here is how to do it in SQL. This statment can be entered into the SQLite Manager:

drop trigger insert_unread_message;
drop trigger mark_message_unread;
drop trigger mark_message_read;
drop trigger delete_message;
CREATE TRIGGER insert_unread_message AFTER INSERT ON message WHEN NOT new.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = new.group_id) + 1 WHERE ROWID = new.group_id; END;
CREATE TRIGGER mark_message_unread AFTER UPDATE ON message WHEN old.flags = 2 AND NOT new.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = new.group_id) + 1 WHERE ROWID = new.group_id; END;
CREATE TRIGGER mark_message_read AFTER UPDATE ON message WHEN NOT old.flags = 2 AND new.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = new.group_id) - 1 WHERE ROWID = new.group_id; END;
CREATE TRIGGER delete_message AFTER DELETE ON message WHEN NOT old.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = old.group_id) - 1 WHERE ROWID = old.group_id; END;

Once that is done a simple insert statement should work:
INSERT INTO "main"."message" ("ROWID","address","date","text","flags","replace","svc_center","group_id","association_id","height","UIFlags","version","subject","country","headers","recipients","read") VALUES ('4','111111111111111111111111111111111111111111111111111111111111111','999999999999999','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','38','0',NULL,'3','0','0','9882987','0','hjdfbvljhvbzjldhvbjlvbjdbvjhdbvjhdvhjdg','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','0')

You can figure out the columns and what value they are expecting from looking at the table description. To understand what they mean I found a URL in the SendSMS code that explains SMS fields and formatting: http://www.dreamfabric.com/sms/. This information is useful if you want to make a fuzzer more accurate and directed. One problem is that the information does not exactly match up with he database format so it requires some experimentation to find out what each field means. The results follow:

Field Name	Input expected	Description
ROWID	INT	The datbase row, used as a key
address	Text	The phone number in the From field
date	INT	The time the message was recieved in Unix time
text	Text	The message body
flags	INT	Show if a message was sent or received. 2 is for sent and 3 is for received
replace	INT	Shows is a message is replacing a current message, like is a newer version is received.
svc_center	Text
group_id	INT	Used by the SMS UI to group messages. If this is set to a id that is not also in the msg_group table, the message will not be displayed.
association_id	INT
height	INT
UIFlags	INT	If sent to 1 the UI will act as if a URL is present.
version	INT
subject	Text
country	Text	Country Code. The United States is set to us
headers	Blob
recipients	Blob
read	INT	Shows if message has been read or not. 0 means it is unread, 1 means it has been read

This information was collected by a trial an error process of sending and receiving messages then duplicating them with different options. If that didn't work I took the SMS message apart and traced it through CommCenter to its insertion in the database. If the field is still blank I can't find anywhere it is actually used and may be used for MMS which I do not have enabled because I am on ATT. Below are some pics of my trial and error process.


The SQLite view of the test messages.


What the testing actually looks like on the iPhone. You might notice the red exclmation points next to the final two messages. This means the SMS was unable to send and it may happen after mucking arounf witht he database enough. Luckily you can just delete the database, kill -HUP the Springboard process, then restart the MobileSMS application. This will recreate a virgin database for you. The failed messages look like this in syslog:

Jul 23 18:24:49 daveTestIphone2g MobileSMS[85]: no URLs for message: Incoming test
Jul 23 18:25:07 daveTestIphone2g com.apple.SpringBoard[26]: told to send sms 18
Jul 23 18:25:07 daveTestIphone2g CommCenter[30]: queuing sms message with id 18
Jul 23 18:25:16 daveTestIphone2g com.apple.SpringBoard[26]: internalID: [18]
Jul 23 18:25:16 daveTestIphone2g com.apple.SpringBoard[26]: notifying clients of event: 3 (recordID: 18)
Jul 23 18:25:16 daveTestIphone2g SpringBoard[26]: send error: < 0x2483d0="">
Jul 23 18:25:16 daveTestIphone2g MobileSMS[85]: send error: < 0x191ad0="">
Jul 23 18:25:16 daveTestIphone2g MobileSMS[85]: _SMSMessageSendError

As far as a fuzzer actually goes using Ruby and the SQLite gem means that a fuzzer could be whipped up in a few minutes. Knowing the field input types and the rules around what gets processed vs what doesn't helps speed this process along. A simple script will just open the database, insert several rows, close the database the kill -HUP the SpringBoard process. The HUP seems to help the UI close then reopen the database and process your new messages.

Things to try involve long strings, unusually high numbers, and setting values that aren't normally set. Below is an example of a crash received after processing a database full of fuzzed messages. The offsets have been removed so we are not accused of releasing 0-day, how ever if you follow the above steps it is pretty easy to duplicate.



CommCenter: Fuzz From Baseband to SMS.db

Back to testing the code that recieves the message and puts it in SMS.db. Looking back at the sendsms tool it seems the best way is through the use of "/dev/tty.debug". Since the sendsms command to my own address doesn't work lets look at other ways to do it. http://rednaxela.net/pdu.php helps you by allowing you to put put in a SMS PDU and it will tell you what it means or you can create your own. A sample SMS PDU is needed. Using minicom on the iphone I connect to the baseband and issue a few commands that give me a binary SMS PDU.

I need my SMSC number and since it is not stored in the SMS.db file typing a debug code on the keypad will show you. I type *#5005*7672# Here is what it looks like:


Next I went back to the Rednaxela site and build a test mesage:


Taking a tour of CommCenter in IDA I trace some code from the function that begins processing spooled messages in MobileTerminated, the the trigger for it.

The function that process SMS messages:


And the command that beings the processing is +CMT:


Starting Minicom I sent the message and play around with various AT commands.


It seems that sending a message with AT+CMGS=length of message produces the desired result. Creation of a test message is easy and it reads "Testing Local Testing". After hitting CTRL-Z after pasting in the PDU I got this on the phone:


Referring back to the website earlier that describes a SMS PDU and all the different options allows for quick fuzzer creation. You can write a small Ruby script to take your fuzzzer output and write it to /dev/tty.debug and monitor the results. This path finds as many bug as the other and they should be tracked down and verified.

In Closing

This paper shows the extent that researchers can follow breadcrumbs to reproduce a work. That's the risk of partial disclosure: a simple description, such as "SMS crash on an iPhone" can give researchers enough hints to reproduce the work.

I haven't figured how how to successfully exploit the crashes I've found. The SMS network only allow 160 characters through their networks. It might take a multistage process (send many SMS messages with shellcode, then a final message that overflows a buffer to run it). Or, it might be something simple to overwrite a few bytes to unlock a phone.

Why isn't Satan invited to Oreilly conferences?

Since we are talking about Ruby vulnerabilities, Blackhat, and other such things, I thought I would take this as an opportunity to respond to something I have read lately over on Oreilly Radar. In a post entitled “Satan on my friends list” a blogger named Jim Stogdill draws a comparison between Oreilly conferences and Blackhat with a quip that he “can't recall Satan making a single appearance in an O'Reilly conference program.”

Now let me start by saying I am a huge Oreilly fan. Almost every time I need to learn something new I grab the Oreilly book on the subject and in recent months I have found that Safari is indispensable as I have been navigating the world of C#, ASP.NET, and Windows Form Development. I even have Oreilly Radar as a subscription on my Kindle, which is how I read this post the first time.

My first reaction is to blast him with something like “The real difference between Oreilly Conferences and Blackhat is that nobody I know who speaks at Blackhat would try to write a post like that." I waited though. I let the topic roll around in my mind. I even read the Blackhat response to it.

I love Blackhat, I have spoken at many of them. I love the people that run the show, and I love the attendees. I have made lifelong friends while attending the shows but most importantly, I have learned as much from audience members as I much as I have taught.

I know how hard it is for speakers to write good presentations. With so many tracks, so little time, most conference attendees have a few minutes to pick the next talk to attend and will often go with the best sounding title. If you look at a few of my presentation titles:

Device Drivers – Don’t Build a House on a Shaky Foundation
Trust No-one, Not Even you self OR the weak link might be your build tools
Data Seepage: How to Give Attackers a Roadmap to Your Network
NX: How Well Does It Say NO to Attacker’s eXecution Attempts?
SCADA Security and Terrorism: We're Not Crying Wolf!

They all seem sensationalist but you have 30 seconds to grab someone’s attention and convince them you are worthy of 50 minutes of their time. Could you imagine college is students could choose any class they like and professors were judged on not just course content but how they are rated by students and how many people attend? Professors would have class titles like “Intro to Physics: The study on bodies in motion” or “Calculus: a primer for understanding and making money stock market” or “18th Century Romantic Literature: how to read porn without looking like a pervert”.

The part that irks me the most about Jim’s blog entry is the last paragraph where he summarizes the Blackhat spectacle with the standard fare of tattooed people, brief thrills, low moral values, and every security researcher just waiting for a big payday to switch sides and become evil.

I wonder if this is how he really sees Blackhat and other such conferences. While Defcon does attack a wide range of Geeks, it seems that Blackhat is far more kosher for the business crowd. You have the vendors with their snazzy little booths, you have every facet of Enterprise security represented from the make it happen engineers to the long pontificating strategy based CTOs. The keynotes are always interesting and the lineup is mostly relevant to people working in the trenches today. I remember the first Blackhat I ever attended, I saw Dan Kaminsky speak about his Paketto Keiretsu tools that included scanrand, a high speed portscanner. I was working at a large university at the time and immediately implanted this tool as a way to scan 3 and a half class B networks for open ports we are interested in. Using this we could easily track down malware that listened on a port as soon as possible. It would take less than 10 minutes to do as opposed to several hours with nmap (note: I am not knocking nmap, it’s a great tool).

In my last post, I mentioned that although the current Ruby vulnerabilities are new, I first saw material covering flaws in interpreted languages, Ruby to be specific, at Blackhat Tokyo in 2005. Although even my, and the original man in blue Mr. Johnny Cache, Apple Macbook hack presentation was controversial and hashed rehashed into the ground the result was that a number of flaws in wireless drivers are closed. Some of these were as simple as setting the SSID of a wifi beacon packet to greater than 100 bytes.

As far as every “white hat” just waiting for a payday to make a switch, I find that personally insulting, I think it is insulting to the largest group of creative and intelligent people I have ever been a part of (the Blackhat speaker alumni). The people who speak at Blackhat go from poor college kids (Johnny was in college when we presented in 2006) to former presidential advisors like Richard A. Clarke. This group of people is dedicated to combating security problems and providing the good guys ammo in the continuing arms race that is security. I, like many other security professionals, have received unsolicited offers for to purchase 0day, to write worms, or even requests to help crack a girlfriends gmail account. None of these offers are entertained let alone offer any temptation.

Blackhat has a long and distinguished history of getting information into the hands of people that can make use of it and actually doing something about it. So in response to Jim’ post I offer this thought: maybe it is time for Satan make an appearance at an Oreilly conference.

Ruby vulns: its been 3 years in the making

After a busy weekend, I come back to the magic of RSS to find multiple security holes in Ruby. I had heard about this last week but could not find any details. It seems that more information comes in the form of an Apple Security team member, Drew Yao, who made the discoveries. You can read more about it at Matasano or from ruby-lang.

These finds are very cool and I have always been interested in bugs in interpreted languages mostly because people think they are a “more secure” standard by some folks because they think the memory corruption angle is no longer an issues.

The first time I saw anybody publicly talk about this problem and a potential attack was Blackhat Tokyo by Dom Brezinski. Actually when I say “I saw the talk” I mean I was sitting next to him in the speaker room discussing the problem afterward because I was giving a talk opposite of him on how to break security tools. The previous statement is to head off the trolls who will undoubtedly comment about my lack of actually seeing the talk because I was scheduled at the same time.

Apple info...and thats all folks...

I will answer a couple of popular questions about my presentation. Other than this I feel Jon and I have proved we found vulnerabilities and attempted to work with Apple. This is now a dead subject for me. The presentation and code samples should be up on both our site (erratasec.com) and the Blackhat site soon.

I thought you said it was a hijack yet you only showed a DoS.
Yup, I showed a crash. I didn’t feel the need to do the do the entire hijack for two reasons: Apple already confirmed that this vulnerability leads to remote code execution (they said so in the advisory here). Everybody that was running a sniffer during my talk now has a copy of the DoS code. The demo had two parts. I showed the crash happening on a 10.4.6 machine since it didn't have any of the airport patches. I then rebooted into 10.4.8 and the crash no longer happened. I did this to prove that the Airport patches issued on Sept 21st, 2006 fixed the problem I was demoing. The only real change to airport code was the security fixes that were issued.

Why not just release everything?
You see the correspondence between my email address at my former employer and anybody is not my property. That correspondence owned by my former employer. Due to legal reasons I can’t just release them, and then I would be violating employment agreements. This is what got Mike Lynn into a lot of trouble.

You just reversed the patches and found what you then showed on stage.
I find this to be a funny argument. If I have the skills to reverse the patches and do a binary difference analysis of them, why couldn’t I use those same skills to find the bugs in the first place (they weren’t hard to find). This argument also doesn’t take into account the fact that I showed that the first crash of the exploit occurred on Jul 15th, 2006, or emails to Apple helping them build a wifi auditing box (A linux machine with madwifi patched with LORCON) and pointed them to a vulnerability that was fixed in their patches (a problem with overly long SSIDs). The picture below is from the day I bought the Macbook, July 15th 2006. This crash occurred because I was fuzzing other devices and the Macbook crashed before I got to run the initial setup.

More Blackhat...

Rob and I just gave a talk on Data Seepage. To be honest Rob mostly gave the talk. It was fun and we found peoples password in the audience.

UPDATE: Slides and code are now up at the Errata Security site, here.

Its V-A day....

In a few hours I’ll be taking the stage at Blackhat DC to give a Device Drivers 2.0 talk. This is an updated version of the material from Blackhat Vegas as well as new information about how to find and exploit wireless device driver vulnerabilities. The last 20 minutes of the presentation are devoted to Apple. Since I am no longer gagged I will finally, publicly refute the statements Apple made concerning never sharing anything with them. I will go through the timeline of what was shared, when, and what vulnerability it will point to. I am unfortunately unable to present any material sent to my email address at my former employer, but what I can share definitely destroys the claims that Jon and I were irresponsible, frauds, and shared nothing with Apple.

Bluetooth vuln...Nobody said anything about a Bluetooth vuln...

UPDATE: It was just mentioined to me how funny it is that the book I co-wrote about this here tells you how to findthese vulns. I guess my pundits didn't feel the drive to try it...

Blogging Blackhat

The big story today is how a company (HID Corp) successfully suppressed a talk by threatening to sue a researcher (Chris Paget). This is the third such action in recent times, after Cisco tried to suppress Mike Lynn and Apple tried to suppress Dave Maynor. The threatened legal action in this case is that HID claims Paget's work infringes their patents.

There is an important legal distinction here. In the Lynn case, Cisco claimed it was about trade secrets. In trade secret cases like this, a company is forced to take legal actions against their will. They cannot selectively enforce their rights against some people but not others, they must sue people even if they don't want to, else people would be compromise their trade secrets and claim that since Cisco doesn't sue in some cases, they cannot sue in any case.

The same is true of trademark infringement. When Steve Jobs announced the iPhone, Cisco was forced to immediately sue Apple over the trademark. Cisco didn't have a choice in the matter: even though they wanted to negotiate in a friendly manner with Apple, they had to immediately file court papers against Apple. Otherwise, they would lose any rights they had over the trademark.

While you cannot selectively enforce secrets and trademarks, you can be selective about patents. In other words, you can choose not to sue some people who infringe your patents, and choose to sue others. Just because you failed to sue person A does not hurt your suit against person B.

Thus, Cisco's reason is at least plausible, but HID's reason is not. They are not actually suing to protect their patents, they are threatening to sue in order to suppress free speech.

However, it's not likely to suppress much. You can get schematics for a device that can be used to break into HIDs systems here http://cq.cx/proxmark3.pl, you'll just have to do a few hours of extra work without Plaget's speech.