iPhone Hack, Take Two

Take Two

by Rik Farrow

A lot of people have totally missed the point of the "hacking the iPhone" video, and I'd like to help them understand what it is they missed. The real meat of the whole work appears one minute and 37 seconds into the video, when MobileSafari disappears from the iPhone's display, and gets replaced by SpringBoard, the iPhone's list of applications. At that moment in time, the iPhone has been exploited and the disappearance of MobileSafari is the iPhone owner's only indication that something really bad has happened. Just how bad things could be is something I barely touched on in the video.

If I had stayed with that tiny segment, and start of the terminal session that follows, I thought that only security geeks would recognize the significance of what had happened. I went on to demonstrate the ipwn tool running on the iPhone, then other tools that I had previously installed. My use of the other tools obviously confused many people, who couldn't make the conceptual leap to understand that ipwn itself provided me with all the access I needed to install those other tools. Instead, many people focused on the shortcuts I used to illustrate my ability to find files and to install new software that can do anything that the iPhone can do. Those shortcuts just made the video run a bit shorter. But let's start at the beginning, so I can explain just how the applications used in those shortcuts got on the iPhone in the first place.

For me, the beginning occurred when I learned that the owner of the iPhone runs applications as the root user. The root user has extraordinary powers, powers typically reserved for system administration. But in the iPhone, everything gets done as root. What that implied to me is that any bug in the iPhone's software could result in a remote attacker gaining full control over the iPhone, and I said as much publicly, drawing the attention of Fast Company author Adam Penenberg and editor Will Bourne.

These two gents wanted to know what I meant by "full control", and at that point I really didn't know. I had handled a friend's iPhone, but all I could see is what most people see: a beautiful touchscreen display with cute icons. What was important if I was going to work with Fast Company was to know what was behind those icons, and the fastest way of getting in was a process nicknamed jailbreaking.

Jailbreaking an iPhone is a real hack. People reversed engineered how the iPhone communicated over its USB connection and learned how to subvert that communication to install an application that could in turn install other applications. But once that application is installed, it appears alongside the Apple applications, and makes installing more applications as easy as any other point-and-click app. I quickly installed basic command line tools and SSH, so I could login over the WiFi network and use those tools.

Now that I had gotten beyond the pretty graphics on the face of the iPhone, I could see what looked like a stripped down Mac OS X system on the inside. That is, some of the files and directories found on any Mac system, like the Library directory, were there, as were familiar services. I used a command to find recently modified files, and quickly located the directories where the iPhone owner's personal files were stored: contact info, recent calls, voicemail, web browsing history, bookmarks, and email. For a spy, this level of access was breathtaking, as these files are not encrypted and can easily be read and manipulated using a command line tool found in regular Mac OS X systems, like my MacBook.

But a spy might want to do more, such as use the microphone that is part of any cell phone as a bugging device. I searched the Web for programs that could turn the iPhone into a voice recorder, and soon found an example program that came close. I also found a toolchain for the iPhone, something akin to a Software Development Kit (SDK), but much cruder. With some study and tinkering, I turned the example program into a crude spy tool, rrecord. If I had had much more time, rrecord would have become a remotely controlled spy tool that automatically uploaded its sound files to various Web sites. But rrecord would work well enough for my demonstration (or so I thought).

The setting for the video is my home office. At nine seconds into the video, you can see the iPhone sitting in its cradle, and clearly unconnected to anything else. To the right of the iPhone, and below the black LCD monitor, is the MacBook used to run Metasploit. To the left of the iPhone is the monitor used for the screenshots, set up to mirror what is displayed on the MacBook. What is not shown is a WiFi access point sitting just behind me. WiFi access made the demonstration a lot easier to do, but is not required.

About one minute into the video, you can see two terminal windows open on the MacBook, with the lower one showing a previous session with the iPhone. It took Larry Lindahl, my friend who shot the video, and I many attempts to get what we felt would be a set of shots that could clearly illustrate the points I wanted to make. In retrospect, having that second window open confused people.

Using the upper of the two terminal windows, I started the Metasploit Console. I then prepared Metasploit by setting some values and typing 'exploit'. At this point, Metasploit has set up a Web server that is waiting for a connection that requests the ipwn file. I had reached this point in earlier takes, and created a bookmark so I could enter the URL for Metasploit quickly. As soon as MobileSafari downloads and interprets ipwn, the exploit takes over. By typing sessions -i 1, Metasploit hands over the connection from the ipwn, the ipwn banner appears, and I type in the command uname that displays the version of Mac OS X running, Darwin iPhone 9.0.0d1.

The ipwn program is a rudimentary shell. HD Moore added it to Metasploit specifically for successfully attacking iPhones that did not have a shell program (a command interpreter, like cmd.exe in Windows or /bin/bash in Linux) already installed. Ipwn is much simpler that a real shell, but has one special features most shells don't have: it can download programs from Web servers. Once I had ipwn running, I could have used it to install the commands I would use later. I choose instead to demonstrate the access I had to the iPhone using tools I had previously installed. Had I manually installed the commands I would use later, I might have avoided some of the ruckus that later insued. But in my mind, how the tools got on the iPhone wasn't the point--it was what I could do with those tools.

I used the secure shell to connect back into the iPhone because it makes the demonstration go faster. The ipwn program does not handle backspace, for example, something I really needed, and not having that capability meant that every mistyped key meant starting the commandline over from the beginning again. Watching someone using the commandline is about as exciting as waiting for water to boil as is, and SSH, the secure shell, really helped.

I already knew where to find personal files, and quickly displayed the recently modified files and directories in my iPhone. The careful viewer will then notice a continuity error, as the display appears to jump back in time. I had already been through this sequence twice before, and had replayed the wrong audio file, bugged.amr, twice. In the video, I play a version that closely matches the sound I had just recorded--but not quite, as I clicked on an earlier version of the soundfile, and my MacBook played it with a Quicktime player.

Like many a novice videographer, I noticed many mistakes when I started editing the day after shooting. I had a very tight deadline to meet, so I just completed the video with the footage I had. Had I had more time, and a few more people to work with, here's what the video would have looked like...

The scene: a coffee shop that might be part of a popular chain.

A young man with unruly hair stares intensely at his laptop, an ominous looking ThinkPad with Gothic designs on its lid from the back of the mostly empty room. Enter two executive types, who sit as far away as possible from the young man--not that it will help.

One of the executives takes out his iPhone, and we can see that he is going through settings, enabling WiFi. He next starts MobileSafari, selects a bookmark, and then MobileSafari has disappeared. Across the room, a faint grin appears on the young man's face, as he types a short command, then continues to watch his screen intently. The executive with the iPhone fires up MobileSafari a second time, and this time it works flawlessly. He remarks to his companion that he'd never seen MobileSafari disappear like that before, then orders a double machiato, and continues talking to his companion.

The next scene begins as the two executives are leaving the coffee shop, viewed from over the young man's shoulder. He clicks on an icon, a Quicktime player appears, and we can hear the executive ordering his machiato again. The young man then begins to download all of the personal content on the iPhone, visible as the names of files scroll down the screen of his ThinkPad.

Besides the much improved videography, the improved screenplay touches on a number of issues brought up by various bloggers about the accuracy of my actual video. To start with, the young man never gets close to the iPhone, yet the attack still appears to succeed. The attacker has used what is called a man-in-the-middle attack where all the local network traffic passes through his laptop. As the reply to the executive's first Web request passes through the laptop, software replaces the actual reply with the exploit, and MobileSafari disappears from the iPhone's display.

There are other ways that this attack can take place without touching the iPhone, although these really fail as dramatic events. That is, MobileSafari still disappears unexpectedly, but without the direct intervention of an attacker. Instead, attackers have compromised thousands of Web sites and added the exploit to ordinary pages. If you think this sounds farfetched, you should visit the stopbadware.org site, and check out the count of URLs currently known to contain badware (273526 when I last checked). Almost all of the badware installed on Web sites throughout the world gets done without the Web site owner's permission or notice-- until Google stops linking to their site and puts up a warning instead.

And for iPhone owners, who might be breathing a sigh of relief, most badware is designed to exploit Windows PCs, not iPhones. But installing iPhone exploits on Web servers is a valid and popular attack vector. And iPhone owners could be targeted by an attacker who manages to compromise Web sites likely to be visited by iPhone owners (hello Engadget and Gizmodo).

Even WiFi is not required for the attack I demonstrated, as the EDGE network will serve just as well. I used WiFi to speed things up in my demonstration, but Metasploit has been updated to deal with networks, like the EDGE network.

And Metasploit will not be the attack tool of choice when iPhone attacks get serious. And ipwn and rrecord are really crude applications compared to what can be done with the iPhone.

If you have an iPhone, or have access to one, take this opportunity to examine it closely, but without touching it. Can you tell whether the iPhone is on or off? Now, touch the screen, or the sleep button on the top of the iPhone. If the phone is on, you will see the unlock slider on the screen. If the phone is off, you will shortly see the Apple logo as the phone boots. What is true in both cases is that these are just images that the iPhone displays.

When you hold down the sleep button to turn off an iPhone, you send a software signal to the iPhone to shutdown. On an iPhone that has not been exploited, the iPhone begins the shutdown sequence. On an exploited iPhone, the iPhone may appear to shutdown, but will continue to operate as before until it is commanded to restart (or the battery dies). Then it will appear to reboot, simply by displaying the Apple logo.

You never really know if your iPhone is off. And you can't remove the battery either. Welcome to the world of the paranoid security consultant, where attacks like this have been known about for years, and used in other smart phones.

And as I mentioned earlier, rrecord is really lame. A real iPhone trojan would be much more automated as well as much better at hiding its presence. The improved trojan would only 'call home' when the iPhone owner is already using the network, so the trojan's network traffic will blend in with the owner's Web browsing. A popular method that remote control trojans use is to make innocuous web requests, with commands being sent back as web responses. This method bypasses any firewall that permits web access, and works well over the EDGE network too.

The clever trojan can periodically check the owner's personal files for changes, and upload those as well to a remote web site. If the iPhone's owner's iCal application shows that an interesting meeting starts at 3PM and runs for 90 minutes, the attack can command the trojan to start recording at 3PM and record for 90 minutes--even if the iPhone appears to be turned off.

And like many trojans, the real iPhone trojan can come equipped with a self-destruct program. The nice version of this program just removes the trojan itself. The mean version removes all the files on your iPhone, then shuts it down (for real this time). You can re-install your iPhone software with a forced reset, once you have access to iTunes. But until then, your iPhone is bricked.

I got involved in this project because I was amazed to learn that all applications on the iPhone run as root, as I wrote earlier. Apple needs to change that quickly, and add other real security features to the iPhone that will make exploitation more difficult. Leopard already includes new security features that would help protect the iPhone--if they were used. The biggest challenge will be making real security features work with the SDK that Apple plans to ship in February 2008, because these security features must be both understandable and easey to use by iPhone developers.

As I said in the video, any computing device can be exploited, not just the iPhone. The vulnerability I demonstrated, using TIFF files, has been patched on the iPhone--just 13 months later than it was patched for other Mac systems. And this is not the first time Apple has patched vulnerabilities in TIFF libraries. Apple, like all responsible vendors, routinely sends out patches, like the one released on Nov 16 that patched 41 Mac OS X and Safari vulnerabilities (http://blogs.zdnet.com/security/?p=666).

I really would like to see desktops, servers, and smart phones become a lot more secure. And it is going to take users demanding that the software they use be designed with security being as important as pretty displays and ease-of-use features. I hope I have motivated you, as well as laid to rest some of the apparent flaws in my video.