Dear Emirates, your mobile app has a security problem

TL/DR - the Emirates mobile app included an empty override for the OS built-in X509TrustManager, making it accept any TLS/SSL certificate served by a man-in-the-middle, and thereby exposing customer data, credit cards, etc for mobile app users to third parties. That has been fixed now. See updates added at the bottom of the blog post for details.

Dear Emirates,

I fly with you a decent amount of miles every year. I do that because you provide good service, good food, good entertainment, all at a good price, and I sometimes need to fly to places that you fly to. I just got back home from a 6h+16h+16h+6h roundtrip on EK flights on your A380s, and I had fun all the way. In short, I am a happy Emirates customer.

Around a month ago, I received an email from you, pitching your mobile app, so I decided to give it a try. I think my habit of flying with you puts me within the demographics targeted by your mobile app, and I was hoping that the app would be useful to me.

Now, most users will just install a mobile app and use it if it provides a friendly enough user experience and user interface. However, I like to dig a bit deeper before I trust any mobile app. The underlying reason for that is that I think the mobile app industry is a bit of "wild west". Or maybe a better analogy would be "Vietnam war". A lot of companies desperately want to have a mobile app, and as a result they will hire any company to build one, regardless of if said company have the competence needed to build a good and secure app.

One of the first thing I checked after installing the Emirates app was if transport security was properly implemented. It turns out, it was not. At least not the Android app I installed on my not-too-ancient Samsung device. In short, transport security is a mechanism for protecting data by encrypting it as it travels over the internet often referred to as https, ssl, or tls, and is used to ensure that a web browser or app is getting data from and sending data to the correct servers and to protect that data from eavesdropping.

I immediately raised this to you through several channels: email, twitter direct messages, the app's feedback form, and public tweets. However, it seems like my feedback didn't make it to the right people within Emirates. I know you have a lot of competent people working for you in a variety of functions, and I hope that applies to information security as well.

Do you have an inhouse infosec department? If so, please have them review your mobile app. They will understand what this is all about.

A more detailed explanation of the problem your app suffer from follows. I will try to explain this in not-too-technical layman terms to make it easier to understand for non-technical people.

Whenever you access a website serving or consuming data that need to be protected, that is usually done over a secure protocol a.k.a transport security, sometimes referred to "SSL" (now deprecated), or TLS. When a web address starts with "https", the web browser you use will connect to the web server using a (usually) secure encrypted protocol. One key part of establishing this connection is verifying the identity of the server you're connecting to. This is done using something called a "certificate", "SSL certificate", or "TLS certificate". A certificate is usually signed by a third party, a "certificate authority" or CA. Their cryptographic signature guarantees that a web server or app server belongs to the domain it claims to belong to.

Your emirates.com website has a certificate, and likewise does your mobileapp.emirates.com server which provide your mobile app with access to your reservation system, your CRM system, to Boxever, etc.

If you open the emirates.com website in a web browser, you will see that the address bar shows a padlock icon, and that the address has a "https" prefix. This means that the connection is secure, and that the certificate presented by the site is valid and signed by a CA trusted by the user's browser and device.

Now, if a bad actor would try to intercept traffic between a user's web browser and your website, they could try to do so using a man in the middle (MITM) proxy. In short, this is a program running on a system somewhere between the user and the web server they're trying to access, but it terminates the secure connection and reestablishes a new secure connection to the server. This allows it to read all communication between a browser and a web server. However, this is only possible if the web browser, app, and device used will trust the certificate served by the MITM proxy. If not, the web browser will show a warning to indicate that a secure connection could not be established.

MITM proxies are not uncommon on corporate networks, on public wifi networks such as the ones available to hotel guests, at airports, in coffee shops, etc. A correctly configured device, with a modern browser or correctly implemented app using transport security will normally warn a user if a MITM proxy is trying to intercept secure connections. For unsecure connections, the user is generally unaware that their traffic is getting intercepted.

If a user tries to access the emirates.com website from a mobile through a MITM proxy using a self-signed certificate, or a certificate signed by a certificate authority that is not trusted by the device, the web browser will display a certificate validation warning that looks something like this:

The same thing applies to mobile apps: if a mobile app need to communicate with a backend system somewhere on the internet, that should be done over a secure protocol. This is usually done using the same https (TLS) protocols used by web browsers, with the only difference being that apps does it "behind the scenes" without showing the user an address bar. The Emirates mobile app communicates with servers such as mobileapp.emirates.com, boxever.com (for tracking user behavior), and a few others.

Some mobile apps do this in a correctly implemented way; they validate the certificate presented by the backend server, and ensures that it was issued by a certificate authority trusted by the device the app is running on. Some don't. Your mobile app is one of those that will trust any certificate, regardless of if the issuer is trusted by the device or not, including self-signed certificates.

The following screenshots shows how Google Maps, Google Play Store, and Uber react if they are served an invalid certificate; those apps will show the user a warning and will not attempt to communicate with a server whose identity appear invalid or can't be verified:


What is shown in the screenshots above is the correct way for an app to act if it is served an invalid certificate.

The Emirates app however, will under the same circumstances, when connecting through a MITM proxy serving an invalid certificate, happily continue working without showing the user that anything is wrong:


Behind the scenes, the app establishes TLS connections without validating certificates, and exchanges information that should have been protected. It does so even if all communications goes through a MITM proxy, and it does so even if that MITM proxy serve invalid certificates. Some of the data in your "skywardsDomainObject" data even expose things that you probably want to keep internal to your CRM system, things like Emirates staff user names for internal systems, Skywards "member score", passenger importance rating, downgrade/upgrade eligibility/non-eligibility, etc. In the screenshot below, among other details you can see that my "memberScore" value is 05.3228, and my account was at one point updated by a user with the login "CRISOPS", and my "impRating" is "NIP", etc.

Dear Emirates, this is not good. This is especially bad if an app handle (and exchange) sensitive data about a user, things like their travel plans, travel history, travel documents, credit cards, etc. Your app handle that kind of data, data that should be protected when it is transmitted over the internet.

The credit card industry has a standard called PCI-DSS that was created to ensure that companies accepting or processing credit card payments protect card holder data in an appropriate manner. One of the requirements of PCI-DSS specificially state that server certificates must be validated before sending payment/card data over the internet. Dear Emirates, your app fail on complying with this requirement, and shouldn't in its' current state be trusted with credit card details.

As mentioned, I have tried to raise this to Emirates through several channels over the course of a month, but seemingly without success. This is another attempt. Hopefully this blogpost can make its' way to the Emirates infosec team, so that the app can be fixed and that I and others can use it without exposing our data to unknown third parties.

Meanwhile, if noone on your side read the feedback submitted through the app's own feedback form, you may as well remove that feedback form while you're at it:


Dear Emirates, you have my contact details. If you need any more information about this, please reach out. I want to be able to use your app, but I can't do that until you fix this (and a few other) bugs or implementation flaws. I am happy to provide your team with additional details on what they need to do in order to make your app as good as your inflight service.

Update #1

Update #1: It looks like this behavior was implemented intentionally. Hey, Emirates and Tigerspike, if you want to fix this, have a look at this...

Update #2, 26 March 2017:

The original content of this blog post will be returned, after the issues raised in it has been corrected by Emirates. They are working on a fix, and a corrected version will probably be available within a few days.

In the meantime, if you are a user of the Emirates app for Android, and if the version you have installed has a version number 2.7.0 or less (or released prior to 26 March 2017), I would recommend that you do the following:
1) Uninstall the app temporarily. Reinstall it after a new version has been released by the Emirates/Tigerspike team.
2) Log in to your Skywards account on emirates.com, click on "account settings", and change your password.
2b) If you have used the same password elsewhere, change it on all sites/apps/etc where you have used it. ...and stop reusing passwords across sites...
3) If you have paid for a booking through the mobile app while connected over public wifi at a hotel, airport, coffee shop, or similar: ask your credit card issuer to issue a new replacement card with a new PAN/account number for you.

Update #3, 2 April 2017:

It looks like Emirates have released an updated version of the app, dated 29 March and available through Google Play store on 2 April, with a fix for the 'missing' (overridden) certificate validation.

Some other minor issues raised below (CRM data leaks, etc) remain, but it is my understanding that they are working on those as well. Since the main issue originally raised has been addressed, the original contents of this blog post have now been restored, after being offline while EK worked on a fix (read: removed the few lines of code I pointed out in 'update #1'). Hopefully someone else will find this useful if they're planning to build a mobile app for their customers.

I have not yet seen any official communication from EK to app users regarding this issue, but I do hope that they will at some point contact their users with information on what happened, and steps users need to follow to protect accounts that have or may have been exposed to third parties as a result of this. In the meantime, if you have used the app, see "update 2".

I still do not have contact details for the EK infosec team, but I hope they will learn from this and make it easier to contact the people who are responsible for handling this kind of issues. Clearly, the usual contact channels are not suitable for reporting infosec issues of a technical nature.

Finally, I think some of the good advice raised by Troy Hunt in one of his recent blog posts would apply here as well, especially when it comes to making it easy to report security related bugs and ensure those reports reach the right people:

• Make it easy to submit security reports
• Treat security reports with urgency
• You must disclose
• Disclose early
• Protect accounts immediately
• Avoid misdirection and false or misleading statements
• Don't be vague
• Explain what actually happened
• Keep customers updated
• Apologise

See:
https://www.troyhunt.com/data-breach-disclosure-101-how-to-succeed-after-youve-failed/

Update #4, 18 April 2017:

Still no communication from EK to app users. I guess they decided to file this one under "Let's pretend it never happened."