Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Networking Security Technology

Millions of Home Routers Are Hackable 179

Posted by kdawson
from the pre-black-hat-frenzy dept.
Julie188 writes "Craig Heffner, a researcher with Maryland-based security consultancy Seismic, plans to release a software tool at the Black Hat conference later this month that he says could be used on about half the existing models of home routers, including most Linksys, Dell, and Verizon FiOS or DSL versions. The tool apparently exploits the routers through DNS rebinding. While this technique has been discussed for 15 years or more, Heffner says, 'It just hasn't been put together like this before.'" Notebooks.com has a list of routers tested and some advice on securing vulnerable routers.
This discussion has been archived. No new comments can be posted.

Millions of Home Routers Are Hackable

Comments Filter:
  • by Slippery Pete (941650) on Friday July 16, 2010 @08:03AM (#32925078)
    The Forbes article [forbes.com] has a Google spreadsheet of the routers.
  • Browser Issue (Score:3, Informative)

    by Manip (656104) on Friday July 16, 2010 @08:10AM (#32925124)

    First things first, you can block most of these attacks by setting a new router password and or changing the router's default IP. Secondly browsers could very easily solve this by disallowing mixed local (192.*, 10.*, 0.*, 127.*) and remote IP addresses from a single site. If it is a local server it won't be load balancing with something on the Internet and the reverse is equally true.

  • by Cato (8296) on Friday July 16, 2010 @08:18AM (#32925186)

    Here's a direct link to the spreadsheet of routers, without the IFRAME so it's easier to read: https://spreadsheets.google.com/pub?key=0Aupu_01ythaUdGZINXQ5Vi16X3hXb3VPYkszNXM0YXc&hl=en&output=html&widget=true [google.com]

  • by JayJay.br (206867) <100jayto&gmail,com> on Friday July 16, 2010 @08:22AM (#32925224)

    Here ya go:

    Vendor Model H/W Version F/W Version Successful
    ActionTec MI424-WR Rev. C 4.0.16.1.56.0.10.11.6 YES
    ActionTec MI424-WR Rev. D 4.0.16.1.56.0.10.11.6 YES
    ActionTec GT704-WG N/A 3.20.3.3.5.0.9.2.9 YES
    ActionTec GT701-WG E 3.60.2.0.6.3 YES
    Asus WL-520gU N/A N/A YES
    Belkin F5D7230-4 2000 4.05.03 YES
    Belkin F5D7230-4 6000 N/A NO
    Belkin F5D7234-4 N/A 5.00.12 NO
    Belkin F5D8233-4v3 3000 3.01.10 NO
    Belkin F5D6231-4 1 2.00.002 NO
    D-Link DI-524 C1 3.23 NO
    D-Link DI-624 N/A 2.50DDM NO
    D-Link DIR-628 A2 1.22NA NO
    D-Link DIR-320 A1 1 NO
    D-Link DIR-655 A1 1.30EA NO
    DD-WRT N/A N/A v24 YES
    Dell TrueMobile 2300 N/A 5.1.1.6 YES
    Linksys BEFW11S4 1 1.37.2 YES
    Linksys BEFSR41 4.3 2.00.02 YES
    Linksys WRT54G3G-ST N/A N/A YES
    Linksys WRT54G2 N/A N/A NO
    Linksys WRT160N 1.1 1.02.2 YES
    Linksys WRT54G 3 3.03.9 YES
    Linksys WRT54G 5 1.00.4 NO
    Linksys WRT54GL N/A N/A YES
    Netgear WGR614 9 N/A NO
    Netgear WNR834B 2 2.1.13_2.1.13NA NO
    OpenWRT N/A N/A Kamikaze r16206 YES
    PFSense N/A N/A 1.2.3-RC3 YES
    Thomson ST585 6sl 6.2.2.29.2 YES

  • Re:OEM firmware? (Score:2, Informative)

    by natehoy (1608657) on Friday July 16, 2010 @08:37AM (#32925348) Journal

    Probably not, but you're still better off making sure you are running the latest of your choice of firmware (Tomato just released a new version a couple of weeks ago, go get it now!).

    Doesn't hurt to make sure that you only allow https connections to the router's admin page (which means in Tomato that you'll get the inconvenient-but-useful "unverified certificate!" warning in Firefox that takes many ugly steps to get around, and as far as I know cannot be scripted), and setting a reasonably complex password.

    And don't assume that your local network is "safe". Run software firewalls and avoid things like open network shares.

  • by Zocalo (252965) on Friday July 16, 2010 @08:38AM (#32925350) Homepage
    As I understand it, it generally works like this: You set a ridiculously short TTL on the server hosting the exploit. When a victim connects you grab their IP address, add it and any other likely target IPs to the list of A records for the server and reload the zone. Your attack code just needs to wait for the TTL to expire, DNS to refresh and then try and connect to the target, which now appears to come from an attack on a trusted network.

    Going to be interesting to see what this talk is going to add to the mix though... Either way, now would be a really good time to change any easy to remember, alpha-numeric only device passwords, if you've got any.
  • Re:Browser Issue (Score:2, Informative)

    by Grandim (1390511) on Friday July 16, 2010 @08:39AM (#32925368)
    10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 0.0.0.0/8 127.0.0.0/8 You missed some privates and you had some legitimate publics listed has private.
  • by sullrich (78) on Friday July 16, 2010 @09:39AM (#32926060) Homepage
    We made changes to pfSense 2.0-BETAS that prevents the DNS rebinding attacks thanks to Craig's help.
  • by Anonymous Coward on Friday July 16, 2010 @10:04AM (#32926346)

    All the _new_ routers maybe. There are still millions of routers where the default password is static.

  • by mzs (595629) on Friday July 16, 2010 @11:11AM (#32927338)
        Vendor    Model    H/W Version    F/W Version    Successful
        ActionTec    MI424-WR    Rev. C    4.0.16.1.56.0.10.11.6    YES
        ActionTec    MI424-WR    Rev. D    4.0.16.1.56.0.10.11.6    YES
        ActionTec    GT704-WG    N/A    3.20.3.3.5.0.9.2.9    YES
        ActionTec    GT701-WG    E    3.60.2.0.6.3    YES
        Asus    WL-520gU    N/A    N/A    YES
        Belkin    F5D7230-4    2000    4.05.03    YES
        Belkin    F5D7230-4    6000    N/A    NO
        Belkin    F5D7234-4    N/A    5.00.12    NO
        Belkin    F5D8233-4v3    3000    3.01.10    NO
        Belkin    F5D6231-4    1    2.00.002    NO
        D-Link    DI-524    C1    3.23    NO
        D-Link    DI-624    N/A    2.50DDM    NO
        D-Link    DIR-628    A2    1.22NA    NO
        D-Link    DIR-320    A1    1    NO
        D-Link    DIR-655    A1    1.30EA    NO
        DD-WRT    N/A    N/A    v24    YES
        Dell    TrueMobile 2300    N/A    5.1.1.6    YES
        Linksys    BEFW11S4    1    1.37.2    YES
        Linksys    BEFSR41    4.3    2.00.02    YES
        Linksys    WRT54G3G-ST    N/A    N/A    YES
        Linksys    WRT54G2    N/A    N/A    NO
        Linksys    WRT160N    1.1    1.02.2    YES
        Linksys    WRT54G    3    3.03.9    YES
        Linksys    WRT54G    5    1.00.4    NO
        Linksys    WRT54GL    N/A    N/A    YES
        Netgear    WGR614    9    N/A    NO
        Netgear    WNR834B    2    2.1.13_2.1.13NA    NO
        OpenWRT    N/A    N/A    Kamikaze r16206    YES
        PFSense    N/A    N/A    1.2.3-RC3    YES
        Thomson    ST585    6sl    6.2.2.29.2    YES
  • by Anonymous Coward on Friday July 16, 2010 @11:18AM (#32927450)

    Seriously, let me filter this shit out of the RSS feed.

    Dude, this is /. If you can't figure out how to filter an RSS feed, you're on the wrong site. And frankly, given the nature of RSS, client-side filtering is the right answer.

  • by BZ (40346) on Friday July 16, 2010 @11:19AM (#32927474)

    > How does your DNS stack pick up a new IP address for a host name once it's already been
    > resolved?

    It doesn't. The way you do this is to return a list of two IP addresses for the hostname when it's first resolved; the first IP is your server and the second is the user's router.

    Then you serve stuff up as normal. When you want to carry out an attack, you point the browser to a url that has your hostname (probably in an iframe that's part of your page) and have your server refuse the connection. When that happens the browser will fall back to the next IP in the list and try it (that's how round-robin DNS works), and load a page from the router; if you pick the path part of your url right, this would be the login page. Now the key here is that web browser security policies are based on hostnames, not IP addresses. So the router's login page is now same-origin with yours and you can run script that does things to it. Like filling in the default admin username/password and submitting the form, for example. Or direct XMLHttpRequest access with the right Cookie headers, whatever.

    Changing the default password definitely helps.

    Some browsers are working on changes that would deny attempts to connect from a public IP to one on the local network, no matter what the hostnames are. That would stop this cold.

  • by BrokenHalo (565198) on Friday July 16, 2010 @11:39AM (#32927728)
    Of course, the sensible thing to do if you can't depend on your router to resolve IPs correctly (like if you don't own or have access to it) is to set your localhost to point DNS requests directly to a trusted IP address. Or, even better (if you're really paranoid), run your own bind.

Brain damage is all in your head. -- Karl Lehenbauer

Working...