3

I have no idea what is going on here, I'm leaning towards an error in the firmware or some kind of protection they wont let you turn off.

My router has 2 networks: a 2.4ghz and a 5ghz network.

I see this in the logs: [DoS Attack: ACK Scan] from source: 143.127.93.123, port 80, Tuesday, October 27, 2015 18:11:07

That IP address belong to Symantec. I can only assume this is a probe attempt to see if my router is vulnerable to some kind of remote admin talk.

When this happens in my logs, my 2.4ghz network just dies silently. Router web interface says everything is fine, and the 5ghz network stays up.

Anyone have any insight into why this happens? I've gone through all the settings I can possibly tune, but nothing. This happens 1-4 times a day, and the only way to fix it is to reboot

Thanks!

1

I have a distinct suspicion of what the cause of your semi-crash might be. If it is so, it's kind-of bad news:

SEC Consult Vulnerability Lab has discovered the flaw, which Ars Techinca refers to as “amateurish,” in a driver referred to as NetUSB. The driver, as its name suggests, is installed on routers to allow computers to access USB devices over a network.

Sadly, the driver contains an error known as a buffer overflow, which can occur when a device sends its name to the router and it’s longer than 64 bytes. The researchers claim that the simple overflow can be used to crash the router, using denial of service of attacks, and even execute code remotely.

According to Ars Technica & the vulnerability testers who caught the bug, it's present in both WNDR v1 & WNDR v2. (The full list of routers believed to be affected is in that Gizmodo article.)

Now, to be clear this is just a suspicion; it's possible the unusual attack traffic (unusual to your router, at least) might just have coincidentally arrived about the time that your 2.4 network had its crash-like event. Without further log details of what was actually in the packets of the suspicious traffic, details that aren't going to be in a consumer-grade router's logs, it's perhaps impossible to say for sure. If the suspicious traffic reoccurs and your router immediately suffers subsequent issues, obviously the cause could then be known with more certainty. (Or if you were to capture some of that future traffic with a packet sniffer like Wireshark.)

You can try the check-for-updates capability wherever in exists in the UI there and see if Netgear has released a firmware update that patches the flaw/s. Sometimes consumer-grade router makers will act responsibly and do so. Sometimes.

On the plus side, I guess, if this is an attack the person or program that knocks out your router has a slight sense of humor, spoofing an IP address of Symantec as the attack source.

Edit:

Ars has some more technical details on the vulnerability. It's really, really stupid:

This router-side driver listens to connections on TCP port 20005, and it's this driver that contains a major security flaw. SEC Consult Vulnerability Lab, which publicized the problem, discovered that the Linux driver contains a simple buffer overflow. As part of the communication between client and server, the client sends the name of the client computer; if this name is longer than 64 bytes, the buffer overflows. The company says that this overflow can be exploited to enable both denial of service (crashing the router) and remote code execution.

Ugh.

If this situation is one such DoS attack, is there anything you can actually do about any of this? Well, the obvious things for me to tell you are to try (1) disabling the USB port feature in the router UI and (2) try getting the router to block WAN traffic on port 20005, which is how the remote code that triggers the buffer overflow gets to your router. (Very roughly speaking, in non-technical terms.) Which might be good advice, except:

Netgear told SEC that even with NetUSB functionality disabled through the router's configuration UI, the driver is still loaded, and there is no ability either to disable it or to block access to port 20005 in the firewall.

Yikes.

So...I'm sort of out of ideas at the moment. Maybe someone else has other suggestions. If this really is the result of the attack method described above...

Edit #2: Qualified my previous statement that this situation definitely is/was an example of an attack to exploit the vulnerability described in the answer. It might well be, but that is still, as the Scots might say, not proven.

| improve this answer | |
  • Why do you think this is that vuln? – Neil Smithline Oct 28 '15 at 4:41
  • @Well, certainly it's a guess, rather than an absolutely firm evaluation. (And I suppose I should have stated that up front in my answer. I will correct that.) But I think it's a fairly intelligent guess; traffic from an almost-certainly spoofed IP that the router itself labels as suspicious DoS traffic arrived at about the same time as the partial crash occurred, plus the symptoms of what the poster described being consistent with what this particular buffer overflow could easily do. But you're right if you imply that I can't prove that it's the cause on available info. Will revise. – mostlyinformed Oct 28 '15 at 4:55
  • I didn't mean to imply anything. I just wondered. One thing that seems off to me is that the vulnerability you reference is a kernel mode buffer overflow, I would guess it would take out the entire router, not just one of the WiFi channels. PS: i hadn't seen the article, good read. – Neil Smithline Oct 28 '15 at 5:02
  • Ahh, I see. Well, actually the constructive criticism I thought you might have been implying is/was/would have been a well-taken one: the evidence is interesting but not conclusive. Re. the lack of a general crash requiring a device reboot that struck me as well. I suppose I just chalked that up to an idea that memory safety bugs can sometimes result in malfunctions vs. full system crashes depending on the state of the device, but it is interesting. Hmmm. – mostlyinformed Oct 28 '15 at 5:28
  • Interesting, i didnt consider that someone could spoof that. I figured it was part of some kind of mass scan; i remember reading about Netgear vul's about a month ago. Also: I am up to the latest firmware and have tried firewalling off that ipaddress and port from the router itself, but I'm not confident that it is enforcing that. Apparently this kind of thing is super common with this particular router; and Netgear's official advice is to flash 3rd party firmware like DDWRT or Tomato. Uggh. I'm not sure what to believe; if this is just shit firmware or a malicious attacker – Patrick Hennessy Oct 28 '15 at 8:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.