Home routers and security flaws
A message to Bugtraq about vulnerabilities in the British Telecom (BT) Home Hub this week had a familiar ring to it. We covered a cautionary posting about these kinds of problems in May, now we have a report of easily exploited flaws in a home router that is widely deployed in the UK. Unfortunately, we will probably have to cover the problem again, as these devices are becoming ubiquitous, while the manufacturers and distributors are, seemingly, leaving the security testing to their users.
The Home Hub is a standard Thompson/Alcatel DSL router, branded and distributed by BT, that provides VoIP and digital television in addition to internet access. It also has Wi-Fi connectivity which can provide shared access to the neighborhood via the Fon network. Overall, it sounds like a nice device, providing multiple useful features, but it evidently can be completely taken over ("owned") rather easily.
The exact details of the exploits used are not revealed, but the video linked from the discoverer's website shows web access to the router's administration screen after luring the victim into following a malicious link. The description of the flaws found read like a laundry list of web application flaws: cross-site scripting, cross-site request forgery, and authentication bypass. Though the router runs Linux, presumably the flaws are specific to the application software or configuration of the router; at least no more widespread vulnerability was reported.
Full access to the router configuration allows for a mind-boggling number of malicious uses. As is pointed out in the posting, one could steal VoIP credentials, reroute VoIP calls for eavesdropping, steal the WEP keys, change the DNS to point to a server under the attacker's control in order to steal credentials, etc. Most of these would be completely undetectable in normal use and the owner might go a long time before noticing that the settings had changed – if they can even log in anymore.
According to the website, BT has responded and is investigating the flaws, presumably some kind of update will be forthcoming. Home routers are particularly sensitive targets, precisely because of the undetectable nature of the attack. If the attacker is careful enough not to interrupt normal functioning, the owner will have no reason to check the configuration.
These kinds of problems are not restricted to routers or embedded networking devices, of course, but they do make tempting targets. Because of that, and the difficulty of ensuring that all customers get a critical security update, vendors of these products and the internet providers that push them need to test very carefully. Someone other than the developers should be tasked with strenuous penetration testing on a device like this, before it gets in the hands of customers.
Updating the devices in the field pose a number of problems; the obvious solution is to do it automatically, without customer intervention. But, as iPhone unlockers recently found out, that can lead to unwanted "upgrades". It is an uneasy balancing act – customers will need to trust the device providers to only update for bugs or security holes, while the providers will need to earn that trust by not breaking functionality the customer relies upon. Otherwise, folks will figure out ways to disable the auto-update functionality, completely defeating the purpose.
This particular incident seems not to exploit any particular Linux problem, but we might not be so lucky the next time. It would be a tragedy to see Linux linked with an in-the-wild exploit of a vulnerable device. An unknown exploit (a so-called "zero day") would be bad enough, but a known kernel bug that did not get properly updated would be a far worse black eye.
Index entries for this article | |
---|---|
Security | Internet/Routers |
Security | Web application flaws |
Posted Oct 11, 2007 1:39 UTC (Thu)
by jwb (guest, #15467)
[Link] (5 responses)
This is the access point that AT&T supplies to all their DSL customers, so this piece of junk is very, very popular.
Posted Oct 11, 2007 11:26 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Oct 11, 2007 13:45 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
My impression after trying WEP crackers on friendly networks was that they weren't very effective. No doubt the possibility that a determined and resourceful attacker would eventually succeed in obtaining your WEP key is a valid threat model, and I agree it would be better to upgrade to better technology where possible, but "10 seconds" doesn't match my experience.
I spent several days monitoring active (and friendly) business networks with tools that made these sort of claims, and in each case they failed to retrieve a workable key. In that time I learned several things relevant to the "10 seconds" claim.
You can't crack a network that's idle. The beacon packets are plaintext, so you're reduced to just guessing keys and trying to connect, there are 2^56 keys so that's not viable even if no-one notices your billions of failed attempts.
Crackers are mostly looking for "weak IVs" which are an implementation error in early APs. If your AP doesn't spit out lots of weak IVs then your WEP implementation will take much longer to crack.
Although having more eavesdropped data available improves the performance of the cracking software it isn't linear, so collecting data for twice as long won't halve the time taken to guess a key.
The attack is probabilistic, so sometimes it won't work and the only way to know why would be to start with the real key value, and if you had that (which I did) then attacking WEP is only an exercise.
Posted Oct 11, 2007 15:46 UTC (Thu)
by fatrat (guest, #1518)
[Link]
Look at modern wep cracking tools that use one card to generate suitable packets and another to crack.
Posted Oct 11, 2007 15:49 UTC (Thu)
by jwb (guest, #15467)
[Link]
Posted Oct 11, 2007 15:53 UTC (Thu)
by leoc (guest, #39773)
[Link]
Posted Oct 11, 2007 6:05 UTC (Thu)
by eru (subscriber, #2753)
[Link]
I would have to say that these attacks are the least of the worries I have about the telco's home routers. The most widespread telco-supplied home router is the 2Wire wireless access point and dsl modem. Each of these is shipped with a 56-bit WEP key, which is written on the bottom of the router. The user does not have the password for the router, because it's kept secret by the telco's support group, so the user can't upgrade to 128-bit WEP or WPA or do any other thing. It is trivial to crack the 56-bit keys in these things. It can be done by any hacker in less than 10 seconds.Home routers and security flaws
Yeah, but BT's goal is eventually to get a BT Home Hub into the house of everyone with a telephone line or a TV. That's basically *everyone* in the UK.Home routers and security flaws
I am very dubious about this "less than 10 seconds" remark.Home routers and security flaws
Home routers and security flaws
This particular router/access point has every weakness you mention. I can literally get the keys while walking past one with nothing more than a laptop in a bag and a copy of aircrack-ng. I have lists of hundreds of them from all over San Francisco.Home routers and security flaws
Those 2Wire modems have far larger problems, primarily the fact that they don't really work. I've had two of them and neither of them would hold a signal for more than an hour or two.Home routers and security flaws
One thing that could make a security problem with these worse than usual is that these home routers are typically always running and connected to the net, even when the user's PC is not. This would make them nice botnet slaves. The ADSL modem/router I have does not even have a power switch. It, too, appears to run Linux, judging by references to Busybox and other typical Linux programs in the logs that can be seen in the html-based administrative interface.
Home routers and security flaws