More on HNAP - What is it, How to Use it, How to Find it

Published: 2014-02-15. Last Updated: 2014-02-15 14:40:40 UTC
by Rob VandenBrink (Version: 1)
5 comment(s)

We've had a ton of discussion on the most recent set of home router vulnerabilities based on the HNAP protocol (see Thursday's story posted by Johannes: https://isc.sans.edu/diary/Linksys+Worm+%22TheMoon%22+Summary%3A+What+we+know+so+far/17633) .  But what is the HNAP protocol for, and why is it so persistently enabled?

HNAP (Home Network Administration Protocol) is a network device management protocol, useful for anyone, but I think meant primarily for ISPs to manage fleets of devices deployed as part of your internet subscription.  It's covered in US Patent 20070130286 (http://www.google.com/patents/US20070130286), and is nicely described in a Cisco doc found here http://www.cisco.com/web/partners/downloads/guest/hnap_protocol_whitepaper.pdf

The protocol was patented originally by Pure Networks, but the protocol is now owned by and the implementation has been carried forward by Cisco.

So for devices that might potentially be deployed and managed by an ISP, or even by a corporation to remote sites, you want a management protocol that is on by default, and is difficult for the remote user to turn off.  Or from some reports, on some devices this protocol stays enabled even after your turn it off (oops, a little too persist there).

And yes, the irony of someone "in the biz" deciding in 2007 that we need yet another clear-text network management protocol does not escape me.  Since HNAP uses SOAP, you can use HTTPS as a transport, but the vulnerabilities to date have been mostly clear text, and the basic device info query is in clear text.

As Johannes described yesterday, an easy Linux / OS X way to test for HNAP is:

echo "GET /HNAP1/ HTTP/1.1\r\nHost: test\r\n\r\n" | nc routerip 8080

What else can you do with HNAP?  You can also just pull the basic "get device info" page using a browser client, wget or curl (you can get both of these tools for windows)

wget http://routerip/HNAP1/
or curl http://routerip/HNAP1
or just point your browser to http://routerip/HNAP1

I prefer using curl for this.  Easy to script, and since HNAP is SOAP based, you can do SOAP requests (using POST instead of GET) using curl (-X POST -H "whatever your soap string is")

What output do you get from this simple query command?  You get the basic device information, as well as the list of other valid SOAP commands you can send to your specific device:

C:\ > curl http://192.168.1.1/HNAP1

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="
http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/en
velope/">
<soap:Body>
<GetDeviceSettingsResponse xmlns="http://purenetworks.com/HNAP1/">
<GetDeviceSettingsResult>OK</GetDeviceSettingsResult>
<Type>GatewayWithWiFi</Type>
<DeviceName>Cisco40033</DeviceName>
<VendorName>Linksys</VendorName>
<ModelDescription>Linksys E4200</ModelDescription>
<ModelName>E4200</ModelName>
<FirmwareVersion>1.0.04 build 11</FirmwareVersion>
<PresentationURL>http://192.168.1.1/</PresentationURL>
<SOAPActions>
<string>http://purenetworks.com/HNAP1/IsDeviceReady</string>
<string>http://purenetworks.com/HNAP1/GetDeviceSettings</string>
<string>http://purenetworks.com/HNAP1/SetDeviceSettings</string>
<string>http://purenetworks.com/HNAP1/GetDeviceSettings2</string>
<string>http://purenetworks.com/HNAP1/SetDeviceSettings2</string>
<string>http://purenetworks.com/HNAP1/Reboot</string>
<string>http://purenetworks.com/HNAP1/RestoreFactoryDefaults</string>
<string>http://purenetworks.com/HNAP1/RenewWanConnection</string>
<string>http://purenetworks.com/HNAP1/GetWanSettings</string>
<string>http://purenetworks.com/HNAP1/SetWanSettings</string>
<string>http://purenetworks.com/HNAP1/GetRouterLanSettings2</string>
<string>http://purenetworks.com/HNAP1/SetRouterLanSettings2</string>
<string>http://purenetworks.com/HNAP1/GetWanInfo</string>
<string>http://purenetworks.com/HNAP1/GetPortMappings</string>
<string>http://purenetworks.com/HNAP1/AddPortMapping</string>
<string>http://purenetworks.com/HNAP1/DeletePortMapping</string>
<string>http://purenetworks.com/HNAP1/GetMACFilters2</string>
<string>http://purenetworks.com/HNAP1/SetMACFilters2</string>
<string>http://purenetworks.com/HNAP1/GetConnectedDevices</string>
<string>http://purenetworks.com/HNAP1/GetNetworkStats</string>
<string>http://purenetworks.com/HNAP1/GetClientStats</string>
<string>http://purenetworks.com/HNAP1/GetWLanRadios</string>
<string>http://purenetworks.com/HNAP1/GetWLanRadioSettings</string>
<string>http://purenetworks.com/HNAP1/SetWLanRadioSettings</string>
<string>http://purenetworks.com/HNAP1/GetWLanRadioSecurity</string>
<string>http://purenetworks.com/HNAP1/SetWLanRadioSecurity</string>
<string>http://purenetworks.com/HNAP1/GetRouterSettings</string>
<string>http://purenetworks.com/HNAP1/SetRouterSettings</string>
<string>http://purenetworks.com/HNAP1/GetFirmwareSettings</string>
<string>http://purenetworks.com/HNAP1/FirmwareUpload</string>
<string>http://purenetworks.com/HNAP1/DownloadSpeedTest</string>
<string>http://cisco.com/HNAPExt/HND/GetPolicySettings</string>
<string>http://cisco.com/HNAPExt/HND/SetPolicySettings</string>
<string>http://cisco.com/HNAPExt/HND/GetDefaultPolicySetting</string>
<string>http://cisco.com/HNAPExt/HND/SetDefaultPolicySetting</string>
<string>http://cisco.com/HNAPExt/HND/GetTMSSSLicense</string>
<string>http://cisco.com/HNAPExt/HND/ActivateTMSSS</string>
<string>http://cisco.com/HNAPExt/HND/GetTMSSSSettings</string>
<string>http://cisco.com/HNAPExt/HND/SetTMSSSSettings</string>
<string>http://cisco.com/HNAPExt/HND/GetPolicySettingsCapabilities</string>
<string>http://cisco.com/HNAPExt/HotSpot/GetDeviceInfo</string>
<string>http://cisco.com/HNAPExt/HotSpot/SetDeviceInfo</string>
<string>http://cisco.com/HNAPExt/HotSpot/GetGuestNetwork</string>
<string>http://cisco.com/HNAPExt/HotSpot/SetGuestNetwork</string>
<string>http://cisco.com/HNAPExt/HotSpot/GetGuestNetworkLANSettings</string>
<string>http://cisco.com/HNAPExt/HotSpot/SetDefaultWireless</string>
<string>http://cisco.com/HNAPExt/HotSpot/GetWANAccessStatuses</string>
<string>http://cisco.com/HNAPExt/HotSpot/AddWebGUIAuthExemption</string>
<string>http://cisco.com/HNAPExt/HotSpot/CheckParentalControlsPassword</string>
<string>http://cisco.com/HNAPExt/HotSpot/GetParentalControlsResetQuestion</string>
<string>http://cisco.com/HNAPExt/HotSpot/HasParentalControlsPassword</string>
<string>http://cisco.com/HNAPExt/HotSpot/ResetParentalControlsPassword</string>
<string>http://cisco.com/HNAPExt/HotSpot/SetParentalControlsPassword</string>
<string>http://cisco.com/HNAPExt/HotSpot/SetParentalControlsResetQuestion</string>
<string>http://cisco.com/HNAPExt/HotSpot/GetSwitchPortLEDSettings</string>
<string>http://cisco.com/HNAPExt/HotSpot/SetSwitchPortLEDSettings</string>
<string>http://cisco.com/HNAPExt/HotSpot/GetUSBCapability</string>
<string>http://cisco.com/HNAPExt/HotSpot/GetUSBPortSettings</string>
<string>http://cisco.com/HNAPExt/HotSpot/SetUSBPortSettings</string>
<string>http://cisco.com/HNAPExt/HotSpot/DisconnectVirtualUSB</string>
</SOAPActions>
<SubDeviceURLs></SubDeviceURLs>
<Tasks>
<TaskExtension>
<Name>Status Page</Name>
<URL>/Status_Router.asp</URL>
<Type>Browser</Type>
</TaskExtension>
<TaskExtension>
<Name>Basic Wireless Settings</Name>
<URL>/Wireless_Basic.asp</URL>
<Type>Browser</Type>
</TaskExtension>
<TaskExtension>
<Name>Linksys E4200</Name>
<URL>http://www.linksys.com/support/E4200</URL>
<Type>Browser</Type>
</TaskExtension>
</Tasks>
</GetDeviceSettingsResponse>
</soap:Body>
</soap:Envelope>

Most of these other HNAP commands require authentication and in many cases HTTPS encryption (depending on the device implementation), but the default credentials for home routers are well known and your chances of success are good if you are scanning using these - in most cases self-signed certs are in play, even if you are a "man in the middle" sniffing legit traffic with a tool like ettercap, chances are you will be successful.  And of course the HNAP exploits don't bother with silly things like credentials at all.

Exploits against HNAP are not new - they go back to the 2010 paper at www.sourcesec.com/Lab/dlink_hnap_captcha.pdf, which describes hacking dlink routers.

So, what's the easiest way to enumerate a network for HNAP devices?  For instance if you want to scan your home or work network for unknown / unauthorized HNAP services?  The HNAP1 query of course will get you what you want, we can use what we've learned so far to write a quick "chkhost.cmd" batch script for windows:

@echo off
REM SYNTAX: chkhost.cmd host.ip.add.ress
ping -n 2 %1 | findstr "time=" > nul
if errorlevel==1 goto endend
REM Host is up, now check for HNAP
curl -s http://%1/HNAP1 | findstr "HNAP" > nul
if errorlevel==1 goto endend
echo Host %1 has HNAP enabled
:endend

Wrap this up in a FOR /L loop in "chknet.cmd" to scan a /24 subnet:

@echo off
REM SYNTAX: chknet.cmd sub.net.address  (3 octets only)
echo Scanning Network %1.0
for /L %%G IN (1,1,254) DO call chkhost %1.%%G

Running it will find everything on that net (my test network just has the one router we've been playing with):

C:\> chknet 192.168.1
Scanning Network 192.168.1.0
Host 192.168.1.1 has HNAP enabled

But this is  a pretty crude method, and it takes quite a while for a /24 subnet.  Is there an easy tool that'll do the job?  I was very surprised to find that there wasn't an NMAP nse script for this.. However NESSUS does have a plugin for HNAP service identification under Service Detection / HNAP Detection (dating back to April of 2011 - http://www.tenable.com/blog/plugin-spotlights-new-nessus-os-identification-plugins)

As always, remember that scanning infrastructure that you do not own without permission is illegal.  These methods are intended to help scan networks you own and have permission to scan - your home network or the network at work for instance (note that you still require permission to scan your work network).

===============
Rob VandenBrink
Metafore

Keywords: HNAP scanning
5 comment(s)

Comments

Its important to point out that the exploit that "TheMoon" is using isn't an exploit against HNAP. Its an exploit against code in the cgi handling in httpd daemon for running tests which has nothing to do with HNAP. The ping.asp is a great example of another vulnerability that basically had the same cause. The vulnerable code is present (in slightly different forms) in firmwares for many different linksys devices going back to at least May of 2005. So its not just the EA and E series of devices. HNAP is just being used as part of the targeting package.

The attackers are using the HNAP queries to find devices with specific models and firmware so they know which attack to throw against routers. Which is nothing new, that has been going on for a while with vulnerabilities against another manufacturers router. HNAP just happens to make it very easy for attackers to do target recon and assessment.

There have been vulnerabilities in HNAP implementations documented over the year. But more common are these types of vulnerabilities where fields are not checked/limited on input and proper authentication isn't enforced for the admin CGI code.

As far as the use of HNAP. I know that Linksys/Cisco use it as a method for configuring your home/soho router through their "Cisco Connect" or "Cisco Connect Express" products. Which are software products (express is for android) that you use as a method of configuring the equipment without logging directly into the web administration interface.

Anonymous

Feb 15th 2014
1 decade ago

Any methods of defense against enumeration or the exploit?

Anonymous

Feb 16th 2014
1 decade ago

For protection, it'll be the same as any other vulnerability - no magic and no silver bullet. The SANS Critical Controls (http://www.sans.org/critical-security-controls) are a good place to start for your entire infrastructure, not just for protection from HNAP exploits. First, scan your infrastructure regularly so that you know what you are protecting (not just for HNAP) - See SANS Critical Controls #1. This will assist in identifying vulnerabilities (CC #4). Next, identify possible remediations - in this particular case, there ares likely one of a few possibilities:
- If it's on your corporate infrastructure, chances are that it's an unsanctioned device and you can just remove it. If it has a valid business use, the approach might be better phrased remove/replace.
- If it's legit, see about setting permissions to prevent remote administration, if the vulnerability is "outward" facing (CC #10/11)
- If it's legit and inward facing, restrict admin to an admin vlan or group of IPs (CC #10/11)
- ACLs on upstream devices can also help a lot in this regard (CC #10/11)
- Vendor patches and upgrades can often remediate - in fact they are often the first step down the path
- In this particular case a different option exists - for many of these platforms you can migrate to OpenWRT or DD-WRT, which eliminates the entire capability. (be sure to start tracking vulnerabilities on the new OS if you go this way).

A final option is to migrate to a non-vulnerable hardware platform (similar to the replace the OS approach, but not free). Given how many of the vendors in this space roll, some vulnerabilities just never get fixed, and new hardware might be the best approach (at least once every few years). This also often gives you new capabilities - faster processor, 802.11ac (faster wireless), or more IPS capabilities are common gains if you go this way.

Anonymous

Feb 16th 2014
1 decade ago

Enumeration / Attack Defense for SOHO routers

#1 Disable/Limit Remote Administration
You should never allow the device to be managed from the internet. So disable remote administration. Very rarely do these types of devices allow you to secure remote administration to level the level necessary for an internet facing service. So just disable remote administration.

#2 Become aware of what information you are leaking about your router/ap and the attack surface it reveals
Use a free web based port scan site to scan your external IP address. Check for common ports like TCP port 80,443,8080 being visible from the internet on your router/AP when scanned form the outside. Like most individuals you will find that even with remote administration off, many home routers actually respond on ports 80,443 or 8080.
These small home routers leak version/model information all over the place on the internet facing side. They leak information via HNAP requests, they leak model information in authentication denied messages (ex 'WWW-Authenticate: Basic realm="ASUS WL-500gP"'), they leak info based on error messages when requests fail. That information is used to target attacks or worse facilitate an attack against your firewall router.

#3 Do what ever you can to stop the leaks / stop being targeted based on your router version/info
This can be a little complicated as there are thousands of manufacturers/models/firmware versions.
A.Upgrade your firmware to latest version
B.Disable remote administration/management
C.Stop router from answering to queries from the internet
Its in many cases its difficult to do part C. You can try emailing the manufacturer and see if they have specific info on settings to make the router appear "dark" from the internet. Try asking in forums. If you get no solution and your router supports port forwarding can try something like sending the traffic that is coming inbound to your router to a black internal ip.

I posted on this before.
" In the absence of anyway to disable this in firmware the only reliable way I have found is to enable port forwarding and forward the traffic into the abyss. To make this safe you need to setup DHCP on your LAN side to not allocate certain addresses. Then port forward the incoming port 80/443/8080 traffic to an ip that isn't assigned to anything.

For example if your routers internal LAN IP is 192.168.1.1, setup DHCP to allocate only 192.168.1.5-192.168.1.250. Then set up port forwarding rules so that incoming traffic to port TCP port 80 and TCP port 443 on the WAN side of your router gets forwarded to 192.168.1.2.

Its not pretty, its not ideal. But on the devices i have tried, it has at least made port 80/443/8080 go dark to the WAN as the SYN's just go into nothingness."

#4 If you can't fix it and/or if you router is no longer supported (End of Life)...then buy a new quality product.
Most people don't realize that many SOHO routers, regardless of brand, share much of the same underlying code and vulnerabilities. Much of which is closed source. The routers are based on reference board designs/software packages from the chipset manufacturer. So often if a vulnerability exists in one, the same vulnerability often exists in other routers manufactured by a different company. So in many cases the security comes down to ability to limit attack surface and get tech support/patches in a timely manner.

Before you buy a router:
- Check to see how long the company will support/patch the router. (don't buy something that is months from End of life)
- Check to see how often the company releases Bug fixes/patches. This is a good indication of how much support effort company puts into the device and how soon vulnerabilities get fixed. For example: One AP/Firewall/Router I use has had firmware's released on 7/2013, 8/2013, 9/2013, 10/2013, 01/2014, 2/1014. Which shows a commitment to support and security patches. (you patch your PC...you should expect to patch the hardware that protects your PC from the internet)
- Ask questions in communities/tech support on locking down the router. Make sure its possible before you buy.
- Get a router from a manufacturer that provides new firmware notifications. Dlink, Asus, and a few others will email you when a new security patch or firmware version is available for your device. Some do it through the device others through the support website.
- IMHO (strictly my opinion) get a router/firewall/ap that is based off of one of the opensource router distributions. Open-WRT, DD-WRT, Tomato etc. As routers based off these open distributions are quicker to be patched and updated as the communities contribute more openly to the security of the product. They also tend to be supported by the community long after the router manufacturer has EOL'd your router. So your not stuck buying a new firewall/router ever two years.

Anonymous

Feb 16th 2014
1 decade ago

If you host a apache2 server, try the modsecurity module as a tarpit. You can google tarpit efforts regarding phpmyadmin enumeration attempts. Here is the custom rule I use:

SecDefaultAction log,allow,status:406,phase:2
SecRule REQUEST_URI HNAP1 t:lowercase,id:40003,pause:5000,log,noauditlog,status:402,deny

SecDebugLog /var/log/your-server-log/modsec_tarpit.log
SecDebugLogLevel 0

This will introduce a 5 second delay before being dropped. Due to the current volume of HNAP1 enumeration attempts this method makes perfect sense vice blocking whole domains.

As a added bonus, logwatch has this module as part of the logwatch suite. You can keep and eye on the OWASP ModSecurity Core Rule Set as well as your custom rules.

Anonymous

Mar 12th 2014
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives