By Jake Edge
October 10, 2007
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.
(
Log in to post comments)