Let it only be me who is (pen)testing my home network (Part I)
18.5.2017

In my previous article, I illustrated a few specific weaknesses of badly reputed networking protocol, namely UPnP. In my research, the latter has been proven to be fairly present in today’s home networks. Thankfully, my home router that I inherited trustworthily from my ISP (notice that I will avoid using any names or brands hereinafter) has all the external management options disabled by default. I honestly appreciate my ISP’s concern, since this same device has been up and running for quite a while now, without having me testing it in a paranoid way for its potential security weaknesses. There is, therefore, no exposure from the outside.

Then it hit me. Why not evaluate my home router’s security posture from the inside and see how well it performs. More importantly, how secure is my home office and its most valuable assets, users, and their data. You might find it odd for someone to internally pentest his or her home gateway, perhaps even a bit geeky, but it is justified. I may confidently argue here that the most sophisticated threats today are client sided. Why is that? First, it’s easier for the attacker. Second, almost everyone trusts his or her home residents, don’t they? Let me give you a few examples.

  1. UPnP is disabled or unavailable on a router’s WAN port. So why not exploit it from the inside, once the hacker or unauthorized code can access it, and continue moving laterally from there. Remember, UPnP requires no pre-authentication of devices participating in their self-provisioning process.
  2. The Router’s administrative Graphic User Interface is only available to internal users. So why not have them do the job of opening up backdoors from where the externals can move freely thereafter.

Both scenarios tend to be realistic only after certain prerequisites are met. Obviously, the external needs to get their homework done, analyzing victims and the potential attack surface. Would knowing the particular CPE’s manufacturer make a hacker’s job easier? Absolutely. There is a good chance of having a known exploit already available in the wild. How valuable would it be to an attacker knowing the particular ISP’s subscribers’ base? Priceless! Since the one thing those subscribers have in common is their vulnerable Internet home gateway. Then, the attacker would only need to google for the victim’s email addresses and distribute a decent exploit via his or her preferred phishing technique.

It took me a while searching for a match on known CVEs (Common Vulnerabilities and Exposures) or publicly available exploits. Nevertheless, I was more eager on identifying the potential weaknesses of my home gateway myself. In particular, I concentrated on those that could have been abused only by having the unaware victims deceived, such as fooling them to click a specially crafted URL or execute a malicious payload embedded in a macro enabled word document.

Potential XSS (Cross-site scripting) in the router’s administrative interface seemed a good candidate to start with. Such a flaw would let one to hijack the administrator’s session (cookie), once they clicked the maliciously formed URL. Initially, I discovered that the router’s administrative interface follows a particular administrator’s session ID, but the session cookie lacks the generally recommended “HTTP-only” attribute. Bingo! The other prerequisite for successful XSS flaw demonstration is a weakly implemented user’s input validation. With the use of interception proxy tool, I literally flooded the router’s most interactive configuration menus, looking for possible reflected inputs in HTML rendered outputs. (Un)fortunately, each user’s inputs is properly validated for known bad meta-characters on both the client (JavaScript) and server (router) side. I found it entertaining though, receiving gateways’ informative complaints about each attempt, stating which particular characters are violating its input validation control. Beneficial feedback in the form of “Special characters such as & < > " ' / \ are not valid” when trying to evade input filters applied to Wi-Fi SSID configuration menus. Well done!

I was inspired enough to move forward toward more advanced pentesting techniques. The first on my list was the security analysis of potential CSRF (Client Side Request Forgery) weaknesses. My goal was to construct a catchy URL that would modify a critical router’s setting in the attacker’s favor by simply clicking it.

I found the router’s external management capabilities the most intriguing to play with. Utilizing an interception proxy, I replicated the origin HTTP(S) POST request, that is made responsible for remote administration restriction. Soon I discovered self-explanatory HTTP(S) POST parameters, named “remote management" and “upnp enable”. The two carry a default value of "disable" within each form submission.

Input

There is no CSRF token implemented within HTTP(S) POST transactions that would correlate each request coming from intended legitimate administrator. Modifying those informative values to “enable” would, if vulnerable, change the default router’s behavior so that it would start serving its hidden provisioning features. Worked like a charm just by clicking the specially crafted URL that served my CSRF HTML form! That’s no real benefit for an attacker, one might argue. He or she would still need to brute-force the administrator’s credentials in order to continue with post exploitation, unless those have been left as the default, such as “admin/admin” or “admin/blank”. Does that sound familiar?

Independently, I narrowed down my interest in those vital settings in the router’s configuration menus. Inadequately provisioned, those would allow an external hacker to control each request coming from the victim’s internal network. I forced myself to think outside the box! So I thought of DNS, the backend naming service that may be provisioned manually on any SOHO router. It goes without saying that DNS may also be external to home users, e.g. placed somewhere on the Internet. DNS, when evil, may as well serve fake name records, pointing client queries to cloned landing pages. See where I’m going with this?

Having that illustrated, I formed an additional URL, this time serving a DNS modification form. Below is a “one click away” snippet of my code that modifies my home gateway’s DNS to its evil alternative (hosted on 1.2.3.4). 

html 

Addressing my home gateway with the modified HTTP request not only reconfigures its pre-built DNS settings but also reloads the device, surprisingly without the need for re-authentication. I should make it very clear here that such a request is only made effective when the victim is already pre-logged in. Which is not unlikely after he or she receives a phishing mail with the intruder’s persuasive (that’s why its localized) instructions.

Mail


Picture translation:
Subject: [NEWS] Program scheme extension
Dear subscriber, to enable the extended Program scheme (50 new channels) on your TV device, please follow the INSTRUCTIONS.
When logging in, enter your password provided by your Service Provider.
Best Regards, Your SERVICE PROVIDER

As Proof of Value, my evil DNS server has served only one “name record”. Cloned Gmail landing page, prompting for internal users passwords. Only consider how many other services you have linked to your Gmail account, and if you are still not convinced, take your time to watch Mikke’s keynote. It could have been any other bookmarked resource though, such as e-banking or your company VPN address. HTTP or HTTPS protected, either way it is controlled by the attacker. These are only my darkest fears; what comes to the top of your mind?

I encourage those reading my pentest findings not to exaggerate with immediately unplugging their home networked devices. It's not just black and white. Moreover, a variety of prerequisites need to be met for such an intrusion to become reality, from the attacker’s in-depth information gathering on ISP and potential weaknesses on its CPE devices to fooling the ISP’s subscribers’ base into clicking the “phishing” link. It does make me consider the potential attack surface of ongoing IoT and orchestration deployments; since there are quite many parallels that I can already project there. Am I the only one?