The Hackers Guide To Dismantling IPhone (Part 2)


 This post is the second part of the series "The Hackers Guide To Dismantling IPhone" and is going to describe how to perform all types of iPhone network attacks on any iPhone. This post is also going to explain how to set up the testing environment for hacking an iPhone also.The iPhone provides developers with a platform to develop two types of applications.

Web based applications – which uses JavaScript, CSS and HTML-5 technologies Native iOS applications- which are developed using Objective-C and Cocoa touch API. This article mainly covers the pen testing methodology of native iOS applications. However, some of the techniques explained here can also be used with web-based iOS applications.

A simulator does not provide the actual device environment, so all the penetration testing techniques explained in this article are specific to a physical device. iPhone 4 with iOS 5 (maybe iOS6) will be used for the following demonstrations.

To perform pentesting we need to install a few tools on our device. These tools are not approved by Apple. Code signing restrictions in iOS do not allow us to install the required tools on the device. To bypass the code signing restrictions and run our tools we have to JailBreak the iPhone. JailBreaking gives us full access to the device and allows us to run code which is not signed by Apple. After JailBreaking, the required unsigned applications can be downloaded from Cydia.

Setting Up the testing environment

In order to set up a descent testing environment you would have to:

  1. Have at your disposal a wireless network that does not have enabled the wireless isolation feature (wireless isolation does not allow communication between hosts, within the same wireless network). If you use an iDevice to set up your testing network then you are screwed since as far as I know iDevice wireless hotspots (e.g. iPhone tethering etc.) have by default that feature enabled.
  2. You would have to configure the proxy with in your iDevice to traffic through a Web Proxy (for this post I am going to use free version of Burp Proxy v1.5).
From Cydia, download and install the applications listed below:
  • OpenSSH – Allows us to connect to the iPhone remotely over SSH
  • Adv-cmds : Comes with a set of process commands like ps, kill, finger…
  • Sqlite3 : Sqlite database client
  • GNU Debugger: For run time analysis & reverse engineering
  • Syslogd : To view iPhone logs
  • Veency: Allows to view the phone on the workstation with the help of veency client
  • Tcpdump: To capture network traffic on phone
  • com.ericasadun.utlities: plutil to view property list files
  • Grep: For searching
  • Odcctools: otool – object file displaying tool
  • Crackulous: Decrypt iPhone apps
  • Hackulous: To install decrypted apps
iPhone does not give us a terminal to see inside directories. Upon OpenSSH installation on the device, we can connect to the SSH server on the phone from any SSH client (ex:Putty, CyberDuck, WinScp). This gives us flexibility to browse through folders and execute commands on the iPhone. An iPhone has two users by default. One is mobile and the other is a root user. All the applications installed on the phone run with mobile user privileges. But using SSH we can log into the iPhone as a root user, which will give us full access to the device. The default password for both the user accounts (root, mobile) is alpine.

Performing our first Man In The Middle attack

In order for you to start capturing non SSL traffic you would have to change the settings in your iPhone, in order for you to do that you would have to follow the steps below.

Step 1: Go Settings -> WiFi.

Step 2: HTTP Proxy -> Manual.

Step 3: Set the proxy IP equal to the IP that the Burp Proxy is running.

Note: Check out that the Authentication is disabled (we would not want to try to authenticate to our own web proxy).

Step 4: Open Burp -> Proxy Tab

Step 5: Proxy Tab -> Options -> Set the listening IP to the one that is visible to the wireless.

Step 6: Proxy Tab -> Set the proxy to invisible and make sure it is in a running state.

Note: By doing this you will be able to capture all none encrypted traffic. A more realistic scenario would include an ARP poisoning attack first (you should know though that wireless access points nowadays incorporate anti-ARP poisoning countermeasure).  Obviously the counter measures have to be defeated.

HTTPS stripping attacks to SSL traffic

Another type of MITM (Man In The Middle) Attack is in encrypted connections (e.g. connections using SSL/TLS etc.). This attack can be performed after a successful ARP poisoning attack, also this type of attack is obviously much more interesting since, it incorporates sensitive data (e.g. credit cards, user names and passwords etc.). The most "easy" way for performing this attack is by using SSLStrip.

Note: SSLStrip is used to perform HTTPS stripping attacks (presented officially for first time at Black Hat DC 2009). SSLStrip will transparently hijack HTTP traffic on a network. The free Burp Suit Proxy Edition 1.5 version and above supports SSLStrip functionality.

The options shown in the picture below may be used to deliver sslstrip-like attacks:

Step 1: Proxy -> Options -> Response Modification

Note: Obviously you can play around with the response modification menu and see how does the client behave with sslstrip-like attack scenario and also with the remove secure flag from cookies. This type of attack is more of a user-oriented attack than an actual technical attack on SSL. It doesn't break the underlying cryptography or trust model. Another way to perform a Man In The Middle attack would be to use the sslsniff tool created by the same guy that wrote sslstrip (Moxie Marlinspike).

This can be defeated by using the HTTP Strict Transport Security (HSTS). The threats addressed  by this http flag are:

1. Passive Network Attackers

The HSTS forces SSL, access using end-to-end secure transport (mixed content is allowed without HSTS). It fixes issues that have to do with web sites that only encrypt the login process and not the cookie(s) created during the login process (the secure flag does not protect from mixing encrypted with non encrypted content).

Note: Tools used to perform the attack: firesheep - http://codebutler.com/firesheep/

2. Active Network Attackers

A determined attacker can mount an active attack, either by impersonating a user's  DNS server or, in a wireless network, by spoofing network frames or offering a similarly  named evil twin access point.  If the user is behind a wireless home router, an attacker can attempt to reconfigure the router using default
passwords and other vulnerabilities.  Some sites, such as banks, rely on end-to-end secure transport to protect themselves and their users from such active attackers.  Unfortunately, browsers allow their
users to easily opt out of these protections in order to be usable

Performing ARP Poisoning to your iPhone (not so easy)

The best possible to perform your MITM attack is by using mature and well tested tools such as Ettercap.  Ettercap is a comprehensive suite for man in the middle attacks. It features sniffing of live connections, content filtering on the fly and many other interesting tricks. It supports active and passive dissection of many protocols and includes many features for network and host analysis.

Step 1: Open a terminal as root and type Ettercap -G then scan for host. In this wireless network the identified hosts are shown below:

Step 2: Alter the traffic in such a way so as to exploit the device. Here is an example ettercap filter that changes on the fly the traffic:

if (ip.proto == TCP && tcp.dst == 80) {
   if (search(DATA.data, "Accept-Encoding")) {
      replace("Accept-Encoding", "Accept-Rubbish!"); 
	  # note: replacement string is same length as original string
      msg("zapped Accept-Encoding!\n");
if (ip.proto == TCP && tcp.src == 80) {
   replace("img src=", "img src=\"http://www.irongeek.com/images/jollypwn.png\" ");
   replace("IMG SRC=", "img src=\"http://www.irongeek.com/images/jollypwn.png\" ");
   msg("Filter Ran.\n");

The code should be pretty self explanatory. The # symbols are comments. The "if" statement tells the filter to only work on TCP packet from source port 80, in other words coming from a web server. This test may still miss some images, but should get most of them. I'm also not sure about Ettercap's order of operation with AND (&&) and OR (||) statements but this filter largely seems to work (I tried using parentheses to explicitly specify the order of operation with the Boolean operators but this gave me compile errors).  The "replace" function replaces the first parameter string with the second.  Because of the way this string replacement works it will try to mangled image tags and insert the picture we desire into the web page's HTML before it returns it to the victim. The tags may end up looking something like the following:

                <img src="http://www.irongeek.com/images/jollypwn.png" /images/original-image.jpg>

Note: The original image location will still be in the tag, but most web browsers should see it as a useless parameter. The "msg" function just prints to the screen letting us know that the filter has fired off.

Now that we sort of understand the basics of the filter lets compile it. Take the ig.filter source code listed above and paste it into a text file, then compile the filter into a .ef file using the following command:

            etterfilter ig.filter -o ig.ef

Note: This type of attack applies to all type of devices, but now-days is most important for mobile devices.

Performing an attack by setting up a rogue access point 

Airsnarf is a simple rogue wireless access point setup utility designed to demonstrate how a rogue AP can steal usernames and passwords from public wireless hotspots.  Airsnarf was developed and released to demonstrate an inherent vulnerability of public 802.11b hotspots--snarfing usernames and passwords by confusing users with DNS and HTTP redirects from a competing AP.

In response to the threat posed by rogue access points, we've also developed a hot spot defense kit to assist users in detecting wireless attackers. HotSpotDK checks for changes in ESSID, MAC address of the access point, MAC address of the default gateway, and radical signal strength fluctuations. Upon detecting a problem, HotSpotDK notifies the user that an attacker may be on the wireless network. Currently HotSpotDK runs on Mac OS X and Windows XP.

Airsnarf has been tested with (i.e. probably requires) the following:

  • Red Hat Linux 9.0 - http://www.redhat.com/
  • kernel-2.4.20-13.9.HOSTAP.i686.rpm - http://www.cat.pdx.edu/~baera/redhat_hostap/
  • iptables - Red Hat 9.0 CD 1
  • httpd - Red Hat 9.0 CD 1
  • dhcp - Red Hat 9.0 CD 2
  • sendmail - Red Hat 9.0 CD 1
  • Net::DNS Perl module - http://www.cpan.org/

Install & run Airsnarf with the following commands:

tar zxvf airsnarf-0.2.tar.gz
cd ./airsnarf-0.2

How does it work?  Basically, it's just a shell script that uses the above software to create a competing hotspot complete with a captive portal.  Variables such as local network, gateway, and SSID to assume can be configured within the ./cfg/airsnarf.cfg file.  Optionally, as a command line argument to Airsnarf, you may specify a directory that contains your own airsnarf.cfg, html, and cgi-bin.  Wireless clients that associate to your Airsnarf access point receive an IP, DNS, and gateway from you--just as they would any other hotspot.  Users will have all of their DNS queries resolve to your IP, regardless of their DNS settings, so any website they attempt to visit will bring up the Airsnarf "splash page", requesting a username and password.  The username and password entered  by unsuspecting users will be mailed to root@localhost.  The reason this works is 1) legitimate access points can be impersonated and/or drowned out by rogue access points and 2) users without a means to validate the authenticity of access points will nevertheless give up their hotspot credentials when asked for them.

So what's the big deal?  Well, with a setup like Airsnarf one can obviously create a "replica website" of many popular, nationally recognized, "pay to play" hotspots.  That's as simple as replacing the index.html file Airsnarf uses with your own custom webpage that still points its form field variables to the airsnarf.cgi.  Combined with sitting at or near a real hotspot, hotspot users will associate and unknowingly give out their username and password for the hotspot provider's network.  The usernames and passwords can then be misused at will to utilize other hotspots of the same provider, possibly anywhere in the nation, leaving the original duped user to pay the bill.  Should the user be charged per minute usage, they may recognize something is terribly wrong when they get their next bill.  If the user pays a flat rate for unlimited usage, the user may never realize their credentials have been captured and are being misused.

Wireless hotspot operators should consider the following:  stronger authentication mechanisms, one-time authentication setups, monitoring the existence and creation of APs, and perhaps just giving away hotspot access for free to remove any user service theft risks.

To Be Continued...

  1. http://en.wikipedia.org/wiki/Wireless_security
  2. http://www.kimiushida.com/bitsandpieces/articles/attacking_ssl_with_sslsniff_and_null_prefixes/index.html 
  3. http://www.thoughtcrime.org/software/sslsniff/ 
  4. http://monkey.org/~dugsong/dsniff/ 
  5. http://ettercap.github.com/ettercap/
  6. http://www.irongeek.com/i.php?page=security/ettercapfilter
  7. http://codebutler.com/firesheep/
  8. http://tools.ietf.org/html/rfc6797#section-2.3.1
  9. http://resources.infosecinstitute.com/pentesting-iphone-applications/ 
  10. http://airsnarf.shmoo.com/