Month: August 2014

In a previous post I was delighted to report that assisted GPS (A-GPS) has become fast enough so I no longer have to rely on Google's Wi-Fi location service that in return requires me to send Wi-Fi and location data back to Google periodically. Unfortunately it turns out that the A-GPS implementation of one of my Android smartphones sends the ID of my SIM card (the IMSI) to the A-GPS server. From a technical point of view absolutely unnecessary and a gross privacy violation.

Read on for the details…

How Assisted GPS (A-GPS) works

To get a position fix, the GPS chip in a device needs to acquire the signal of at least three satellites. If the GPS chip is unaware of the identities of the satellites and their orbits this task can take several minutes. To speed things up a device can get information about satellites and their current location from an A-GPS server on the Internet. The single piece of information the server requires is a rough location estimate from the device. Usually a device is not aware of its rough location but it knows other things that can help such as the current cellular network id (MCC and MNC) and the id of the cell that is currently used. This information is sent to the A-GPS server on the Internet that then determines the location of the cell or network with a cell id / location database.The location off the cell or network is precise enough to assemble the satellite information that applies to the user's location which is then returned over the Internet connection. The satellite information is then fed to the GPS chip which can then typically find the signals of the GPS satellites in just a few seconds.

No Private Information Required

It's important to realize at this point that no personal information such as a user's ID is required in this process. The only information that can be traced back to a person, if the A-GPS client is implemented with privacy in mind, is the IP address from which the request was made to the server. In practice a mobile device is usually assigned a private IP address which is mapped to a public IP address from which the request seems to have originated. This public IP address is shared with many other users. Hence, only the network operator can identify which user has originated the request while the A-GPS server never gains any insight into who has sent the request.

The SUPL protocol and Privacy Breaching Information Fields

A standardized method for a device to gather A-GPS information from a server is the Secure User Plane Location protocol (SUPL). Several companies provide A-GPS SUPL servers answering requests on TCP port 7275 such as Google (supl.google.com) and Nokia/Microsoft (supl.nokia.com). In the case of my Android smartphone, supl.google.com is used. As the 'S' in 'SUPL' suggests, the protocol uses an encrypted connection for the request. As a consequence, using Wireshark without any additional tools to decode the request won't work as the content of the exchange is encrypted. Fortunately there's SUPL-PROXY, an open source piece of software by Tatu Mannisto that can be used in combination with domain redirection to proxy the SUPL SSL connection and decode the request and response messages. And on top, the SSL certificate generated by Tatu's software for the proxying can be fed into Wireshark which will then also decode the SUPL messages. And what I saw here very much disappointed me:

My SIM Card ID In The SUPL Request And No SSL Certificate Check

I almost anticipated it but I was still surprised and disappointing so see my SIM card's ID, the International Mobile Subscriber Identity (IMSI) in the request. This is shown in the first screenshot below. As explained above, the IMSI or any other personal information is not necessary at all for the request so I really wonder why it is included!? And just to make sure this is really the case I ran another test without a SIM card in the device and also got a valid SUPL return with the IMSI field set to 0's.

The second screenshot shows the cell id in the request which is required for the SUPL request. The IMSI in combination with the cell ID provides the owner of the SUPL server (i.e. Google in my case) a permanent personal identifier and as a consequence the ability to pinpoint and record my location whenever a SUPL request is made. And in this day and age, it's pretty certain that my network operator is not the only entity that is aware of my IMSI…

The third screenshot below shows the first part of the SUPL response which includes the location of the cell that served me when I recorded the SUPL request. Just type the two coordinates into Google search and you'll end up with a nice map of the part of Austria where I was when I put together this post. The second part, not shown in the screenshot, contains the satellite information for the GPS receiver.

And the cream on top is that the SUPL client on my Android device did NOT check the SSL certificate validity. I did not include the server certificate in the trusted certificate list so the client should have aborted the request during the SSL negotiation phase. But it didn't and thus anyone between me and the SUPL server at Google can get my approximate location by spoofing the request in the same way I did. I'm sure that two years ago, most people would have laughed and said that it's unlikely this could happen or that someone else but my network operator would know my IMSI, but one year post-Snowden I don't think anyone's laughing anymore…

When The Baseband Makes The Query

And now to the really scary part: The next thing I tried was if I could reproduce this behavior with other Android devices at hand. To my surprise the two I had handy would not send a SUPL request over Wi-Fi and also not over the cellular network (which I traced with tcpdump on the device). After some more digging I found out that some cellular radio chips that include a GPS receiver seem to perform the requests themselves over an established cellular IP connection. That means that there is NO WAY to trace the request and ascertain if it contains personal information or not. This is because the request completely bypasses the operating system of the device if it is made directly by the radio chip. At this point in time I have no evidence that the two devices from which I did not see SUPL requests actually use such a baseband chip A-GPS implementation and if there are personal indentifiers in the message or not. However, I'm determined to find out.

    

 

 

 

And for those of you who'd like to try yourselves I'll have a follow up post that describes the details of my trace setup with two Raspberry PI's, Wireshark, and the SUPL-PROXY software mentioned above.

When I upgraded to my recent smartphone hardware (a Samsung Galaxy S4 running Cyanogen Mod) I noticed that the time it takes to get a first location via GPS (first time to fix) is stunningly quick compared to my previous device. Even after not having used the GPS receiver for more than half a day, it only takes a few seconds until at least 3 satellites have been decoded and a pretty good approximation of my location is being returned.

Obviously using Google's Wi-Fi SSID database gives an even faster first location approximation but I am not very fond of having to consent to periodically gathering SSID and location information for Google to return the favor. But with such a fast GPS startup time I don't need Google's SSID services anymore and thus I have happily switched it off to re-gain some of my privacy. Yes, I know, SSID location gathering should be anonymous but I don't want to do it anyway.

But getting a fast GPS fix means that the device has to ask for satellite location information which also requires a rough location approximation being sent to a server in the network in what is called a SUPL request. More about my 'adventures' to find out more about what's included in such a request in my next post on the topic.

I always assumed that my Ubuntu based servers would automatically keep their real time clocks synchronized to NTP servers on the net. But when I recently checked the time on my local Owncloud server at home, I was quite surprised that it was off by over a minute. Also, the time on a virtual server I use for my backup SSH tunnels on the Amazon cloud was off by over 30 seconds. It turns out that Ubuntu server only polls an NTP server at system startup and both machines have been up and running without a restart for over a month. Quite an RTC drift for only 30 days, I would have expected far less. The issue can be fixed quite easily with the following entry in /etc/crontab but I wonder why Ubuntu doesn't do it out of the box!?:

# Synchronize date with ntp server once a day and write the result to syslog
00 6    * * *   root    ntpdate ntp.ubuntu.com | logger

Agreed, for most services used in mobile networks today a NATed private IP address does the job. But there are some applications that require a reachable public IP address such as web servers, VPN gateways, chat servers, etc. Also agreed, these are mostly connected via fixed line connections but in some instances, e.g. for fallback solutions or in places where DSL links are not available, it's great for them to be reachable over a cellular network as well.

Unfortunately support of public IP addresses is seen as a niche service by most mobile network operators and hence they either don't support public IP addresses at all or only via obscure and unadvertised APNs. The more delighted I was when I saw that one of the mobile network operators in Austria is offering to use a public IP address for a connection via their web configuration interface with a simple on/off switch. Great, a mobile network operator who's willing to also cater for those with special applications!

And when thinking a bit more about it it's even more stunning in the light of many alternative fixed line network operators who are also not willing anymore to give out public IPv4 addresses, not even on request. Take a look guys, it can be THAT simple!!!

In a previous post I described how to use a Raspberry Pi as Wi-Fi access point and how to trace the data traffic of my smartphone in real time using tcpdump and netcat. The next logical step is of course to directly trace the network traffic on the smartphone. This has the big advantage that it's not only possible to trace the Wi-Fi traffic but also traffic that goes over the cellular interface. I've laid the foundations for this a couple of weeks ago by installing CyanogenMod on my Samsung Galaxy S4. Unfortunately, though, CyanogenMod does not include tcpdump in its standard image.

There are some sources on the net that provide pre-compiled tcpdump executables for Android but since these are not well known I had a hard time trusting them. Not that I think they are not trustworthy but I just don't know them at all. So I had to find a way to get a trusted executable. At first I thought that I could perhaps use a tcpdump executable from one of my Raspberry Pis as they also run on an ARM processor. That would have probably worked if the Raspberry Pi used static linking for it's executables, i.e. bundling all libraries required into the file which is required for Android. Raspian, like most other Linux distributions, I imagine, however, uses dynamic linking with the libraries in separate directories. O.k. so that was not an option.

After doing some more research I came across a 3 piece post over on the Symantec blog (see here, here and here) that explains in detail how to cross compile tcpdump for Android from the original sources on a Debian system. Fortunately I had something close to this, an Ubuntu 12.04 in a virtual machine on which I can easily try things without backing anything by creating a VM snapshot to which I could restore later-on to undo all changes. It turned out that cross-compiling the sources is not very difficult at all as only the original source and the gnu cross compiler. As I was using Ubuntu I had to install additional packages which is not described in the Symantec posts but the error messages are quite straight forward. Also, I had to set 'LDFLAGS=-static' in the tcpdump 'Makefile' as mentioned in the comments to the third part of Symantec's description.

And here's the command to trace the cellular interface once tcpdump is up and running on your Android phone and to save the traffic into a file on the SD card:

tcpdump -n -i rmnet_usb0 -s 65535 -w /storage/sdcard1/trace.pcap

Happy tracing on Android!

I don't mind some advertisement on websites as long as it's not obtrusive. Live and let live. On the desktop that line has long been crossed with major news websites looking more like a Las Vegas casinos than news websites. So I've been using Adblock Plus for many years there already and I'm always shocked when I switch it on and see how the unfiltered web 'really' looks like these days. On the mobile side, ads were somewhat more subtle on the web sites I frequent, at least until recently.

Within a short time, however, the three news websites I visit daily on my mobile have started to push ads into my face with full screen pop-ups or keep showing me the same stupid ad over and over again. Sorry, that's it, you've pushed me over the edge and I had to resort to countermeasures. Adblock Plus is available as well for Android but unless there is no alternative I don't want a proxy in the system.

The alternative is to make use of the 'hosts' file and block ad serving domain names. This requires root access to the device but that's not a problem on CyanogenMod. Also, I've already modified the hosts file to keep apps and the OS from frequently calling home so it was little effort to also include the domain names from which the ads come from.

Actually I'm a bit shocked at how many domains I had to block to get back my peace on three news websites. Here's the list of domains they include in their pages that have nothing to do with the main content:

#Ad blocking
127.0.0.1   ad8.adfarm1.adition.com
127.0.0.1   googleads.g.doubleclick.net
127.0.0.1   stats.g.doubleclick.net
127.0.0.1   mobile.smartadserver.com
127.0.0.1   www.google-analytics.com
127.0.0.1   pagead2.googlesyndication.com
127.0.0.1   ads.stickyadstv.com
127.0.0.1   pixel.rubiconproject.com
127.0.0.1   t1.visualrevenue.com
127.0.0.1   beacon.krxd.net
127.0.0.1   rtb.metrigo.com
127.0.0.1   c.metrigo.com
127.0.0.1   ad.zanox.com
127.0.0.1   cm.g.doubleclick.net
127.0.0.1   ib.adnxs.com
127.0.0.1   ih.adscale.de
127.0.0.1   ad.360yield.com
127.0.0.1   ssp-csynch.smartadserver.com
127.0.0.1   ad.yieldlab.net
127.0.0.1   dis.crieto.com
127.0.0.1   rtb.eanalyzer.de
127.0.0.1   connect.facebook.net
127.0.0.1   platform.twitter.com
127.0.0.1   b.scorecardresearch.com
127.0.0.1   sb.scorecardresearch.com
127.0.0.1   ads.newtentionassets.net
127.0.0.1   ak.sascdn.com
127.0.0.1   fastly.bench.cedexis.com
127.0.0.1   probes.cedexis.com
127.0.0.1   linkedin.com
127.0.0.1   x.ligatus.com
127.0.0.1   d.ligatus.com
127.0.0.1   a.visualrevenue.com
127.0.0.1   radar.cedexis.com
127.0.0.1   www.googletagservices.com
127.0.0.1   pubads.g.doubleclick.net
127.0.0.1   farm.plista.com
127.0.0.1   static.plista.com
127.0.0.1   video.plista.com
127.0.0.1   tag.yoc-adserver.com
127.0.0.1   ads.yahoo.com

Yes, that's from just three news portals. Quite shocking…

Knowing something in theory and experiencing something for real are two different things. I know of course that Android is based on a Linux kernel and shares many things with desktop Linux distributions. But it's all nicely hidden under the Android user interface so the concept felt quite abstract to me, even after using 'adb' for a long time and having experience with Debian running on ARM driven Raspberry Pis and all. But when I recently opened a terminal on the device itself and used the shell like I would use one on a PC with a hardware keyboard, auto command completion and on top of that write shell scripts with my favorite shell based text editor 'nano', e.g. to issue the commands to enable write access of the system partition and start the editor to modify the 'hosts' file, it started to feel quite different. Yes, there's really something under the hood I'm quite familiar with and it 'feels' very good indeed.

I'm quite surprised that pretty much the entire industry these days thinks that Wi-Fi Internet connectivity means that there is free, unlimited and ultra-fast connectivity. As a consequence many smartphones and tables are shamelessly downloading operating system updates and other things small and large without asking the user first.

A 150 MB Android update available!? No problem, there's Wi-Fi so it's downloaded by many devices without asking the user first. Now imagine you are hanging off a hotel Wi-Fi that is slow already or even paid by the megabyte. The former is still the norm rather than the exception while the later is rare these days but it still exists, which is why I would never stay in NH hotels if I can avoid it…

Even worse, you ask a friend in a café if you could tether your Wi-Fi only tablet over his phone to the Internet. He graciously agrees despite only having a contract that includes a few hundred megabytes of data a month. After all, a couple of web pages won't hurt!? Well, these probably won't but the 150 MB OS update starting automatically will. And unless you friend keeps his data counter in sight he probably never knows what hit him until a couple of days later when he hits his monthly data cap.

Therefore, think twice before you open your mobile network connectivity for anyone…

Fortunately CyanogenMod on my Samsung Galaxy S4 gives me root access so I've put the domain name of the update server in the hosts file and point it to localhost. This stops the madness and restores sanity so I will not be surprised by a bulk data download while I'm tethering or staying in a hotel.

Just a few weeks after I could use LTE for the first time while roaming in France I recently found myself in Belgium's capital for the weekend and could again benefit from LTE speeds while roaming. But how fast is it actually and is there a bottleneck on the link to the home network? The later is quite important as all data is tunneled to the PDN-Gatway in the home network and from there to the Internet. As you can see in the image on the left, Mobistar in Belgium and my home network operator have provisioned the link with ample capacity and I could reach speeds of 20 Mbit/s in the downlink direction and 14 Mbit/s in the uplink direction on LTE Band 20 (800 MHz) cell with a 10 MHz carrier in average signal conditions. Not too bad I would say. And the ping delay of 62 ms for a roaming scenario is great as well.

So there we go, somewhere along the way Android lost the radio network type (RAT) indicator over the signal bars when roaming. I wonder if that has something to do with Americans rarely leaving their country? Anyway, the important thing is that Android is open and flexible enough for someone to come up with an app to fix the issue. After looking around bit I chose the "Network Type Indicator" app and as it didn't want any suspicious rights I didn't hesitate to install it. It works as it should and my smartphone again feels as it should when I'm out of the country. It is even better than the original as I can now see the network type much easier when using the device for navigation in the car. Yes, I like to know what kind of network is around me when driving through the countryside…