What’s going on?
Hey folks, what’s up!? As you can probably tell by the title, today we’re going to go over a very dumb mistake made by EE (the largest mobile network provider in the UK!) that lead to the exposure of 2 million lines of private source code. Like my last blog post, it’s also about EE, and something I discovered and reported a year ago. I want to write about some of my old finds before I publish anything about recent and new discoveries and research (other bugs I’ve found, 0day research and more!), just to get them out of the way and have them documented (for myself!).
I had spent the whole week reporting security issues to completely random telephone companies (Verizon Wireless, Orange, T-Mobile, etc) when I decided it was time for EE to get some love. The funny part about this story is that there’s not actually any exploitation or hacking involved! I started with the basic reconnaissance that an attacker would; I scanned subdomains, DNS records, ports, certificates, services and did some basic Google dorking. After the scanning of subdomains, I scanned for open ports on each to determine which ones actually had services on, were externally reachable and so on. I started with making a list of subdomains that had a webserver running by picking out all the subdomains that allowed access on the following ports:
There were a LOT of subdomains with webservers on. To make my life easier, I proceeded to use a tool called
FortyNorthSecurity to capture a screenshot of every subdomain that was running a webserver on a common port, making it easier for me to pick out subdomains with potentially interesting behaviour! The main one that caught my eye was called:
Since I’ve done a lot of development work myself (independently), I knew what SonarQube was. SonarQube is an open source platform developed by SonarSource for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities in 20+ programming languages. I decided to navigate to aforementioned subdomain (
sonarqube.intdigital.ee.co.uk) to try and determine the verison of SonarQube they were using, and if it was an old version, if it was vulnerable to a public security issue. To my disappointment, it was the latest version. I decided to try some common default credentials to login to the application, such as:
And to my surprise, the username
admin with the password
admin actually worked. I was inside of EE’s SonarQube portal that was used to audit all of their private internal source code for security vulnerabilities; millions and millions of dollars worth of code, sat right infront of me.
After a swift glance over some of the code, to verify that it was indeed their internal applications source code, I came across the following (sensitive data partially redacted for obvious reasons):
The above image shows the leakage of access tokens used to authenticate to one of their internal employee tools. In the hands of a malicious person, this could have been disastrous. Even if an attacker did gain access to the portal, but overlook the leakage of their access tokens and AWS keys, they could easily have dumped all of the code (by using wget recursively, for example) and analysed the source code of many of their applications for critical security vulnerabilities. To show what risk this could’ve presented, I will show you a screenshot of the inside of the development branch for their web-services (ee landing page, customer portal, payment processing, etc):
In the image above, you can see some of the projects in the web-service repository include but are not limited to the functions used for billing management, retrieval of device details, direct debit contracts, and SIM activation among much much more. Again, this could’ve been disastrous.
I swiftly alerted EE via Zack Whittaker (I had no responses when contacting directly) and it was patched immediately.
Daley Bee - https://twitter.com/daley