Members of the embedded systems hacker collective /dev/ttys0 spend their time playing around with devices like home routers and set-top boxes.
They like to see what interesting facts these devices’ proprietary hardware and firmware might reveal.
Part of the hackers’ motivation is to get the devices to do things that the vendor may not have bothered to implement, thus improving their functionality.
And why not, if it’s your device that you bought outright with your own money?
But hacking on embedded systems can also help to improve security, or at least help others to avoid insecurity, by revealing and helping to fix potentially exploitable vulnerabilities that might otherwise lie dormant for years.
Indeed, in recent times, we’ve written repeatedly about security problems in consumer embedded devices.
We had a botnet that unlawfully mapped the internet by jumping around from router to router and taking measurements without permission.
We described a flaw that allowed attackers to force your router to open up its administration interface to the internet, something you would never normally do.
We’ve talked about how the Wi-Fi Protected Setup (WPS) feature, intended to improve security, typically makes your wireless access point easier to break into.
And we wrote up a widepsread flaw in the way that many routers implement a popular system known as Universal Plug and Play (UPnP).
UPnP is a protocol that is supposed to make it easier to configure your system correctly, but may instead leave you open to the world.
You can probably guess where this is going: another security hole.
This one was found in the firmware of a number of D-Link routers – the author suggests at least the models DIR-100, DI-524, DI-524UP, DI-604S, DI-604UP, DI-604+ and TM-G5240.
I’ll skip the details – you should read the original author’s analysis, since he did the hard yards to identify the flaw – and cut to the almost unbelievable conclusion.
If you browse to any page on the administration interface with your browser’s User Agent (UA) string set to a peculiar, hard-wired value, the router doesn’t bother to ask for a password.
Let’s be perfectly clear what this means: these routers have a hardwired master key that lets anyone in through an unsupervised back door.
“What is this string,” I hear you ask?
You will laugh: it is xmlset_roodkcableoj28840ybtide.
Ignore the xmlset, which probably just means “Configure Extensible Markup Language (XML) setting.”
Flip round the part after the underscore, in reversible-rock-music style, to get the hidden message:
Edit by 04882 Joel: Backdoor.
Can you believe it?
If you tell your browser to identify itself as Joel’s backdoor, instead of (say) asMozilla/5.0 AppleWebKit/536.30.1 Version/6.0.5, you’re in without authentication.
Fortunately, the administration interface isn’t accessible from the internet-facing port of these routers by default, which limits the exploitablity of this vulnerability.
(If you have one of these models, check right now that you can’t access the management interface directly from the outside!)
This is a shabby feature to put in any product, let alone in a router than aims to provide at least some additional security.
It begs the question, “Why have Joel’s code there at all?”
A good guess is that the backdoor probably wasn’t put there to enable illicit surveillance, or for any other nefarious purpose, but as a favour to special-purpose D-Link software, so it could make configuration tweaks without needing a password.
Or it was put in to save time in development and debugging, but never taken out again.
Sadly for the world, though, 04882 Joel made it easy for anyone at all to make configuration tweaks without needing a password.
For the second time this year, we’d therefore like to say, “Hardwired passwords were a design blunder back in the 1970s. In the 2010s, they are simply unacceptable, so never succumb to the temptation to include them in your code.”