Slashdot Mirror
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.
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.
I understand these things quite well, as I wouldnt be in the field if I didnt. NAT provides some degree of security in the sense that if you are on an IPv4 network (99% of home users) on an RFC 1918 network (99% of home users) with NAT enabled, it is impossible for anyone to send an unsolicited datagram to your computer behind the NAT.
There are technologies which punch holes in this (like uPnP), but that does not change the implicit security.
NAT in a typical Linux based router does not prevent someone on the external interface from talking to any port and any host on the internal network
Then you have a static port mapping. Generally to get through the NAT you need to know the public IP and port (out of 65536) you want to connect to, which is dynamically assigned. Then you need to deal with the fact that anything you send is going to be pinned to a specific client port not of your choosing, and you will not know the correct source port to get the client to accept your unsolicited datagram (whch will thence be dropped).
I never said it was perfect security, but it prevents folks from accessing listening ports (like 135-139) as a listener port wont have a dynamic mapping-- only outbound traffic gets those.
But you seem to think Im wrong, so educate me. Lets set up a scenario.
Gateway Public: 1.2.1.1
Gateway private: 192.168.50.1
Windows XP box: 192.168.50.5
No firewalls, NAT on the gateway, Windows XP listening on port 135-139.
What Layer3/4 headers are you going to use thats gonna get a packet delivered to one of those 4 ports on that XP box?
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.