As users become more and more accustomed to ensuring their data is safe when using the Internet, one area that it's still incredibly difficult to ensure your own safety is when using smartphone apps. There is no address bar to check for https:// and you can't manually inspect a certificate or even check if their is one being used. Often with no idea of how our data is being sent across the Internet, we are left to either trust the app implicitly, or simply stop using it.
Introduction
When using a web browser, you can verify if the site you're visiting is being loaded over a secure connection by looking for https in the address bar and verifying the certificate presented to the browser. Unfortunately a mobile application rarely presents the user with such options and it can be quite difficult to find out if the application is sending your data in a secure fashion. To determine whether or not an app is sending data securely I'm going to launch a Man in The Middle (MiTM) attack against my smartphone. I'm going to be using my WiFi Pineapple to channel traffic through my computer for Wireshark to try and read. If the traffic is being sent without encryption then it will be a simple task to steal data from apps as I use them. Even if the app is using Transport Layer Security (TLS), I'm going to be using Fiddler, an intercepting proxy, to insert itself as a MiTM and substitute SSL/TLS certificates on the fly. Hopefully the apps I'm going to test will be able to stand up to the above scrutiny and not leak sensitive data as I use them.No Security Whatsoever
When you visit my blog you can see https in the address bar and be pretty sure that you're communicating with me and that we are communicating securely. If you were to login to my site and insert user credentials, no one would be able to steal a copy of them as they zip around the Internet on the way to my server. Likewise, when you load a page you can be sure that the content has remained private and has not been modified during transit. Mobile apps don't present the same ability for users to make these manual checks and as such, we're left to trust the application.
Blackburn with Darwen Borough Council
The first app on the list was one from a local council, Blackburn with Darwen Borough Council, available on Google Play here. When the app launches you're presented with the login screen. Happily, I type in my username and password and hit the 'Login' button.
Right there, are my email address and password being sent over the air and off into the wild, in plain text. This, right away, highlights the kind of problems we face in smartphone apps. I can't see an address bar in the app so I can't check if the content is being loaded over a secure connection. Further to that, I can't inspect any elements in the app much like I could in a browser to verify the form action was indeed secure. This is an application from a local government organisation so you may well expect it to be trustworthy. Sending user credentials without protecting them is a serious error. Upon contacting Blackburn with Darwen council they put me in contact with their software provider who worked to implement a fix. Whilst the new version of the app does use encryption, the site scores a rather poor score on the Qualys SSL test due to poor protocols and ciphers. You can see the score here.
RightMove
Next up was a large organisation, RightMove. As expected from a large company they have their own smartphone app available on Android and iOS and you can grab the Android version here. RightMove advertise on TV and make many claims about being the biggest and best property search website in the UK. If they're the best at what they do, surely they made sure their mobile app was secure for their users?
As we can see, my credentials are being sent off into the wild without any protection, again. This time, instead of being data attached to the request, they're actually being sent as GET parameters right there in the URL. This is generally worse because any device with access along the way, like a proxy server or gateway, will often record URLs as data passes through. This would usually only capture the URL, and not any POST data, which is why GET parameters should be avoided and certainly not contain user credentials. There's also a fairly good chance that the web logs on the server are a script kiddies dream and your browser history probably contains sensitive data now too. Great... I contacted RightMove about the security on their website and in their mobile application several months ago. Progress has been made on the website and in their mobile app and your credentials are now encrypted during transit. You can read more in my blog about RightMove here and see the Qualys SSL test results for the api subdomain here.
Partially Secured Transport Layer
Following hot on the heels of apps that run no transport layer security, are apps that only secure some of their data in transit. Whilst I suppose you could argue it's better to encrypt some traffic rather than no traffic, by actually encrypting any of it you're acknowledging the need for encryption. At that point you should also acknowledge the need to do it properly and encrypt the exchange of any and all data that has even a whiff of sensitivity.
Domino's
Moving on to Dominos, available here, I was pleased to see that most of the traffic was being sent over a secure transport layer. I still had to use the word 'most' though... As it turns out, as soon as you fire up the app, it's keen to scoop up and report back plenty of information about you and your device.
That's your device UDID, IMEI and MAC address all being sent over the air without any encryption at all. I'd consider that to be some incredibly sensitive data. Interestingly, along with other details like your device make, model and IP address I'd have to argue that this certainly qualifies as personally identifiable data. I mean, who else would that data identify?! It certainly shouldn't be sent in the clear, that's for sure.
I tried to contact Domino's for comment on several occasions but never heard anything back, they did find the time to stop by my LinkedIn profile and check it out though.
Since reporting this to Domino's, the app has been updated to send all data across encrypted connections, but they haven't reduced the amount of data they collect. As soon as the app starts, it immediately grabs everything it can and fires it off to a site that has another poor Qualys SSL test result, seen here.
Argos
As a pretty big retailer in the UK I was pleased to see that most of the traffic was being sent over a secure transport layer in the Argos app. But, again, I still had to use the word 'most'. We do have a little leakage of data with things like any search terms you enter and your location being sent over an insecure connection.
The application clearly has the ability to send data over a secure transport layer so when you see mixed connections being used it really doesn't make any sense at all. Once the data you're transmitting becomes sensitive enough to require encryption, you should never fall back to using http. This is especially the case when things like a session id or cookie are being passed backwards and forwards. Prior to publication I checked over the Argos app again and found little had changed. There is some additional data being sent off to metrics.argos.co.uk, like my device and software details also in plain text, but that's about it.
Natwest
I checked all of the mobile applications for every high street bank in the UK and was pleased to find that all of them transmit sensitive information securely. There were only a couple of little things that I picked up on, and that was mainly that things like Terms and Conditions were generally loaded over HTTP. As I've demonstrated previously, SSL/TLS isn't all about privacy, it's also about protecting the integrity of data in transit. As these are the first thing that the app loads when you launch it, allowing an attacker to manipulate this data carries certain risks.
If an attacker could fashion a believable login form out of HTML at this point, they may well successfully trick a user into entering their sensitive data. After all, we are inside the official app and surely this is all secure, right? At the time of publishing, the Natwest app still loads content over HTTP inside the app. I also noticed the entire FAQ section is HTTP too.
Getting It Wrong
To ensure that your connection to a site is secure, your browser has to do several things. It checks the certificate it received is actually for the site you're visiting, that the certificate is valid, and that it's signed by one of the trusted root certificates it holds. If that's all good, and the certificate hasn't been revoked, the connection can continue and we can rest assured that it's secure. If someone switches that certificate as your data travels over the Internet, to try and trick you into using their certificate, your browser will detect it and warn you.
Because the certificate I injected wasn't signed by a trusted root certificate, the browser wouldn't accept it and will not allow me to connect to the site as we can't be sure the connection is secure. We should hope to see similar behaviour in smartphone apps too. We don't want our data sent if it's not secure, do we?
HungryHouse
A big concern when using smartphone apps is the security involved when using debit or credit card data. To start with, the HungryHouse app was sending my personal details (name, address, post code and phone number) over HTTP. Not a great start.
Thanks for that guys, I'd like to think that people at least try to take a little care of my data... Fortunately, when it comes to my credit card data, they tried to secure it. I say tried because the app doesn't actually validate the SSL certificate provided by the server. That allows me to inject my own certificate and as soon as someone places an order with the app...
Yep, you can wave goodbye to your credit card details. Taking into account an attacker already has your name, address and post code, that's a bad situation to be in. I contacted HungryHouse in December and got the generic 'your query has been passed to the appropriate team' response. Over 3 weeks later in early January and I decided to chase them, I hadn't even had so much as a response.
I disclosed a serious security vulnerability that exposes Credit Card data to @hungryhouse almost 3 weeks ago. Not even a response guys?
— Scott (@Scott_Helme) January 8, 2014
Once the information had been made public I received an email from them in short order and things progressed very quickly with a patched version of the app available on the store within a few days. They even invited me to become a beta tester for them on the Google Play store so I could take a look at the fix before it went live. You have my address if you feel like sending me a free pizza for that guys :-)
What can we do?
As a consumer or user of an app, there isn't really a great deal that we can do. Inspecting the traffic of apps that we use, and only choosing to use apps that secure the transport layer, is a bit of an arduous task. I think that developers need to start taking more responsibility in securing user data, both in transit and at rest. Many of the above apps have associated websites and if they tried to run with the equivalent lack of security there, things would get picked up on very quickly. Just because the user doesn't have the same feedback regarding security within an app it doesn't mean we should be seeing lax approaches by comparison.I've often thought of things that can be done on the OS to improve this situation too. A flag that a user can set on an app to only allow secure communications, or a flag that developers can set, like a permission, to inform the OS that we only want to use a secure transport layer. This way a user could identify that an app is either going to communicate securely, or not communicate at all. Of course, this opens up the questions of SSL/TLS protocols, no point allowing SSLv2 and calling it secure, options like the cipher suites and then certificate validation and even more. Something like this could quickly turn into a total nightmare to manage and implement. I'd be interested to hear what readers think or if you have any ideas on how we can inform users of the security in the background when using smartphone apps. Please drop your thoughts in the comments below.