D-Link has made some statements that we’d like to offer rebuttals to, as we either suspect them to be incorrect or find them to be downright confusing. The below quotations are from the ZDNet article:

The model that D-Link said is not in the European market is DI-524 (C1). In addition, that model does not support HNAP, the company noted.

Yes, the DI-524 hardware version C1 does in fact support HNAP. It was one of the first D-Link routers to do so. Install the most recent firmware release (version 3.23). HNAP is clearly there and vulnerable.

The non-existent model is DIR-628 (B2), as only A hardware has ever been released for that device.

Correct, the DIR-628 hardware version B2 does not exist; that’s bad on us. The version we tested was actually A2 not B2 as we erroneously reported. I find it odd that D-Link doesn’t seem to have even tested their A-series DIR-628s though. If they had, they would have found that they were vulnerable.

Finally, model DIR-655 (A1, firmware 1.30EA) runs a restricted firmware version related to East Asia and therefore irrelevant for Europe.

There seems to be some expectation from D-Link and others that we have tested every firmware version for every D-Link router in existence. That is simply not possible for us to do. We tested three different D-Link routers with four different firmware versions that spanned a period of three years and two continents, and they were all vulnerable. But that is all that we have tested, and therefore all that we can confirm. Just because we didn’t test European firmware doesn’t mean that it is or isn’t vulnerable. It just means that we didn’t test it.

The networking company said on Monday that the problem, discovered by security researchers SourceSec, affects three of its wireless routers: DIR-855 (hardware version A2), DIR-655 (versions A1 to A4) and DIR-635 (version B).

Interestingly, D-Link told PCWorld that there were five routers affected: the DIR-855, DIR-655, DIR-635, DIR-615, and the DI-634.

Now, we know that the DI-524 and DIR-628 are vulnerable. We have also had reports that the DIR-300 is vulnerable (though we can’t confirm this). Yet D-Link does not mention any of them in their list of vulnerable routers. So are there three router models affected? Or five? Or more? Has D-Link performed comprehensive testing on their routers? Or are these just the ones that they’ve tested so far? I can assure you that the DIR-628 and DI-524 need to be added to this list; which others are missing?

In addition, just running the exploit code was not enough to compromise D-Link routers, it said. “It is important to note that running the code on its own is not sufficient to hack into the router: only the software tool provided seems to achieve this result,” said the D-Link statement.

OK, now I’m confused – running the code won’t hack the router, but running the software will? It’s a bash script: the code is the software (Einhorn is Finkle…Finkle is Einhorn…). Any piece of software that can make Web requests can be used to exploit the vulnerability. Web browser? Check. Netcat? Yup. Wget? Sure! Curl? Definitely! I’m not sure what D-Link is trying to say here.

And finally, there’s the inevitable passing of the buck:

“By publicising their tool, and giving specific instructions, the authors of the report have publicly outlined how the security can be breached, which could have had serious repercussions for our customers,” said the D-Link statement.

Yes, of course. It’s not D-Link’s fault for selling vulnerable routers to their customers. It’s obviously our fault for informing their customers of the vulnerability. Shame on us.

[the captcha is] not really broken. It’s circumvented, but not broken.

Agreed; we’re still looking into some OCR engines that might be used to break the captcha completely. Perhaps a more fitting title would have been “D-Link Captcha Implementation Partially Broken”.

It turns out all that’s required to access the router’s setup page is the hash, so the feature provides an easy way for anyone within range to access the panel that controls all kinds of sensitive settings and contains the WPA password.

No, you cannot access the full router control panel with this vulnerability. Only a few pages (basically any XML page) honour authentication without captcha, one of which is the WPS activation page. Once WPS is activated, anyone within WiFi range can access the network, and then they can access the router control panel.

If you use a dictionary or simple alphanumerc passphrase then it can’t be brute forced unless they pass the CAPTCHA too.
Yes, it’s very annoying on web pages. But on a router page you might use once a month? It’s not such a bad idea.

Actually, if you look at the threat that the captcha is supposed to prevent, it is a terrible idea. A captcha does not provide security, it only attempts to prove that whoever performed a given HTTP request was a person. Yes, captchas may block automated attacks (assuming that the bot cannot break the captcha, which they have been known to do), but remember that the threat consists of a trojan running on the client’s PC that is used to attack the router. What’s stopping the malware from sending the image back to the attacker who can then read it and tell the trojan what it says? Yes, as shocking as it may seem, hackers are people too.

For this to work the attacker has to 1. be in your wifi range and 2. be wired into a pc on your lan i.e have a physical connection…Truth is, if you use the full length hexadecimal wpa2 key it will take a long, long time for anyone to crack your wifi.

To address first point, yes, the attacker does have to be within WiFi range; thankfully, it cannot be used to perform an entirely remote attack. I think it is important to keep in mind however, that besides the proximity requirement, a WiFi compromise is as dangerous (if not more so) than an attacker changing your router settings. Think about it; if he does get some malware on your PC, he only has access to one machine on the network, may not have sufficient permissions to do what he wants, and at the very least will have to upload a bunch of tools to your PC in order to propagate through the rest of your network. With your WPA key in hand, he can put as many of his own machines on your network as he wants.

As for the second point, please refer to my earlier point regarding the threat that the captchas are supposed to prevent. The attacker does not need a physical connection to your network; he just needs you to have one. The “truth is” that this can also be exploited via pure JavaScript (i.e., no trojans on your PC). Why would an attacker take the time to crack a 63-character WPA2 key when he can get you to click on a link and hand it to him?

Compromised web page is not wifi related, hence this is separate.

Technically, this is correct; there is no WiFi vulnerability per-se. However, the Web page vulnerability allows an attacker to bypass any WiFi security that you have in place, so I wouldn’t say that they are completely un-related.

most routers by default dont allow you to access the config from the WAN port, only if you are on the LAN

This is not a WAN issue. The attacker is in your browser or on your PC, which is on the LAN, hence, he has access to the router config page on the LAN side.

I thought most new routers require you to set them up properly to work and no longer “work out of the box” to prevent default password.

I wish! That actually would have been the proper response to such threats, had D-Link really wanted to make their routers more secure. To my knowledge, no consumer-grade router requires any type of configuration before they’ll work.

Honestly, If you have any advanced education you should be using OpenWRT or DDWRT and not the crap firmware in these routers.

Be careful what you wish for.

I would like to see a proof of concept. I do know that the salt hash is easily attainable in a txt file on the router.. however I forget the local url that retrieves it.

The salt is a JavaScript variable located in the router’s index page (http://192.168.0.1/). We are not releasing any code at this time, however, the attack is easily re-producible:

1. Go to http://192.168.0.1/ and view the page source; locate the salt value (search the source for “salt”).
2. Using the nicely-commented send_login JavaScript function in that same page, generate the MD5 hash for the User account with a blank password (which is the default).
3. Visit this URL: http://192.168.0.1/post_login.xml?hash=<insert the hash you calculated here>
4. Visit this URL: http://192.168.0.1/wifisc_add_sta.xml?method=pbutton&wps_ap_ix=0

If you have WPA enabled, your WPS light (located on the side of the D-Link) will start flashing. Any WPS-capable WiFi card can now connect directly to your WiFi network. If you aren’t using WPA, then anyone can connect directly to your WiFi network anyway. If you want to test the pure JavaScript variant of this attack, you’ll have to perform some anti-DNS pinning in order to read the salt value from the index page. While Firefox is kinda-sorta immune to anti-DNS pinning (only because it takes two minutes to perform in FF), IE and Opera users are prime targets.

As always, there are going to be a lot of other great talks there too; tickets are still available and are only $100 for the conference, so if you’re going to be in the Chicago area May 8th and 9th, we hope you’ll stop by!