Router Crash Test
Could your home network be taken over remotely?

What's going on here?

During our development of GRC's comprehensive DNS nameserver spoofability profiling system, we discovered something quite unexpected: A number of users were losing all Internet connectivity shortly after initiating the nameserver profiling. Upon further examination they discovered that the test was crashing their consumer NAT routers. The following routers are currently known to be susceptible to crashing under this test:

DNS Test “Crashable” NAT Routers
• 3Com 3CR858-91 OfficeConnect Ethernet Broadband Router
• 3Com 3CRWDR100A-72 OfficeConnect ADSL Wireless 11g Firewall Router
• A-Link RR24AP(i+) with latest firmware at time of crash report
• Belkin F5D7234-4 v3 (01) Wireless G Router (firmware 3.00.3)
• Belkin F5D7234-4 v4 (01) Firmware v4.00.05
• Belkin F5D7630-4A (rebranded as MicraDigital)
• Belkin F5D8236-4 v2 Wireless N Router
• Belkin F5D8636-4 v2 Wireless N Router
• Belkin F7D2301 v1 (01) Wireless N Router
• Ozenda AR4505GW
• Philips SNA6500 ADSL Wireless Base Station
• Siemens Gigaset SX551 WLAN DSL

Okay, that's annoying, but why is it a concern?
What this means is that the Internet data packets entering these routers from the outside are, in some way, something that the router does not currently handle properly — so the router crashes. The development of virtually all successful remote Internet exploits begins when someone notices that something unexpectedly crashes a system. This is typically evidence of a previously unknown “buffer overrun” or “unchecked buffer” vulnerability in the affected device. Armed with the knowledge of the existence of such a possible vulnerability, skilled hackers — and make no mistake about it, these people are highly skilled — are often able to refine the characteristics of the “crashing packet” to cause the affected system to execute code they provide in a some sophisticated version of that packet.

And, with that, the minor annoyance that once crashed a router when running
GRC's DNS test evolves into a full blown exploit that allows a remote hacker to
take control of the network that was previously protected by that router.

PLEASE CAREFULLY NOTE what we are and are not explicitly stating about this potential for a remotely exploitable vulnerability:

  • We are NOT stating that any of the routers which our test causes to crash have any discoverable remotely exploitable vulnerability.
  • We ARE stating that no one's router should ever crash simply by having it pass a valid, resolved domain name from the Internet to a machine on its internal network — which is all our test does.
  • We ARE stating that remote execution exploits almost always begin life as unexpected (and certainly unwanted) crashes.
  • We ARE stating that any newly discovered crash, exactly like this, provides the sort of window of opportunity that talented hackers live for.
  • We WILL NOT be surprised to learn that this revelation results in the creation and exploitation of any of the routers listed above.
Mitigating Circumstances:
It might very well be that the inherent behavior of NAT routers, whereby they simply ignore and drop unsolicited packets coming in from the Internet, would completely mitigate any danger from the fact that expected and solicited packets — such as those occurring during our test — are able to crash the router. In other words, your router is crashable and potentially vulnerable only because and only while it is in the process of running this test which was initiated by you “on the inside” from behind your router's inherent protection.

Having said that, however, it might also be that any exposed ports in a router, such as those created by explicit port forwarding or the use of a router's “DMZ” forwarding capability, would once again expose the router to DNS packets it appears to be unable to safely digest.

Two Worrisome Scenarios:

You already know and trust us — that's why you're here. You know that GRC are the good guys. But imagine for a moment if we weren't: We have a simple web-based test that currently only crashes your router. It does so through the simplest everyday occurrence of having your web browser lookup the IP address of an unknown domain name. Easy, right? And that's as far as we have taken it, because our interest is limited to letting you know, and helping you to get your router fixed. We have no interest in using our test to take over your router and gain unsolicited access to your network. Really we don't. Really.

But even if it turns out, as currently seems likely, that crashable routers are only vulnerable to solicited DNS replies, it does appear to be very likely that additional research could turn this “solicited crashing behavior” into “solicited remote exploitation.” Here are two worrisome ways this could be done:

  • You innocently visit a malicious web site that causes your web browser to solicit the IP address from a malicious DNS server that takes over your router. No personal firewall would prevent that, since it starts as a simple and valid DNS domain name lookup. But in soliciting the IP address of that malicious domain, the returning packet doesn't crash your router, it takes it over. Perhaps it enables remote WAN-side management, opens a port, removes the logon password, aims the router's DMZ at your main machine, or anything of the sort. That's worrisome.
  • Now take the case of a shared public network behind a consumer-grade router such as any wireless hotspot, hotel or other shared network. A bad guy sitting anywhere inside the network, in a cafe or hotel lobby, identifies the router by looking at its logon page or by broadcasting a UPnP (universal plug'n play) query. Now he knows which router he's dealing with and in exactly what way its vulnerable (if it is) to a solicited DNS reply. So he sends his DNS server out on the Internet a DNS query . . . and when the publicly shared router receives his specially crafted reply he “owns” the router (in hacker parlance). That's worrisome too.
It's pretty clear that we need to get these
routers fixed . . . and sooner rather than later.
What can, and should, you do if you have a crashable router?

So now you know as much as we do about this intriguing issue.
But you may not know whether you have a crashable router.
Simply push the button below to find out...

GRC's DNS Nameserver Spoofability Testing Pages:
DNS Tests Usage Statistics:
 Standard   CustomCrashTest
Daily Usage:311224
Total Usage:175,1471,34817,870

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2014 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: Jun 04, 2014 at 05:07 (268.47 days ago)Viewed 49 times per day