GRC | ‘s DNS Nameserver Spoofability Test – Router Crash Test

GRC | ‘s DNS Nameserver Spoofability Test – Router Crash Test

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:

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?

  • Complain loudly to your router’s manufacturer:
    One advantage of this publicly available router crashability test is that any router manufacturer can easily use it to reproduce and fix their defective router firmware. (And yes, we realize that the downside is that the bad guys can also use it to figure out what’s happening and possibly design a potent exploit. This is the common tradeoff when publicly and openly dealing with Internet troubles.)
  • Don’t panic:
    Yes, there’s significant potential for trouble here, but please remember that it’s only potential at this time, even if it is significant. That’s still very different from confirmed trouble. Please don’t confuse the two. At the moment, there’s every reason to believe that only solicited packets arriving during GRC’s DNS test can cause a router to crash. Unexpected (unsolicited) incoming packets will simply be dropped, no matter what payload they carry. It seems quite likely that it is the act of the router actively dealing with and digesting the incoming DNS packet that’s causing trouble. Without knowing the exact nature of the trouble for each router, it’s impossible to say for sure. With the exception of “evil web sites” such as we outlined in the box above, this is not panic-worthy at this time.
  • If your router crashes and it is NOT already on this list:
    Given that so many defective routers were discovered by a relatively small testing group, we fully expect to discover that many more routers are crashable. Therefore, if you discover a crashable router that is not listed above, please notify us immediately using our feedback page with this link or the link below. Our best option is to bring this problem to the attention of the broader Internet community so that users can notify their router manufacturers, and those manufacturers can repeat the behavior, observe the trouble, and fix their defective firmware promptly. The more pressure that’s brought to bear by their customers, the faster the manufacturers are likely to respond. So please help us to list any additional routers you discover. This will also help to protect anyone else who may be using the same router.
  • If your router IS on the list and DOES NOT crash:
    We need to know that too, so that we can maintain an accurate list of currently crashable routers. Once manufacturers have repaired their firmware, we’ll want to make note of that fact so that users of still-defective firmware — and then needlessly crashable routers — can update their router’s firmware then use this test to verify that their router is repaired.
  • If a router YOU DO NOT OWN crashes:
    As we detailed in the box above, we recognize that this trouble may be widespread enough that routers on “borrowed networks” — such as at wireless hotspots, in hotels, or other communal settings — could unfortunately and inadvertently be brought down by the use of this inherently benign DNS-based test. That is a risk created by a public test such as this, benign though it is. However, this trouble was first discovered publicly through public tests on GRC’s newsgroups, so those horses have left the barn and are roaming freely. The best course of action now is to get all crashable routers repaired — especially if this trouble does extend beyond simple crashability. So please also let us know if you discover crashability on such borrowed networks. We probably won’t share the information, except very generally. But it could be important to know that it is happening.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s