Today in my undergraduate security class, we set up a sniffer so we could run Wireshark and Mallory to listen in on my Android smartphone. This blog piece summarizes what we found.
- Google properly encrypts traffic to Gmail and Google Voice, but they don’t encrypt traffic to Google Calendar. An eavesdropper can definitely see your calendar transactions and can likely impersonate you to Google Calendar.
- Twitter does everything in the clear, but then your tweets generally go out for all the world to see, so there isn’t really a privacy concern. Twitter uses OAuth signatures, which appear to make it difficult for a third party to create forged tweets.
- Facebook does everything in the clear, much like Twitter. My Facebook account’s web settings specify full-time encrypted traffic, but this apparently isn’t honored or supported by Facebook’s Android app. Facebook isn’t doing anything like OAuth signatures, so it may be possible to inject bogus posts as well. Also notable: one of the requests we saw going from my phone to the Facebook server included an SQL statement within. Could Facebook’s server have a SQL injection vulnerability? Maybe it was just FQL, which is ostensibly safe.
- The free version of Angry Birds, which uses AdMob, appears to preserve your privacy. The requests going to the AdMob server didn’t have anything beyond the model of my phone. When I clicked an ad, it sent the (x,y) coordinates of my click and got a response saying to send me to a URL in the web browser.
- Another game I tried, Galcon, had no network activity whatsoever. Good for them.
- SoundHound and ShopSaavy transmit your fine GPS coordinates whenever you make a request to them. One of the students typed the coordinates into Google Maps and they nailed me to the proper side of the building I was teaching in.
What options do Android users have, today, to protect themselves against eavesdroppers? Android does support several VPN configurations which you could configure before you hit the road. That won’t stop the unnecessary transmission of your fine GPS coordinates, which, to my mind, neither SoundHound nor ShopSaavy have any business knowing. If that’s an issue for you, you could turn off your GPS altogether, but you’d have to turn it on again later when you want to use maps or whatever else. Ideally, I’d like the Market installer to give me the opportunity to revoke GPS privileges for apps like these.
Instructor note: live demos where you don’t know the outcome are always a dicey prospect. Set everything up and test it carefully in advance before class starts.
Wondering if you considered the possibility of intercepting and manipulating the returned URL of the AdMob request?
Appears to be a fantastic way to root a droid.
Unless the AdMob responses are used by a process with root (which seems unlikely) I don’t see where the vulnerability exists.
On a related note, I recently discovered that the Facebook page for setting your privacy preferences doesn’t work over HTTPS; it forces you to use HTTP. Worse, if you have HTTPS-Everywhere installed, then you can’t change your privacy settings: you can click the buttons, but Facebook silently fails accept the changes.
Thank you for this blog post, quite interesting to see that Facebook traffic is sent in the clear. I am developing a Facebook desktop application as well (see here), and there, Facebook refuses to authenticate if you are not using HTTPS.
I’m actually quite interested in the traffic dumps you got of the Facebook communication. The Facebook app on Android is for some reason allowed to get the phone numbers and email addresses of your friends, which is quite convenient, especially having the phone numbers in the Android address book is cool. I want the same for my application, but the official API doesn’t allow it, so I am wondering how FB on Android does it. Any chance that you can send me a traffic dump of the communication at the point where the app downloads a phone number or email address?
I spent all of one minute looking at the Facebook traffic. That’s a far cry from reverse engineering unpublished APIs. It’s very easy to set this up yourself. I have no idea how easy or hard it would be for you to sort out how to use unpublished Facebook APIs. Good luck!
Ok, we’ll try capturing and analyzing the traffic ourselves, should be easy since it is sent in plain text. Thanks!
Great project for an undergrad program, thanks for the results!
It is worth observing that an application can easily determine if it is on 802.11 or carrier data and could choose to disclose more information (or drop encryption) assuming that the 3g connection is harder to eavesdrop on.
It would be pretty interesting to see if any borderline apps acted any differently in practice. Decompilation or a 3g micro cell are probably a substantial barrier, but you might have success using a VPN over the mobile network and sniffing the endpoint.
Thanks for taking a look a mobile information disclosure!
Wish there was a firewall app that allowed blocking of specific IPs like Firewall iP for the iPod Touch / iPhone.
Does this finding pertain to Google Calendars within Google Apps domains that have the force SSL setting turned on globally? I believe that ensures encryption for all CalDAV and web browser sessions. But I’m very curious whether there’s still an http backdoor for Android, in which case a 3rd-party CalDAV client would be far preferable. 🙂
I’m not sure since I don’t have that setup, but you should be able to test it easily with your own Android phone, a copy of Wireshark, and so forth. I suspect the problem is universal.
Hm, the Android SDK doesn’t seem to have what I’d need to check this, and otherwise, I’m on an iPhone. I suppose if by chance Google Apps domain settings don’t apply to a hidden Android connection method then that a domain’s users can simply be instructed to use Google’s Exchange/ActiveSync instructions, which include an option to force SSL in the client. I believe that works on Android 2.1, where users can only have one Google account set up and so use ActiveSync for Google Apps calendars for their institutional work.
When in doubt, you can set up a sniffer and just look at the traffic. It’s much easier than digging through source code.
Um, right. Wireshark is the easy part … But the SDK’s emulator does not allow testing this point. 😉
Have you tried loading the sniffed pcap file into NetworkMiner to extract images, facebook messages, tweets and gmail accounts?
You can read more about this functionality here:
http://www.netresec.com/?page=Blog&month=2011-02&post=Webmail-Information-Leakage
http://www.netresec.com/?page=Blog&month=2011-01&post=Facebook-SSL-and-Network-Forensics
We have done some work on Android. Though not directly related to your blog post, I think this demonstration of a trojan might be of interest to you: Stalk N’ Steal
-Chaitanya.
I am one of the co-founders of ShopSavvy. I am dismayed to read your post. Each time you turn on the app to scan a barcode we determine your location to help you get the best deal. The first reason we locate you is to show you nearby stores that sell the product you have scanned (we show both the price and the whether or not it is in stock). The second reason we locate you is to determine which store where you are shopping. Based on this information we can offer retailer specific deals, rebates and coupons for the product. ShopSavvy is all about local shopping and without GPS coordinates we have no idea where you are. Without it we can only show you online results – i.e. not a very compelling offering.
We disclose that we need GPS coordinates to make the app work. We also publish a privacy policy that details how we use location data related to your shopping behavior. Google selected ShopSavvy as one of the best Android apps back in 2008 when they awarded us with the Android Developer Challenge. The reason we were selected was due primarily to our use of the various features of the first Google phone – camera, GPS, accelerometer and internet. Please feel free to reach out to me directly if you would like to discuss this further. For more info: http://shopsavvy.mobi
I dont think the objection was to ShopSavvy’s use of the GPS (it’s pretty obvious that something that offers coupons based on your location would need GPS data), it was more that the GPS data was sent unencrypted.
That said, since one would have to be within sniffing range of WiFi to capture the data in the first place, isn’t the security concern of GPS data being exposed rather moot?
In the case of SoundHound, they clearly don’t need to know where I am in order to tell me what song they’re hearing. I agree that ShopSavvy is somewhat different, in that there’s a tradeoff. You can tell me more useful things if you know more precisely where I am. As a user, I’d like to see some control over that. I might be perfectly happy for you to know that I’m in Houston without you knowing exactly what store I’m in at the time.
One possibility that occurs to me is that SoundHound may be making use of the GPS coordinates to narrow down the search. If you are in the US, there is probably not much point searching through (for example) the Ukrainian top 100. By adding in a location hint they may be able to optimize their search. Sure, they shouldn’t *need* the information, but by providing it the search may take 10 seconds instead of 45.
I imagine what SoundHound really wants to know is where songs are popping up. In the aggregate, if they’re getting enough hits on their service, they can produce beautiful animated maps where they can plot out the spread of any particular song. I’m sure that kind of data is worth real money to the record companies.
Of course, that’s not my problem. They need to offer some value to me in return for my telling them where I am. For example, say they only tracked what city I’m in, they could tell me, in return, something about how many other people in my city have tagged the same song. That would still let them collect and sell interesting aggregate data without having a database somewhere that says exactly where I was at the time I wanted to recognize a song.
Soundhound marks your GPS location when you tag a song (look at your recently tagged songs and see a map point of where you were). Someone will need to investigate further to see how this data is being used by Soundhound after it’s sent over the network and privacy policies, etc, however I imagine it’s something harmless like storing your tag history (which includes this GPS data). Definitely should be made optional, whether by Soundhound or Android OS is debatable.
I definitely think that the user should have the option to configure at what level of resolution an application gets your location. Clearly you want navigation applications to be able to see the highest resolution, and other applications you might not want to know your location at all. There is a middle ground however with location-based services (including advertising). If an application wants to provide me with nearby businesses or offers, it only needs to know my approximate location (within a few city blocks). The application should probably have the ability to request that level of detail, and I as a user should have the option to override the developer’s request and only provide what I think is appropriate. Maybe I’ll find my way over to the android site and submit an enhancement request.
On the topic of VPN, does anyone know of a way to setup a VPN server on my home network that would be compatible with android and/or iphone? I would like to have a VPN service to connect to when I am on a public wifi connection, but I don’t really want to use my work VPN for personal use. I tried a while back to setup an ipsec-based solution, but never got it to work.
If you happen to have home wifi set up with device running on dd-wrt, you can configure the dd-wrt VPN tunneling and it will work well with Android.
However, in order to connect there you either have to have fixed IP address from your internet provider or have to configure dyndns type of service.
Unfortunately, Facebook has not implemented HTTPS transport support for applications. Since everything but the main web site is connected to data feeds via an application connector of some sort, that means that all but the original auth data (to generate the token) are sent in the clear. This would not be an Android shortcoming, but rather a Facebook [and its app for Android] issue.
One of the most glaring examples of this problem is attempting to access any application from the Facebook Web site via an account set to HTTPS-only. The user is redirected to a page demanding that the account be set (on a non-temporary basis!) back to plain HTTP access, in order to reach the application.
There’s a secure site address now on all facebook apps, and I believe they are going to start enforcing all apps to provide that access soon.
– Google Reader, Google Maps, and Google Goggles, like Google Calendar, do their work in the clear. No encryption. I haven’t tried every other Google app, but clearly there’s a pattern here.
– Pandora appears to be sending music to you, in the clear as well. It issues requests over HTTP in the form
GET /access/[long number].mp4?version=4&lid=[number]&token=[really big string]&av=1.5.4
Somebody may be able to use this to extract music from Pandora to play later, without using the Pandora app. Or maybe they’re encrypting the MP4 file. Worth further investigation.
Just install something like AdFree or DroidWall and block the network traffic for the APP.
Yes it may still gather information like your phones IME, MAC and location but it can send it anywhere.
I use the application “Lookout” on my HTC Droid Incredible and it makes me feel a bit safer. I currently have the free version but am going to upgrade to the more comprehensive premium soon. Have you tried this software? The premium seems like it may help with some of the problems here and I’m curious what you think of it.
I am assuming that this is only a problem when surfing via WiFi, is that true? Also, I am a mid-level techie (I know a good bit but specialize in desktop support) who doesn’t know a ton about configuring VPNs and would like to know more. Could you point me to a good resource, particularly for doing this on my droid? Thanks!
I think the comment about about unencrypted Google Calendar traffic may be quite misleading.
First the post does not give any clue about which Android version and which device has been used and tested.
The author should know that there may be a huge difference between the opensource code released by Google and the code that is shipping on real devices. OEM can change whatever they want and that is why it is usually better to have “pure” Google Android devices.
Last, if you are really interested, get the Android code and read the the Calendar Sync Adapter code. You would find that ALL the traffic is using HTTPS… If not, but I really doubt it, this is a bug. Then just file a bug and it will be fixed asap.
So please, next time, be more accurate before you drop such assertion on Android.
My phone is a Motorola Droid X, running Android 2.2.1 — the most recent version available for my phone. The Calendar app is the stock one that came with the phone (“Build 2.2.1”). It would certainly be interesting to compare this to other Android phones. Nonetheless, the wireless traffic we captured clearly showed unencrypted calendar traffic.
You’re, of course, welcome to do your own network traffic sniffing.
http://www.cs.rice.edu/~dwallach/wireshark-google-calendar.png
What about trying on a NexusOne with latest “Froyo” or on a NexusS with “Gingerbread” and letting us know the results ?
Thx
Just disabling the GPS will not prevent your location from being sent. The phone can use phone triangulation and also can use WIFI to find your location in the same vein as Skyhook.
The SQL you saw with the Facebook app was almost certainly FQL – the latter is essentially the basics of SQL syntax applied to a predefined list of virtual tables. It’s common for apps using Facebook APIs to send FQL statements in their requests.
Also, while Facebook doesn’t use OAuth signatures, API requests do generally include a signature parameter that requires knowledge of a secret key specific to the application. With web apps, this is only stored server-side; since the Android app is more similar to a desktop application, the details may be different.
Use Droidwall 🙂
Droidwall is a cool way to restrict applications from having access to the network. Unfortunately, it doesn’t let you restrict applications from having access to internal resources like the GPS, which is what I’d really like.
To be fair to ShopSavvy it uses location information to try and find cheaper products in your vicinity using either the coarse location provided by cell triangulation or GPS location.
Given the battery eater that GPS can be I leave this switched off unless I require it for a specific app (Maps/Navigation).
As for Soundhound, I have no idea why they need our location…
Yep, I’d love the ability to deny access to a certain permission on an app, rather than just having to say yay or nay to using the app at all. It’s kind of understandable from google and the app developer’s perspective though – targeted ads are where they get paid. And 99% of the apps out there that want access to your location and the internet only use them for targeted advertising. If you give the user the ability to cut that off, they lose revenue.
What about giving the user the ability to limit the app to coarse GPS information? The app so restricted just gets GPS coordinates with the last few digits randomized, say, so it’s still accurate to the city but no longer can pinpoint you to one side of one building in the city.
Significantly, the app should be unable to tell whether it is getting precise or blurred coordinates with this scheme. Just zero out the last few digits, or whatever, and apps might be written to punish users for doing this. Of course, if it takes repeated GPS readings in a short time that jump around too much it might guess, so perhaps a random offset of up to a few city blocks’ radius in any direction should be added if the app is restricted, and this offset should change slowly and randomly over time without abrupt veers or discontinuous jumps. This slowly changing random offset can be global to the phone (so cooperating hostile apps cannot average their GPS values to figure out your position more exactly) and the radius can be user-configurable. The default for newly-installed apps would be to fuzz incoming GPS data; you’d have to explicitly opt in to a particular app having your exact position.
The biggest failing in Android’s security is the “take it or leave it” permissions model when installing apps. It leaves users in a tough spot of having to compromise their security for “must have” apps.
The way the Android Market SHOULD work is present you with all the permissions the app requests and then allow you to uncheck the ones you disagree it should have and then go ahead and install with those restrictions!
I would prefer to see a model where the user is asked at run-time whether X.app wants to see your contact info … Allow or Disallow. This way I can set perms for trusted apps and get untrusted apps to prompt me when they need access!