Mobile giant EE says that exposure of a critical code repository revealed by a teenage security researcher left no customer data at risk.

The company, which has over 30 million UK customers, was put on the back foot this morning after the security researcher, who goes by the handle Six, found that the company hadn’t changed the default username and password on the open source SonarQube platform, used by EE to audit code for vulnerabilities.

Both were still “admin”.

That gained Six access to the company’s private employee and developer APIs, as well as the company’s Amazon Web Service logins.

Luke Brown, VP EMEA at enterprise security specialists WinMagic said in an emailed statement: “We’ve seen quite a number of incidents these past few months where data has been left exposed on servers and open-source tools, but to have kept the default password on a repository created to audit code for flaws and vulnerabilities…. The irony won’t be lost on anyone! ”

He added: “That a company as reputable as EE could have made this mistake underlines the importance of proper configuration and security for any public facing services.  It should also serve as a reminder that under the shared responsibility model of cloud security, responsibility for data stored in these repositories falls to the organisation, not the cloud provider. As a result the need for consistent policies, password rules and specialised data encryption management has never been greater.”

Company Fixes Portal, Thanks Researcher

EE said in a statement: “No customer data is, or has been, at risk. We have now changed the login credentials to our sonarqube development tool and have blocked all access while we investigate this issue.”

The company added: “This is just one of the tools used by our web development teams to quality check our code in development. Our final code then goes through further checks, processes and review from our security team before being published.”

“This development code does not contain any information pertaining to our production infrastructure or production API credentials as these are maintained in separate secure systems and details are changed by a separate team.”

 

Bitglass‘s Steve Armstrong noted: “Ideally, when organisations use public cloud platforms, a third-party security control should be implemented to enforce granular, contextual user access control.”

He added: “By focusing on factors such as the device, the user identity or geographic location of the login attempt, it is possible to implement controls such as step-up multi-factor authentication.  This can mitigate these issues in real time preventing an unauthorised user accesses the cloud service.  Applying multi-factor authentication to any application, even those which natively do not support the function, greatly reduces the risk of misconfigured cloud platforms.”