Mobile app privacy insanity – we’re still failing massively at this

I was preparing for a talk last weekend where I wanted to show the sorts of bad mobile app behaviours you can readily find using Telerik’s Fiddler. Now I’ve spent quite a bit of time over the years looking at the behaviour of the apps we use every day on our phones, in fact it was nearly four years ago that I wrote Secret iOS business; what you don’t know about your apps and called out some really sloppy security practices. But since then we’ve had all sorts of things that have contributed to the overall awareness of online security; Snowden, more easily obtainable free SSL, countless attacks and so on and so forth. There are no longer any excuses for sloppy practices the likes of which I’m going to talk about here, you can no longer claim ignorance.

For the uninitiated, what I’m going to show in this post amounts to nothing more than looking at the requests that mobile apps are making over the web to back end services and inspecting the responses that are returned. It’s the mobile equivalent of looking at the network tab in the developer tools of your favourite browser. In this case though, I’m simply proxying my iPhone traffic through Fiddler which you can set up in about a minute. The particular patterns I’m looking for are discussed at length in my Pluralsight course titled Hack Your API First so if you want to understand the process in detail, go and check that out.

Let’s have a look at what’s going on.

Excessive and insecure tracking by third parties

People get rather sensitive about the tracking of personal info, particularly the broad aggregation of it across otherwise discrete services. We know, for example, that Google has a serious grasp on your movements by virtue of search, analytics, ads and then of course the broad permeation of these across entirely independent websites. That is simply the nature of the web today. (Incidentally, there’s a great story I did with a local TV network down here a while back called In Google We Trust which highlights this very well.)

In the browser world, tools like Ghostery and AdBlock have become massively popular as people elect to opt out of this degree of tracking. But in the mobile world, there is no equivalent, certainly not within a platform like iOS where third party apps can’t be used to intercept your traffic. The closest you can really get is by using a product like F-Secure Freedome as a VPN which can strip trackers, but only if they’re served over HTTP and then you’ve got to be comfortable with inviting them to handle your traffic. (Incidentally, I’d trust them more than just about anyone and it’s a great VPN solution.)

Here’s where it all gets a bit tricky. Take this app from Aussie Farmers Direct:

Now what sort of tracking would you assume is going on here? No ads, no commenting engine about the worst case scenario you’d assume is a degree of tracking like Flurry was doing in the earlier mentioned secret iOS business. Actually, it shouldn’t even be that bad because you can longer track unique device IDs.

As soon as I log on, I see two requests:

The first is the logon with my credentials and fortunately this is done over a secure connection. Ok, it’s a fundamentally broken SSL implementation, but that’s a story for another day. The second though, well this one is a bit more worrying:

This is all going to a third party tracking service called Gomeeki. No wait – they’re a “Multi-Screen Engagement Agency” – my apologies, let’s move on. The data towards the bottom is URL encoded so let me explain it clearly here:

1. Customer ID
2. First name
3. Last name
4. Home address
5. Latitude to 14 decimal places
6. Longitude to 14 decimal places

Frankly, this alone is way too invasive and I had no idea that by doing some grocery shopping I was going to be telling this org I’ve never heard of my name, exact physical location and corresponding home address. Tracking IP addresses is one thing and there’s a certain amount you can assume from that in terms of physical location, but tracking your precise location to 14 decimal places and sending it off to a third party is not cool. Same again with my name and address – why does Gomeeki need this?!

But of course the really worrying thing is that the data is sent in the clear. No transport layer protection at all, not even bad transport layer protection like with the login. This is my personal info flying around the web with zero protection and that’s an entirely unsatisfactory state in this day and age.

I did actually wonder for a moment if perhaps the app developers were misusing Gomeeki’s service by requesting it in the clear but no, the POST request to http://afdapi.dev.gomeeki.com/api/storeLogin?API_KEY=123456 returned HTTP 200 and an encouraging response body:

So by all accounts, Gomeeki successfully processed the message over HTTP so there’s a major problem right there when we’re talking about this class of data. Perhaps they also support HTTPS though? How about we try https://afdapi.dev.gomeeki.com/api/storeLogin?API_KEY=123456 and see if it loads?

It’s never real encouraging when your browser is telling you that “attackers might be trying to steal your information”! Of course the site is simply not meant to be loaded over HTTPS which is the real issue, but the cert this request returned is also a bit worrying. It was issued to ubiquityplatform.com and if we head over there we find what they do is:

manage your digital landscape, drawing strategic insights from your data to foster closer engagement with users across multiple channels and devices

“Strategic insights from your data” (and I think what they mean is my data) is a nice way of describing a tracking service. Their site then presents you with a login page also with no transport layer security (seeing a theme here?), who knows what lies beyond that.

It’s not like they haven’t put a lot of thought into the whole Farmers Direct thing either, in fact Gomeeki features them on their home page:

The bottom line here is that both Aussie Farmers Direct and Gomeeki have questions to answer about both the sensitivity of the data they’re tracking and the insecure fashion in which they’re doing it.

Invasive personal device data tracking

The other one that really stuck out at me when having a browse around at API comms was PayPal. Let’s take the login screen:

Now these guys should know better and whilst they’re not sharing my data with other parties (at least not directly via the app) and they are sending it over a secure connection, they’re obtaining data from me that I had absolutely no idea about. How much data? Give this a go:

This is when logging onto PayPal and it’s a veritable shopping list of personal info. I’ve highlighted the key bits but let me call out the extra personal ones here:

1. BSSID: This is the unique device ID of my home router which is the same as the MAC address. Google got themselves into hot water for siphoning this up via their mapping vehicles a little while back because that one unique ID ties back to my precise device.
2. Device model and name: You could argue that comparable information is sent via your browser courtesy of the user agent, but that would only apply to the model and not the name of the device which is explicitly not passed in requests. This is private – it’s my device name.
3. Internal IP address: The internal address assigned to my iPhone via the router when it associated to the network. This can give a sense of how many devices are on the network.
4. Location: There’s my lat and long again and for all the same reasons I don’t really want to share it with Aussie Farmers, I also don’t really want to share it with PayPal.
5. SSID: We’re talking about the name of my internal network here. I name mine in a non-identifying fashion because frankly, I want to keep it somewhat private and that’s from those in my immediate vicinity, let alone those on the other side of the world.
6. Storage space: Ok, so it’s a 128GB iPhone, do they really need to know that? Back to the user agent comparison, this is not the sort of stuff that’s typically “leaked” by generic requests to the web because it’s an internal metric of no external consequence.

Hang on – what do you mean you didn’t know they collected this data from you – you read, understood and agreed to the terms and conditions including your privacy rights, didn’t you?

In order to help protect you from fraud and misuse of your personal information, we may collect information about your use and interaction with our website or PayPal Services. For example, we may evaluate your computer, mobile phone or other access device to identify any malicious software or activity.

Keep in mind also that data like BSSID and SSID are now publicly searchable data thanks to Wigle. Even if you seek out the privacy of a VPN and disable your location services, PayPal still has the potential to join the dots and nail you all the way down to a very precise global location.

The thing with privacy is this and I like the way Mikko Hypponen often explains it: It is not necessarily that I have anything to hide, it’s that I don’t particularly want to consciously share it. It’s this whole creepy line thing where there is a point at which this kind of tracking becomes invasive and while we might not be able to define exactly where that is, we know when it makes us feel uncomfortable and for me, this level is personal data is up there.

Oh – and before I get the “But this is for your security” or it’s to “Enhance debugging” or some other similar excuse, those belong with Lenovo’s Superfish being designed to enhance your browsing experience. Most of these attributes are invasive, of questionable functional value and none of them were “consciously” opted into because frankly, burying them in terms nobody will ever read is as good as hiding them from public view.

Lack of SSL

Frankly, I’m amazed that we’re still talking about this one in 2015, but here we are. In times gone by, you could open up just about any non-mainstream app on your device (and there were notable exceptions there too) and witness credentials being sent in the clear. It was either that or the app wasn’t validating the cert which is pretty much the same end result.

Things are different today, however, in fact they’re so different and SSL is so ubiquitous, that even loading up this menu on the Nando’s app is done over a secure connection:

And here we have everything securely transferred:

Ok, it’s public data anyway so you could argue that SSL is entirely pointless here but hey, SSL all the things right? How about this thing:

Naturally this is exactly where you would have SSL as it’s the point at which you share the sensitive bits. So let’s login and see how that goes:

Oh c’mon! You protect the amount of protein in your “A-grade chicken” but don’t protect my password?! And then to really top it off, you send me my sensitive personal info including date of birth and mobile number over a clear connection?! And you send back the password in the response just in case someone didn’t already grab it via the insecure request! Oh and there’s the whole gender, birth date and mobile number which you really need to be sent insecurely as a response to simply logging on…

Now I know what you’re thinking – Troy’s gone and forgotten to obfuscate his password and you’re right, I missed it. Let’s go and reset it then:

Don’t worry about the button saying “Retrieve Password”, that’s a just a colloquialism and there’ll really be some sort of secure password reset feature behind it, right? Let’s “retrieve”:

Don’t worry, they’ve got me sorted (allegedly)! That was indeed the password that I generated (thank you 1Password) and clearly it has been stored and transmitted insecurely. The first thing I did after this exercise was to change it and submit the new one back over an insecure connection. The second thing I did was go to report them to Plain Text Offenders, then discovered they’d already been featured, two years ago. It’s the UK version, but you’d assume some cross-communication, right?

Wrap up

I feel a bit matronly saying this, but I’m disappointed. No really, I was sure things were looking up there for a bit and it seemed harder to find egregious examples of security shortcomings in a random selection of apps. Whilst this is but a very small selection here, the problems were found very quickly and are extremely worrying. Both Aussie Farmers and Nando’s have serious security risks in how they handle data and as for PayPal, you may not call it a security risk but it’s sure as hell an invasion of privacy. The network I’m connected to when using their service and where I physically am in the world is my business and I don’t particularly want to share it with them. Perhaps I should just stick to the browser that doesn’t leak this class of data yet one would assume is still sufficiently secure.

What has me a little worried with all this is that we’re heading in a direction where we have more data to share via more channels which are all racing to be first to market with something. This week the Apple Watch will hit and it will arguably be the point at which wearables seriously take off. Now we’re talking about very personal data – health data – and there will be all new ways of sharing it. But it’s to improve the experience to you, the consumer, right?

Learn how to hack your API first

Everything in the post above is based on observations of my traffic from my device across my network and as I said earlier, it’s the equivalent of watching traffic in the browser dev tools. Everything above can be very easily observed just by opening apps and watching how requests and responses are handled. If you’re interested in learning more, check out the Pluralsight course I mentioned, Hack Your API First:

This course runs you through everything described above and a heap more, including things you don’t want to be doing with other peoples’ systems! But it will teach you how to probe for vulnerabilities in your own systems so go and check that out if you’re building this class of app.