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.

This new feature is called WiFi-Protected Setup. WPS is a standard designed to ease the distribution of strong WPA/WPA2 encryption keys. Anyone who has tried to enter a 60-character WPA key into a Wii will immediately appreciate WPS; when you want to add a new client to your wireless network, you simply push a button on the router, push a button on the client (clients typically have “soft” buttons), and the two will negotiate an 802.11 EAP session which the router uses to securely send the network encryption key to the client.

Unfortunately, along with this ease-of-use, WPS brings a whole new threat into SOHO router networks: physical attacks. Physical tampering with a router used to mean some malicious person bringing in a laptop, plugging it into the router, and trying to brute force the router login. But now, an attacker can install a simple hardware back door which activates WPS at a specified interval. In fact, in some cases this can be done with nothing more than a stick of gum.

The attack is very simple; you just have to create a circuit that “pushes” the WPS button on the router. With some routers, such as Linksys, you can simply short out the pins on the WPS button, causing WPS to remain permanently on. This can be done very easily using the foil wrapper from a stick of gum:

Place the foil in the Linksys' case

When the board is placed back in the case, the foil shorts the pins on the WPS button

Use the remaining foil to cover up the WPS LED

Note that since WPS will always be activated, the WPS LED will be constantly blinking, so it’s probably a good idea to cover up the LED as shown in the above picture.

Although a simple hack, using gum to back door a router is not the best solution. In the routers tested, the gum hack only worked on our Linksys router; the rest require us to push, hold, and release the WPS button before they would activate WPS. Even in the Linksys device, this is a non-stealthy hack, as the administrative interface will (rather obnoxiously) indicate that WPS is activated whenever an administrator logs in to view the wireless settings.

A far better solution can be found by using a simple NE555 timer circuit. The push buttons are typically configured with one contact connected to ground, and the other contact connected to something else that reads the button’s state. Using an NE555, we can connect the non-ground pin on the button to ground for a second or two, and then return the pin to it’s open state. The following circuit will push the WPS button for 1.5 seconds every 2.5 minutes:

NE555 Schematic Diagram

Vcc and ground are connected to the router’s DC power supply. Since the 555 can be powered from a wide range of voltage sources (4.5v – 16v), no voltage regulator should be required (routers typically run off of 5 – 12 volt DC power adapters). Conn1 is connected to the non-grounded pin on the WPS button.

The output (pin 3) stays high for 2.5 minutes and goes low (i.e., is grounded) for 1.5 seconds. D1 ensures that there is no charge flowing into pin 3 (probably not likely, but we don’t know exactly what the WPS button is connected to). When pin 3 goes low, it effectively grounds the button connected to Conn1; resistor R3 limits any current flowing through D1 during this period. The circuit can be modified to stay high for much longer periods of time by increasing the value of the R1 resistor.

Although the NE555 is not very precise when used to time long periods, precision is not really a concern in this application, so activating WPS once every 10-12 hours is possible. This has the added benefit of making such a back door more difficult to detect; WPS has a two minute time out period (if no client is found within two minutes, the router stops looking for a client until the button is pushed again), so the light will only be blinking for two two-minute intervals throughout a 24 hour period.

Below are pictures of the above circuit connected to several routers from various vendors. Since the WPS button works the same way on basically all routers, this circuit is a universal hardware back door for practically any router that has WPS support:

The circuit connected to a Linksys WRT160N

The circuit connected to a D-Link DIR-628

The circuit soldered up and placed inside a Belkin F5D8233-4v3

Now, you just wait for WPS to be activated (WPS state can be passively monitored real-time using our WPSpy tool) and use a WPS-capable WiFi card (or software) to retrieve the key:

Using a Belkin WiFi card to retrieve the WPA key via WPS

Specifically, here’s what we’ll need:

• If the access point supports WPA and/or WPS, enable both of those features. This can help us in creating more robust signatures.
• Place your wireless card in monitor mode and use Wireshark to capture the access point’s beacon packets (we only need one beacon packet, so don’t feel like you have to capture large amounts of data).
• Save the Wireshark capture and send us the pcap file along with as much information as you can about the access point (vendor, model, firmware version, hardware revision, etc).
• Send all submissions to dev [at] sourcesec.com.

Our presentation focuses on SOHO router security, specifically, exploiting router vulnerabilities to gain direct access to the internal WiFi network without having to crack encryption keys.

We discuss various methods of router reconnaissance, including some new tools that we’ve written specifically for this purpose, how to obtain WPA keys using simple HTML img tags, and how to own the WiFi network remotely using anti-DNS pinning attacks.

We even throw in some hardware hacks, describing how to implant a hardware backdoor into a router’s WPA encryption using nothing more than a stick of gum or a simple $8 circuit.

Download the slides here!

WPScan actively sends 802.11 probe requests to access points that advertise WPS support. It then parses out the WPS Information Element in the resulting probe response and displays the results. This is a very useful fingerprinting tool since nearly all new routers have WPS enabled by default, and most vendors will actually put the exact make, model, and version of the router in the probe response!

WPSpy is a tool to simply monitor and report changes in the WPS status of and access point. This is particularly useful if you are running some of our described attacks that leverage WPS to gain access to the WLAN.