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 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 192.168.1.10)
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.
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.
This will configure sslstrip to listen on tcp port 80 and log all HTTP POSTs to the file sslposts.txt
Monitor HTTP POSTs:
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 🙂
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.
The following are some recommendations to consider when securing administration access to your home Internet router.
- Disable remote administration access (over the web) or at least restrict it to trusted IPs only
- Whenever Possible – disable access to the administration page from the Wireless LAN (use wired only)
The following is my original submission to Secunia and NETGEAR disclosing the details of the vulnerability:
HTTP/1.0 401 UnauthorizedWWW-Authenticate: Basic realm=”NETGEAR WNR1000v3″Content-type: text/html
<meta http-equiv=’Content-Type’ content=’text/html; charset=utf-8′>
<p>Access to this resource is denied, your client has not supplied the correct authentication.</p><form method=”post” action=”unauth.cgi?id=78185530