followed by incompetence.
A Wi-Fi router flogged by British mobile network EE has a hidden administration account with a hardcoded username and password – and is accessible via SSH. This root-level account, present in EE's 4GEE HH70 gateways, can be accessed by anyone on the local network, such as a malicious user or malware on a Wi-Fi-connected PC. …
Jesus what idiocy is this?
This is back to the days when all ISP supplied kit had the same crappy admin logins across the board.
Nowadays, every one I see has a tag/label of some kind with these details - it's not a stretch to print another line for this should it be required...but....why is it required?
And if you must have something like this, don't make it so easy to get that all you have to do is grep a file
And to be equally as fair, they're supposed to assess the security of those devices before passing on the system to the customers.
So they're both responsible for owning the fix, and for it getting out in the wild past their "testing" regime in the first place.
It doesn't matter where you buy something from, your supposed to check its fit for purpose before putting your customers at risk using it, ok?
> To be fair to EE, they don't actually make the thing
To be fair to EE, they (should have) wrote the requirements for the thing and sent it out to manufacturers RFx teams, who wrote compliance statements against each line item and then a £ amount at the bottom of the report. One of the requirements should have been to do this properly, but I guess they either didn't think this was important to be mandatory, or they didn't think of it.
JetSetJim, "...they (should have) wrote the requirements..."
Oh lookie. Another naive person that believes in Requirements Management. It's so cute.
Allow me to explain why...
Code is at least an order of magnitude denser than requirements prose. A given paragraph of Requirements 'Shall' poetry might result in just a small part of one line of code. So if you have 'a telehone book' worth of code, the associated Requirements bible should amount to an encyclopedia set of volumes spanning a meter of shelf. Nobody can afford this. Nobody, except perhaps the Flight Safety software on an aircraft.
That's why the myth that is 'Software Design By Requirements' is so monumentally idiotic.
Program Managers that insist on using this approach deserve to fail.
(As noted above, please do use DOORS Requirements Traceability on Safety Critical systems. That's the sort of use-case where it's clearly worthwhile.)
PS: DOORS is an IBM tool. When is the last time you saw huge volumes of fantastic code pouring out of IBM?
"...they didn't think of it."
Equally likely they thought of it, and possibly other "it" things they should do, followed by quickly realizing those "it" things cost time, money, etc., and since they only care about wringing the last bits of profit out of the thing, quickly discarded all concerns for "it".
I have seen this argument used many times. The problem is you end up with a Maginot Line effect. Any compromised device on the network can be used to compromise the router. Plus there are ways for JS to initiate a login to the router. So badly implemented browser security can let that happen. The right way to do secure design and implementation is to have security well implemented in ALL components.
>>>"It's important to note that for this vulnerability to be exploited, you need to have local access. So the risk of this being exploited is low."<<<
Do these boxes also have WPS, WPA & WPA2 active by default as well? I'd suggest the low risk is down to being one of millions in the herd available for targetting.
I think we can deduce that the EE equipment
developers finders are Trotters Independant Trading co.
I'm not suggesting that this is "secure", but if you're going to put in a default backdoor password (presumably to force firmware updates and the like, like cable operators do), then at least take ten seconds to come up with something that's not so bleeding obvious all you have to do is grep the firmware.
Off the top of my head:
Set the password to: A cryptographic hash of the device serial number/MAC address, salted with a secret salt that - should the worst happen - you can change and then re-password all the devices (you know what the serial number/MAC address is, it's then easy to work out what the password for any particular device should be and it should only be travelling over your own network, yes? And one password does not let you into every device. And if you do it right, even with a million passwords of a million devices out in the wild, someone shouldn't be able to work out the hash salt?).
Just make sure that the salt is NOT stored on the devices themselves (literally just generate the hash and use that in your password file as the password for that device - hell "ASCIIfy it" or "hexadecimal" or something if you want a human-readable version of it).
That's where I'd start with the absolute bare basics of "bodge job".
If you want to do it properly... secure certificates. Gosh, if only we had those right? A client certificate on each device that can be unique and you can use for securing their update checks, and every device carries the public key of the certificate that you intend to use to connect to them and expect login.
This way - you don't even need a password! Just a certificate (it might be an idea to passphrase it though). Ten minutes with OpenSSL (gosh, I wonder what kind of device would have to have OpenSSL installed by default anyway?) and every client can generate their own unique certificate to identify themselves, and you have a certificate at EE / whoever that can connect to any router to make it update. And you could even do things like replace that cert, revoke any compromised cert, pull that cert from the Internet when it changes, verify it against certificate stores, etc. etc. etc....
It's almost like someone invented an infrastructure and encryption methods to support all this, and people added it into basic login / administration tools so you could use it, eh?
A.K.A. SSH public-key-authentication.
it isnt necessary though. All commercial routers have a default password that is usually printed on a sticker. If an engineer is visiting then they can either use that or factory reset if the customer has changed it and forgotton. There is literally no need for any hardware to have a baked in root SSH credential.
I know a script on a web page can access the webpage of a router, which is why the default password should always be changed on ANYTHING on your LAN with a Web admin interface.
Can a malicious browser script use SSH? I think not. Though I suppose it could install a program on your phone/tablet/PC etc that can?
I use uMatrix and I also change all default passwords to "hard ones" (written in a securely kept address book, never removed from the premises) and have Java, PDFs and other things disabled in the Browser.
Hard coded passwords are mental. Some are only activated by a physical reset button with factory reset, that's I suppose reasonable if your router isn't on a café or library publicly accessible shelf.
My gut says maybe, and google threw this up https://github.com/billchurch/WebSSH2
Which on poking around suggests no.. on the basis it's using a proxy thus the (ssh)network packets do not come from the client network.
That said JS has arrays, and integers, so you should be able to craft appropriate packets, leaving only finding a way to inject the packet on the client network as an exercise for the reader..
I worked at Nildram back in 2000-2001 and we were punting out Zyxel routers to customers as a replacement to the original Stingrays.
Myself and a second-line technician were tasked with writing some software to preconfigure the routers with the connection details, and to make some other tweaks, so that the provisioning ladies could plug it in, run a script, box it up and ship it out.
One of the first things we baked into the script was to change the default router password. Admittedly, to the same as their connection password but it was still not the default...
They do. They also require login on that page to change anything. In theory, depending how buggy the code is. Without password all you see is various status pages.
Default IP address != default password
Sadly SH3 is JS hell, the previous ones at least had status pages that were easily readable with curl to build some automatic monitoring and statistics collection.
There is also a hidden way to enable SSH (even after EE disabled it), Alcatel or EE have developed a button trigger that will enable the dropbear service.
If you hold the WPS button for 15 seconds or more and then release it, this triggers the following code:
logger the button was $BUTTON and the action was $ACTION the time is $SEEN
if [ "$BUTTON" = "wps" -a "$ACTION" = "released" -a "$SEEN" -ge 15 ];then
logger enable dropbear the time is $SEEN
uci set dropbear.@dropbear.enable='1'
This is present in /etc/hotplug.d/button/buttons on the router filesystem.
Someone goofed on the uci set, because uci commit is never called, but it starts the dropbear service anyway, so SSH access restored! You can then setup pub key authentication and disable the password auth option so the SSH access is secure.
The original report picked up hard coded sshpass commands that pointed at the modem side of the router (192.168.225.1), that too also have the same root password, although changing that is probably a bit riskier, given the binary has hardcoded references to it. You can however secure the router SSH without breaking anything.
Although the router modem has always been able to be accessed via SSH (still is), but instead of using the 192.168.225.1 IP, you'd use the IPv4 address assigned as displayed in web interface, usually 19.x.x.x something.
Biting the hand that feeds IT © 1998–2020