Paid Advertising
web application security lab

Router Reconfiguration XSS

Update: Thank you to Zulfikar to pointing me to the real website where this was first discussed and indeed there was mention of Jeremiah’s work. Snarky comment now only applies to eWeek’s coverage, and my apologies to Zulfikar for my unfair comment - as it wasn’t him who said this.

I just got this link sent to me, and it is essentially a re-hash of the JavaScript intranet hacking stuff Jeremiah and I came up with last year. Essentially Zulfikar Ramzan of Symantec is saying that you can use the old technique (which he is calling a new technique) that we came up with to hack into routers. The only vaguely original thought in the article is that they are using it to change the DNS entries for use in pharming attacks. Of course there was no attribution - that would be silly because, of course, this is new. Except for… these little teeny weeny inconvenient tidbits:

Turning off security using CSRF - August 7th, 2006

JavaScript port scanners - August 2nd, 2006

Cross Site Scripting Talk at Blackhat - July 25th, 2006 (where I first mention attacking network devices)

XSS talk at BlackHat - July 1st, 2006 (where I first mention attacking other layers of the OSI model)

While not in any way at all new, it’s interesting to hear the statistics that 50% of home routers are vulnerable to this form of attack. Pharming is one of those things I have always scoffed at, because before this attack they primarily relied on DNS hacking (not of the home user’s DSL connection but of the DNS server they used). It’s a slightly different take on the same old hack, that has some interesting implications.

So, while not new, it’s another take on pharming, which I had pretty much thought was a dead topic. I guess we’re bringing it back, and calling it new. While we’re at it, I’m going to invent the Internet again. Al Gore will be pissed, but so what? /snarky

7 Responses to “Router Reconfiguration XSS”

  1. Zulfikar Ramzan Says:

    Hi Rsnake,

    The article in the link you were sent was based off of a blog entry I posted:

    As the blog entry indicates, the Drive-by Pharming concept was very much inspired by the excellent work Jeremiah presented at Black Hat. (Actually, I wasn’t at BlackHat, but got to hear Jeremiah talk about it at an OWASP meeting a little later).

    I also wrote in the blog that I felt that the pieces of the drive-by pharming concept are easy enough to put together by anyone sufficiently familiar with how JavaScript host scanning works (certainly that would include yourself, Jeremiah, and others).

    In my mind the technical details of the attack are far less interesting than the potential widespread implications. There are, after all, a large number of people who own broadband routers (whether wireless or wired) that have never changed the default password. That all of these users are susceptible to a pharming attack that involves viewing a web page is alarming.

    I just wanted to clarify that since while I have control over what I can write in my blog itself (and certainly made efforts to set our work in the appropriate context relative to the JavaScript host scanning work), I have considerably less control over what appears in a seperately written article about the blog.


  2. SecuriTeam Blogs » Wireless “Drive-by Pharming Threat” Says:

    […] Read this before reading this blog entry. […]

  3. Spider Says:

    Yeah. It seems to happen a lot on the web. There should just be one wiki for everyone to publish to and refer. The only way as a developer interested in writing secure code to keep a tabs on these issues is to visit several blogs/sites and subscribe to various mailing lists. If even symantec didn’t even go to the trouble of doing a google search for previous exploits of this nature how does anyone expect anyone less security minded( you know the ones who write exploitable code, surely not me;) ) to?

  4. John @ Says:

    The paper does attribute Jeremiah and I think does a fair job at not taking credit for something groundbreaking. The popular media is just to lazy to point all this out (plus its not “news” if its not “new”). But we need to remember that if the bad guys had a good imagination we would all be in a lot more trouble. A lot of these exploits have a lot of potential when combined with other exploits and a little social engineering. I think the paper does a very good job of showing what’s easily possible using a bunch of old problems that no one is addressing.

    A reformed war driver acquaintance of mine use to go around and change router passwords to something only he knew. He thought they might come in handy someday and wanted to lock them down before someone else got to them. Luckily ([cough, cough] Justin) reformed before he figured out what to do with them. The home and SOHO users never open the router admin again after the initial setup so they’ll probably never know.

    If the bad guy can obtain enough automation in this process and are able to attract enough people to the exploit page these routers could be used for a lot things. Replace the ROM and turn them in to onion routers, botnets, redirecting (or mirroring) all user LAN traffic through the bad guys system for analysis / password pharming, etc. I think getting this to scale to big numbers is the hard part. But having even a few onion routers is always useful.

    Its just such an easy exploit to fix. As I mentioned in my article just change the darn router password!


  5. RSnake Says:

    Zulfikar, thank you for writing… there was no link from the eWeek article so I had no idea where that had come from. My apologies and thank you for setting the story straight. I do agree that more than the actual attack it’s the percentage risk that is interesting. Anyway, I updated the blog to reflect this information.

  6. Mark Goodwin Says:

    I came up with using Jeremiah’s techniques for Pharming several weeks ago. Joe Walker published a write up of this well over a week before Zukifar’s write up appeared.

    Joe’s write up is pretty good; I think it deserves linkage:



  7. Nik Cubrilovic Says:

    True I read it and thought ‘nothing new’ as it has been discussed previously - didn’t realize where the original credit did lie but it is hard with security related research to retain attribution (unlike source code) since it is research based