D-Link Apologizes For Router Security

Mark Wilson writes D-Link has issued an apology to its customers for an on-going security issue with many of its routers. A problem with the Home Network Administration Protocol (HNAP) means that it is possible to bypass authorization and run commands with escalated privileges. The list of routers affected by the issue is fairly lengthy, and D-Link has already issued one patch. But rather than fixing the problem, last week's update left routers wide open to exactly the same problem. As it stands at the moment, a firmware patch is still being produced for a total of 17 routers. In the meantime, all D-Link has to offer is an apology. While unhelpful patches have already been issued, D-Link is currently working away on replacement firmware updates. The release dates for these patches is not yet set in stone, but some are due today (20 April), some tomorrow (21 April) and the remainder on 24 April.

Comments

Words without actions are meaningless

[TWX]

An apology doesn't really mean anything in this case, does it?

Re:Words without actions are meaningless

[gstoddart]

Depends on how we define "mean anything".

"We're sorry we have sold you shitty products but won't fix it" is just PR.

"We're sorry we've solve you shitty products but will replace it at our expense" is actually doing something.

I suspect this is one of those corporate apologies designed to say "fuck you, but thanks for playing, hopefully we've minimized the fallout of writing shitty products by issuing a half-assed apology".

I'm hoping the absence of my DIR-615 isn't "we're sorry to tell you we made a shitty product and forgot to check if it was vulnerable".

I keep saying, corporations should have some liability for implementing terrible security. Especially for a product whose job it is to be a firewall.

Re:Words without actions are meaningless

[LordLimecat]

For starters, I have read up on it, and many many vendors agree that it IS security.
Sources:
Cisco (Top 2 paragraphs of intro)
http://www.cisco.com/web/about...
SANS institute (Page 5, 2nd paragraph)

And so on.

As to your solution, it has a massive issue. Route tables must use next hops as their gateway; you could not enter a command like that targetting my WAN, and have it work, because my WAN IP would not be a next hop for your computer. The only thing your route table can do is instruct your computer which IP on your broadcast domain will be willing to handle your datagrams. At that point, it is up to that router to figure out the next hops.

You will note I asked you what the L3 / L4 headers would be on your packet; this was specifically to demonstrate why such attacks would fail. You would have a source address of 9.9.9.9, and a destination of 192.168.50.5, and you would instruct your computer to pass that datagram off to a router at ethernet address 99:99:99:99:99:99 (your router), and he would promptly vomit and say "what the hell I cant route an RFC1918". Add the route on your router, and you've shoved the issue back to your ISP, whose router would either fail to find a route for that subnet, or (more likely) outright reject it as a violation of RFC.

The only scenario in which this attack makes sense is when the attacker IS the next hop, that is your ISP. And for 99.999% of users, this is not a realistic threat model they will face, and NAT will be "acceptable" security.

No one argues that a stateful firewall is BETTER (as it prevents attacks like you mentioned), but to say that NAT adds no security whatsoever is being silly; major infrastructure vendors disagree with you.

Good security

[ArhcAngel]

I think D-Link has excellent security. The minute you try to use it the hardware dies. I have some of the old metal box Netgear desktop switches that will outlive me. Almost all of my D-Link products have died prematurely.

you don't want their actions.

[Lead Butthead]

Keep in mind this is a company that has a history of doing malicious things; willful violation of GPL that was resolved only when they're drag into the court and lost, hard coding default time server IP address in firmware (imagine hundreds of thousands of them all attempting to sync at the same time daily) It demonstrated a culture of (sociopathical) disregard for others, that alone is reason enough to not buy any of their products.

OpenWRT

[Shadow IT Ninja]

I'm glad I did my recent router shopping by starting with the list of OpenWRT supported devices. OpenWRT is a community supported router firmware. There is more active scrutiny of OpenWRT than proprietary manufacturer firmwares. They support hardware more actively and longer than the manufacturers, themselves, do because they use a common source with many hardware models. There is less likelihood of backdoors being introduced or going unnoticed if they are introduced. I'm talking about backdoors like the famous port 32764 back door which was found and patched but then the patch was reverse engineered and found to just hide the back door better.

Now this story highlights another issue which is that the manufacturers are trying to add features to their routers. This is antithetical to security. The best thing for security is to keep it simple. HNAP, the basis of the vulnerability in this story, is just such a feature which I don't need or want. I think this all adds up to a situation where you want to avoid manufacturer supplied firmware if at all possible.