Firewall Your iPhone

by Лоика

Intro

In light of the recent Carrier IQ revelations, the feelings of paranoids everywhere have been confirmed: smartphones spy on you.

What's even worse is that the data is handled by some shady company.  If it went directly to the NSA, CIA, NRO, FBI, DHS, or one of our other 13 intelligence agencies, you could be more sure that they would keep it to themselves, perhaps not even allowing other law enforcement organizations access, in addition to Chinese hackers, etc.

In some shady company's servers, it's free game for skilled ninjas, high bidders, and spooks of any and all varieties.  Upon receiving the gift of a new iPhone 4s, I was eager to jailbreak and check for little parrots talking back to home...

Background

First, I will provide the information and background on the state of the hardware and software researched.

When I received the iPhone 4s, it was running iOS 5.0.1 and a jailbreak wasn't yet available.  I turned Siri on, played with it, found I didn't like it, and turned it off.

This happened a few times over the course of a few days, then it stayed off for weeks.  I never logged into iCloud, FaceTime, and have no account for such.  Never bought or downloaded anything from the app store.  I never let GPS be on, and selected "Don't Send" on the "Diagnostics & Usage" settings.

I, in fact, connected this phone to my computer only to jailbreak it.  No sync over Wi-Fi.  I basically avoided any integration of this device with others, with the Internet, and with Apple.  I did have iMessage turned on, an Apple service for free texting between iDevices.

I used it as a phone and a camera for this time.  Here's the hardware summary:

  • Model: MD276LL (iPhone 4s)
  • Carrier: Verizon
  • iOS Version: 5.0.1 (9A405)
  • Modem Firmware: 1.0.13

Fun Begins

The jailbreak (Absinthe) came out.

I got around to applying it, backing up data, and applying it.  It worked with no mishaps.  I turned off all automatic syncing through Wi-Fi, etc.

Now that I had Cydia on there, the first thing I did was the first thing any self-respecting 2600 reader would do: install MobileTerminal, network utilities, tcpdump, and all the tools one needs to take a peek at the network and see what's going on under the hood.

I SSH'ed in and got comfortable...

I understood that my Wi-Fi was at en0, and 3G seemed to be on a strange device named pdp_ip0, of which there were four, as follows:

pdp_ip0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1450
inet 10.255.255.156 --> 10.255.255.156 netmask 0xffffffff
pdp_ip1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
pdp_ip2: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
pdp_ip3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500

Above the 10.255.255.156 would be your mobile broadband/3G IP address.

The 255s were placed there in the same manner that phone numbers in movies use "555."

Now with this information, I could cap packets on the 3G or Wi-Fi side, and I knew the IP addresses.

I ran tcpdump on the thing while it wasn't in use, and saw some packets that seemed unexplained, so I started messing around with Netstat, running netstat -n to see what connections were happening and what status they held.

I didn't like what I saw:

Active Internet connections
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp4       0      0 10.255.255.156.49159    198.224.191.68.143      ESTABLISHED
tcp4       0      0 10.255.255.156.49158    17.172.232.51.5223      ESTABLISHED
tcp4       0     48 192.168.1.8.22          192.168.1.3.41445       ESTABLISHED
udp4       0      0 *.*                     *.*

The first two connections, as you can tell, were on the mobile broadband.

Mind you, this was happening while I had an excellent Wi-Fi connection, which you can see me SSH'ed in over on the third line.

You can see that I had an established TCP connection through my 3G hardware to these two mysterious IP addresses.

I looked them up.  The first range was owned by some company unknown to me (WDSPCo.), which owns the range 198.224.0.0/16.  The second was Apple: 17.0.0.0/8.  So time went on, and I kept an eye on this.

It seemed to be the status quo.  The phone was always connected to some IP in Apple's range on port 5223, and to WSDPCo. on port 143.

The WDSPCo. IPs didn't seem to be allowing outside connections from my home cable, either.  But they were happy to let my phone connect.  WDSPCo. seems to lease IPs for mobile devices, so it's also likely that whoever this is is simply leasing these addresses from them.

Either way, a Telnet into one of their servers from my phone yields this welcome message:

* OK Proxy IMAP ready to serve you, master.

I looked online and found others complaining about this same thing - not even about possible privacy "issues," but about losing bandwidth that they paid hard earned money for.

So What Are They Sending?

Now that it's established that there are little tweets going back to Apple, we must ask: "What are they sending?"

I can't answer that question, but I can address whether or not these things are data or simply pings.  First of all, it is important to note that the communications to Apple often come as a cluster of three packets every five minutes or so.

The first sends 85 bytes of data from the phone to Apple.  The second is about 37 bytes of data from Apple to the phone, totaling about 93 bytes.  The last has no data, totals about 56 bytes in size, and is sent from the phone.  This seems to be the standard interaction.

The data fields do not stay constant between these clusters of communication.  In our limited observation of these exchanges, one larger packet was observed being retransmitted many times.  It contained a plaintext string: courier.push.apple.com

I looked this up and saw that it had to do with Apple FaceTime, a video chatting service.  A service I have turned off.  I checked online to find that other people have been complaining about not being able to turn this off in desktops and laptops.

After a few days, I came to find that this traffic was largely due to iMessage.  I decided to play with this, and found that the range 198.224.0.0/16 was associated with iMessage, but not necessary for functionality.  I also saw some of the same connections even with iMessage off.  It is also noted that when changing iMessage settings, I saw brief connections to the range 63.116.166.0 to 63.116.166.255 on port 80/TCP, which is Akamai.  Akamai is a data collecting kind of company - I have no need for them myself.

Either way, it's clear that this traffic was largely unsolicited by me, and has proven to be difficult or impossible to stop in settings.  Even with iMessage off, these connections were still forming, and some of them weren't necessary for iMessage in the first place.

To me, this was a problem and required some fixing...

Solution - OpenBSD PF

I came to find that the OpenBSD PF packet filter was built in and installed, along with its relevant control pfctl.  I decided to block all traffic from Apple, because I really just didn't need them for anything, other than this beautiful hardware I had.

After messing around and reading man pages, I ended up with this pf.conf:

# $OpenBSD: pf.conf,v 1.52 2013/02/13 23:11:14 halex Exp $
#
# See pf.conf(5) for syntax and examples.

3g = "pdp_ip0"
wifi = "en0"
apple = "{
          17.0.0.0/8
          198.224.0.0/16
          63.116.166.0/24
        }"

# play dead
set block-policy drop
set skip on lo0

block in quick on {$3g, $wifi} from $apple to any
block out quick on {$3g, $wifi} from any to $apple

This, as you can see, simply blocks the offending IP ranges (17.0.0.0/8 / 198.224.0.0/16 / 63.116.166.0/24).

Put this in /etc/pf.conf and, to start PF, run: pfctl -ef /etc/pf.conf

The packet filter was enabled, and I went back to playing with: netstat -n | head

At some point, I noticed something I found quite amusing:

Active Internet connections
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp4       0      0 10.255.255.156.49366    17.172.232.93.5223      SYN_SENT
tcp4       0      0 10.255.255.156.49365    17.172.232.220.5223     SYN_SENT
tcp4       0      0 10.255.255.156.49364    17.172.232.147.5223     SYN_SENT
tcp4       0      0 10.255.255.156.49363    17.172.232.163.5223     SYN_SENT
tcp4       0      0 10.255.255.156.49362    17.172.232.159.5223     SYN_SENT
tcp4       0      0 10.255.255.156.49361    17.172.232.83.5223      SYN_SENT
tcp4       0      0 10.255.255.156.49360    17.172.232.141.5223     SYN_SENT
tcp4       0      0 10.255.255.156.49359    17.172.232.140.5223     SYN_SENT

Ahahahahahahaha no one can hear you scream little birdy - all your SYNs are going to /dev/null !!

This persisted for some time.

Here and there, I would check and see this SYN gasping.  But it seems to have died off now.

I went to figure out how to add this to the boot sequence, and found: /etc/launchd.conf

I added the line: bsexec .. /sbin/pfctl -ef /etc/pf.conf

Now it starts at boot and loads the configuration.  To turn it off, use: pfctl -d

Conclusions

My initial observations were tainted by iMessage, but further observation of this behavior was made with iMessage turned off.  Apple, and three other entities that are not entirely clear, had unsolicited connections opening from the phone to servers out on the web.  One was onto a hidden IMAP server, another was to Akamai.  This means that there is software making these connections.

I am sure some of it, or all of it, is built into the firmware.  The easiest way to deal with this is to just block the hosts.  This may get tricky, depending on which services you would like to use.

And as always, further investigation is warranted.

The future is written by you.

Gr33tz to callz, lace, Лаzи, s4m, and ptq.

Return to $2600 Index