EE have released a patch for their BrightBox routers which addresses some of the issues that I disclosed. Whilst the device now takes more care of user credentials and doesn't seem to be exploitable remotely, it remains vulnerable to CSRF. This potentially allows an attacker to change almost any configuration setting on the device. The biggest risk is an attacker changing the DNS servers on the device, allowing them to intercept all data that goes through your Internet connection. Further to this, several other security vulnerabilities have come to light that pose a significant risk to EE customers.
Patch Day
Whilst EE were reluctant to provide me with a copy of the firmware update file, and reluctant to tell me why, they did agree to flash the firmware onto my device over the broadband line. This means that anyone that doesn't yet have the updated firmware will have to continue to wait, and anyone that uses the BrightBox as a secondary device, like an extra WiFi AP, will not be able to get the update unless they connect it back to the modem directly. It seems like the roll out of this firmware could be done much more quickly if EE would allow their customers access to a critical security update. There also hasn't been any form of announcement on the EE website regarding the vulnerabilities or the need for routers to be patched.
2 out of 3
Post patch, the BrightBox now seems to take much better care of my user credentials. It doesn't leak access to the files in the cgi folder any more, the router no longer transmits the admin password to the browser and the remote management feature seems to have been completely removed this time. Unfortunately, EE haven't fixed the CSRF vulnerability, which is going to be addressed in a subsequent patch. With a successful CSRF attack, an attacker could alter the DNS settings of your router. Once that's done, they would be able to intercept all of the Internet traffic from your house. That's the traffic from every single device in your house that uses the router to connect to the Internet, like your laptops, computers, smartphones and even games consoles. A scary prospect. Whilst a CSRF attack does require a little engineering, it is still trivially easy to carry out. The code required to carry out the CSRF attack can be embedded in any webpage, potentially even a legitimate website, and you can find some references in my demo page from my previous blog. The dangers of such an attack have recently been highlighted by CERT Polska (the Polish Computer Emergency Response Team) who discovered a large scale attack on Polish Internet users. Exploitable routers had their DNS server settings changed with the intention of intercepting online banking traffic. CERT Polska have also warned that they believe the attackers will target users in other countries using similar techniques.
Additionally, even though EE have developed a new file, changePwd.cgi, to handle the password change feature, the existing apply.cgi will still allow you to reset the admin password without providing the existing password. That means the reset admin password option on my demo page still works.
Accessing account credentials for EE customers
Whilst testing the latest version of the firmware I also discovered a new way for an attacker to steal user account credentials directly from EE. The BrightBox routers use a protocol called TR-069 to request configuration data from an Automatic Configuration Server (ACS). If the BrightBox boots up and doesn't have any credentials to connect to the Internet, it will query the ACS and ask for a configuration. This is how EE support can routinely suggest a factory reset as part of their troubleshooting steps. The device will pull down the configuration automatically, meaning the end user doesn't have to set the router back up.
It appears that the only information the ACS requests from the BrightBox is its serial number. The serial number of each device is unique and it seems to be tied to the customer that the device was shipped to. So, after a factory reset, when my BrightBox makes a request to the ACS, it returns my username and password for the router to connect back to the Internet. This process seems fairly standard across modern equipment and in itself isn't anything to worry about. That is, until you consider selling your BrightBox. Anyone who purchased your second hand router can hook it back up to their EE phone line (I've not tried this with another provider) and the device will request a copy of your account credentials that are then downloaded onto the device. Not so good, and, there's nothing you can do to prevent it except not sell your router. What's even worse is that in my previous blog I was able to connect to the device over the serial port and one of the configuration options that I could change on the device was the serial number itself. Here you can see the existing serial number marked by the green arrow, and the new serial number I'm about to flash onto the device marked by the red arrow.
I think you can see where I'm going with this. With a willing volunteer sending me his device serial number and giving me permission to try, I flashed the new serial number onto my router and performed a factory reset. Once the device came back up, a quick navigation through the web admin and I'm greeted with this.
As it turns out, the ACS is happy to hand out user credentials based purely on the serial number you provide! The fact that this serial number is being provided from a telephone line that is not associated with the account in question doesn't seem to be a problem. An attacker can simply sit and insert serial numbers to retrieve the account data associated with them. Now that I know it's possible to retrieve user credentials using just the serial number, I wanted to see if there was a more efficient way than flashing the serial number onto the router.
Update 10th Feb EE responded today with the following regarding my disclosure about the ACS;
"In response to the points you have raised, the ACS system is secured with a unique username and password for every user, so cannot be exploited in the way you describe. The only reason this was not the case for a short time on your router is because we had removed your router from the network, and then reinstated it so you could test the firmware."My router received the firmware update from EE on Jan 31st and I made my initial disclosure to them on Feb 3rd upon discovering the flaw. At the time of publication, Feb 10th, I have re-tested the same methods and I can no longer retrieve account data from another serial number. It seems odd that the ability to retrieve account data in this fashion was present, but upon receiving an official comment from EE 7 days after disclosure and several chaser emails, the problem is gone. Perhaps a coincidence, perhaps not, at least the issue is no longer present.
DIY LAN tap
In an effort to determine if the exchange of configuration data was secure, I decided to monitor the communications between the router and the modem to see if I could intercept the request for the account credentials. There may have been other ways to do this but I decided to hack together a LAN tap. Apologies for my horrendous wiring skills here, but it was cheap and easy, only requiring a couple of old LAN cables. You can of course opt to get a much more professional LAN tap such as the throwing star.
The idea behind the LAN tap is to attach a listening cable (the blue ones) onto the transmit lines of the target cable (the yellow one) in each direction. Once I connect my laptop to either of the blue cables I can listen to the transmissions going over the wire in one direction without interrupting anything. No one will know I'm there, I just fire up Wireshark and start packet capture. Using the yellow cable to connect the router to the modem, I connected the blue cable that allowed me to listen to what the router was saying so I could monitor outbound requests. After a factory reset the first thing that grabbed my attention was a DNS lookup for arcadyan.cwmp.eu. CWMP is the CPE WAN Management Protocol, the formal name for TR-069, so this seemed like a good starting point. As you can see when visiting the site your browser should throw a warning about the SSL certificate not being valid. This is because it's not signed by a trusted root authority. Instead it's been signed by madesimpletechnology.com. This isn't a problem in itself as I imagine the page wasn't meant to be accessed using a browser, but by the routers instead. As long as the router has the certificate pinned, then the communications would still be secure. All that is required at this point is to install yourself as a MiTM and either spoof the DNS record for the host or run an SSL intercepting proxy to see if the router validates the certificate. As I've already seen that the exchange is encrypted, and that I can no longer retrieve data using alternate serial numbers, I won't devote any more time to investigating the data exchange with the ACS.
Update 5th Feb Modifications have been made to the arcadyan.cwmp.eu page since my disclosure on 3rd Feb, you now get a warning when visiting with a browser instead of the status/information page. I could still retrieve account credentials from the ACS as of the 5th Feb when I noticed these changes.
Accessing accounts online
After receiving a tip via email from XRaySpeX over on ThinkBroadband, I was shocked to find that the account credentials on my router were the same account credentials required to access the online account section of the EE website. Given the ability to purchase routers on eBay and access previous owner's details, and my previous ability to recover details from the ACS, you can obtain a worrying amount of information from the account pages.
With the ability to change my account package to something much cheaper or much more expensive you could cause some serious inconvenience, especially considering you can completely change the package and it's included allowances. Additionally, the payment details page provides an awful lot of sensitive data. With the full name and address of the account holder, including portions of their bank details, this could possibly open up social engineering attacks or access to other services the user is signed up for that use this information as verification. With the change payment details option I can insert some false bank or card details and the next time a billing date comes by, payments are going to be declined. I imagine you'd have a hard time talking to EE about that one. I'm guessing that the only way around this problem is to not use the same credentials to connect to the broadband connection that are used to login to your online account. I can't see why these credentials would need to be the same, in fact, it'd be a lot better if they weren't. If anyone has any input on this, please let me know in the comments below.
Hijacking sessions the easy way
When someone is logged in to the web admin on the router and another devices visits the page, you get the 'duplicate administrator' message. You can't attempt to login or attempt to logout the other person that is currently logged in. Whilst performing a little testing against the router, I discovered a method that allows me to logout the other person and to hijack their authenticated session with a single click.
When viewing the 'duplicate administrator' warning, you simply need to use the following link and the router will log out the other user and log you in, without needing the password. It's not apparent what's causing the issue but it seems that the router can't handle the invalid URN value very well. There are several demonstrable flaws where the router doesn't sanitise or handle invalid user input very well, which leads me nicely on to my next point.
Crashing the web server
Whilst testing the new password update mechanism, as all good testers do, I decided to throw some invalid input into the mix and see what calling the changePwd.cgi file with missing parameters would do. As it turns out, the web server crashes, rendering the web UI completely inaccessible. The only way to recover is by rebooting the device and to add insult to injury, you don't even need to have anyone logged in to carry out the attack. (crash log here)
I've tried accessing the same file, and others, over the WAN interface as the device seems to be listening on ports 80, 5438 and 8085, with no luck. Port 8085 is the TR-069 comms port and does give you a telnet connection but nothing seems to happen, Port 5438 serves login_guest.html which sits in a redirect loop to itself still, I've a feeling that it's waiting for something, perhaps a customised user agent string like the D-Link routers? Port 80 seems to just sit and time out on the request.
Conclusion
Whilst the patch is a good step forwards in terms of securing the BrightBox, there is still work that needs to be done. The exposure of account data directly from the ACS was a bit of a worry given that it was so easy to access, but that now seems to be resolved. The CSRF vulnerability is also pretty dangerous as the ability to change DNS servers represents a huge risk to privacy and security, especially considering the recent attack highlighted by CERT Polska. Once the second patch is available for the BrightBox and EE have resolved the remaining issues, customers will be able to breathe a sigh of relief.