Security issues with the ‘My EE’ app

At e2e-assure, we like to play our part in making the web safer for everyone.

One way we do this is by responsibly disclosing security vulnerabilities. We go out and look for security vulnerabilities in products, then we tell the companies involved about them. We do this so that companies can fix these problems before the 'bad guys' find them (and use them for nefarious purposes).

Disclosing these vulnerabilities can be surprisingly difficult. Whilst many big companies have recognised 'Responsible Disclosure' programs (like Google's Android Security Rewards Program, a surprising number do not. This makes it challenging to report these issues, or sometimes even be taken seriously (if we get a reply at all).

Unencrypted data sending from the 'My EE' app

We noticed that the 'My EE' app was sending several sensitive, user-identifying details back to store.ee.co.uk without using encryption. Without encryption, these details can easily be intercepted and used for no good.

These details included:

• IMEI – a unique number identifying an individual mobile phone
• Brand ID – identifying the mobile phone brand
• SIM Operator ID Number – identifying the SIM provider
• IMSI – a unique number identifying an individual SIM card
• Phone Make and Phone Model
• Current phone software version (including build number and versions)

We noticed that although the individual IMEI was encrypted, this and the rest of the information was sent 'in the clear' with no encryption, meaning that an attacker could easily collect all this information to be used in a later attack.

As well as all these details, the app was sending back both a plain-text username and password in the clear… for an internal EE system!

Publicly-exposed EE system through API

All the data above was sent using a SOAP POST method to http://store.ee.co.uk/orial/live/default.asmx – an API page which was publicly accessible on the web! Included along with the data was a username and password for the system (unencrypted and in plain-text).

Not only could we access the API page (by browsing to it), we were presented with documentation for the API hosted on the page. So not only had we been given the system and the password for it, we were being given instructions how to use it!

Disclosure

Although EE have now fixed this vulnerability, it took more than 2 months for this to happen. We also found the disclosure process particularly difficult, arduous, and time consuming. Taking into account that EE are a large, UK-wide mobile network provider with extensive resources, we encountered the following issues:

• No defined disclosure program or scope for testing
• No listed contact for disclosing vulnerabilities (i.e. a Security Team)
• The EE Support team being unable to deal with our request for a security contact
• Lack of reply from the security team (until we informed them we would disclose)
• Lack of updates or notifications on the fix (or a timeline for this)

These issues could have been avoided if the company had a defined Responsible Disclosure policy, saving much time and effort for both parties.

Leading by example…

We want the Responsible Disclosure process to be as smooth as possible for both security researchers and organisations.
We also believe that we should lead by example, which is why we are unveiling our very own Disclosure Policy. If someone finds a security vulnerability on our website or our systems, we want to know about it, fix it, and credit them for the help.

Please find our new disclosure policy at e2e-assure.com/responsible-disclosure