I read this article stating that purely through a website, "without any user interaction" mass router infection is (/was?) possible. I'm not sure that this problem still exists as it was posted 3 years ago, but I'm still curious.

The article states:

How could an attacker "own" a router? First, the victim would have to be lured into visiting a malicious website, which would then push JavaScript with instructions to the browser to tell it about all locally connected devices. Second, after learning about the network and finding a device to target, the malicious website would need to launch a brute-force attack and divine login credentials for the device. Then, after gaining access to the device, the website could then send malicious firmware, instructing the browser to install it on the targeted device.

I get the part about HTML5 releasing IP addresses that allow a hacker to see devices on the network, but from there I dont understand how the hacker goes about breaking into and controlling the devices remotely.

I didn't realize that I could control even my own computer purely via my home network, without leveraging an application like TeamViewer or LogMeIn. How would the hacker make attempts at entering my password purely by knowing my IP address?

Can someone please explain the way this would work more clearly than the article?

2 Answers 2


These types of attack could be achieved via multiple CSRF attacks against the IP addresses discovered via the JavaScript reconnaissance tool.

Say your local IP address is You visit the malicious website, the JavaScript runs and finds the device on your network. Now, depending on how complex the JavaScript is, it will either identify the router make and model, or will just try a brute force attack in order to exploit the router. That is, it will send every exploit in its database at the device in order to try and compromise it.

Say that the BOB 2000 router has a vulnerability in that its URL /config/remoteConfigSettings does not implement any sort of authentication checks. As this page is only accessible from your local network, it is not normally vulnerable to internet based attacks.

However, after someone on your network has visited the malicious site, this could try every attack in its database to try and exploit the router at, including sending a POST request from the browser with the message body:



As this page is vulnerable, the request causes the WAN side of the router to be available for remote administration and disables the password authentication. The malicious website can report that a device was found to the attacker along with the internet IP for the attacker to log into later either manually, or more likely to add to an IP list for automated exploitation now that remote access is granted. The remote exploitation could include anything from altering DNS settings to an attacker controlled server for a future MITM attack, to malicious firmware updates to the router itself.

As well as checking for known vulnerabilities, the malicious script could also try regular router requests but authenticating with default or commonly used credentials.


Regarding @Ajedi32's comment about the Same Origin Policy - the scanner does not need the router to be in the same origin in order to fingerprint it. It uses a combination of IFrames and image tags to determine whether something and what was loaded and then matches these against known default IPs. From the author's site:

The scanner accesses a IFrame to perform a generic scan of the network for known default router IP’s, once a connection has been made it then passes the IP address and performs a lookup of routers/devices based on that address. The reason I have decided to do this is because I wanted the scanner to grab as many devices as possible because it will be impossible to finger print everything.

Once a IP address has been found it passes this to the finger printing function which uses a image object to make a connection to the device to see if the finger printing graphic is there.

Via DNS Rebinding

Another possibility not discussed in the linked article is a DNS Rebinding attack. Say the IFrame trick detects something is running on once the victim has visited evil.example.com. The attacker's detection script then runs a server-side script to rebind the DNS of evil.example.com to As the DNS entry has a very short TTL, the browser requeries the name lookup and gets the router address. As the router has default credentials setup, the malicious page can send AJAX requests to read and alter any content on the router's configuration page. This "bypasses" the same origin policy as the router now has the same origin as the malicious site (http://evil.example.com:80).

This attack would count on the browser timely rechecking DNS. Most browsers have their own DNS cache outside of the Operating System's, and may cache for longer than TTL dictates, hindering this type of attack.

  • 2
    Won't the same origin policy prevent the JavaScript from finding out much about the router, or even what IP it's hosted on, given that it can't retrieve the result from any AJAX requests sent to the router? (Unless the router was using CORS for some strange reason?)
    – Ajedi32
    Commented Jul 27, 2015 at 14:38
  • 2
    Yes, possibly. It depends how sophisticated the script code is. A sophisticated script may be able to use response time information (timing attack) or attacks such as cross site history manipulation to find out what it needs to know. Commented Jul 27, 2015 at 14:42
  • @Ajedi32: Answer updated regarding SOP. Commented Jul 27, 2015 at 17:03
  • @Ajedi32 Same origin policy does not protect against CSRF otherwise there won't be any CSRF.
    – billc.cn
    Commented Jul 28, 2015 at 13:14

Many routers have a web-based admin console, and it sounds like that's what this attack exploits. Frequently, the admin console is only accessible on the LAN, rather than allowing external connections - and this malicious JavaScript is what's used to bridge from the attacker's machine to the LAN.

One potential way that this attack could play out:

  1. Malicious JavaScript loads in the victim's browser. This doesn't need to break out of the browser's sandbox, or otherwise attack the user's PC itself - it just needs to run for long enough to attack the router.
  2. The JS scans for local network devices, and determines where the router is located ( and are pretty common IPs for a router, for instance).
  3. The JS then attempts to access the web admin panel of the router. Remember, you're inside the LAN at this point, so as far as the router is concerned, this is an internal connection.
  4. The router's admin panel asks you for a username/password. There's a good chance that this is still the default for that particular type of router. Often it will be something like "admin:admin".
  5. If the attacker is able to guess the correct username/password, they have access to the admin panel. If there's any ability to upgrade firmware from within the web admin panel (the article says this is sometimes the case), that's it - game over, the attacker can install whatever they like.
  • 1
    How exactly javascript is supposed to login into router web panel? Won't the same origin policy prevent it from reading the response?
    – Cthulhu
    Commented Jul 27, 2015 at 13:05
  • I will admit that getting around the same origin policy is the one part I'm fuzzy on, in this case - the article doesn't seem to explain that detail. If someone can fill in that gap, then by all means, go for it.
    – Soron
    Commented Jul 27, 2015 at 13:11
  • Would an attack like this only be interested in controlling my router, for data theft, or would this attack be capable of actually controlling devices (PC's for example) on my home network as well?
    – J.Todd
    Commented Jul 27, 2015 at 13:14
  • @JonathanTodd - if you control the router, you can execute a full MitM. This includes attempting to compromise computers by injecting malware into downloads. What it actually gets used for is up to the attacker.
    – Soron
    Commented Jul 27, 2015 at 13:19
  • @Cthulhu Some of the rules of same origin policies are specified in response headers of the target URL. The implication of that is that the browser will send the request to the target server and a response will be send back to the browser. But due to same origin policy, the browser will never hand the returned data over to the javascript code. However if the attacker already managed to replace the router firmware, he doesn't care whether the javascript got the confirmation.
    – kasperd
    Commented Jul 27, 2015 at 13:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .