back to article Password 'XXXXairocon' pops Wi-Fi routers from ASUS, ZTE and others

A bunch of home gateway vendors, presumably sourcing their firmware from the same place, can be hijacked using depressingly common hard-coded logins. As the Carnegie-Mellon CERT states, the vendors involved are ASUS and ZTE in Asia, European vendors Digicom and Observa Telecom, and carrier Philippine Long Distance Telephone ( …

  1. DRendar

    "...recommends blocking telnet and SNMP..."

    Wait... Telnet and SNMP are OPEN on these devices? To the Internet presumably (seeing as that's the only place these 'routers' apply firewall rules)

    What. The. Fuck?

    I cannot comprehend why in the bloody year 2015 telnet is even installed on these devices, let alone open to the world.

    1. Anonymous Coward
      Anonymous Coward

      Re: "...recommends blocking telnet and SNMP..."

      Just a guess but... in all the cases I've seen, ports/services useful in the design and test phases (often including default hardwired back doors) are left enabled when the RTM leaves the building. Those engineers are pulled off to fight another fire before cleanup is complete.

      1. Doctor_Wibble

        Re: "...recommends blocking telnet and SNMP..."

        > ports/services useful in the design and test phases

        Though there's not really an excuse for the config defaulting to 'open'... I can see why for the plug-and-play side they might want snmp enabled, but telnet - definitely not.

        As for why telnet and not ssh, that's down to resources - a telnet service uses naff-all resources, whereas the requirements for ssh will add at least 25p to the hardware cost and there's not many manufacturers who will go for that. Plus all the patching/reflashing now that people have actually been looking at the code.

        > Those engineers are pulled off

        I think you might have inadvertently grasped why the technical professions appeal more to men than women, and the situation needs a firm hand to resolve etc etc, see recently-republished 'single entendre' article...

        1. TeeCee Gold badge
          WTF?

          Re: "...recommends blocking telnet and SNMP..."

          As for why telnet and not ssh...

          You mean so that once your intruder has logged in using its predictable password they'll have a secure connection to it?

          That'd be nice for them.

          1. Doctor_Wibble

            Re: "...recommends blocking telnet and SNMP..."

            > You mean so that once your intruder has logged in using its predictable password they'll have a secure connection to it?

            Quality sarcasm aside, I may have misunderstood but would that not have been better directed to someone who was actually asking the question as opposed to making an attempt to answer it? (genuinely confused, perhaps my original wording was unclear)

            1. Anonymous Coward
              Anonymous Coward

              Re: "...recommends blocking telnet and SNMP..."

              You seemed to be recommending using SSH and not Telnet, but a hard-wired obvious login is a hard-wired obvious login, regardless of protocol.

        2. Alan Brown Silver badge

          Re: "...recommends blocking telnet and SNMP..."

          "I can see why for the plug-and-play side they might want snmp enabled"

          Why? P&P uses uPNP, not snmp.

          1. Doctor_Wibble

            Re: "...recommends blocking telnet and SNMP..."

            I had hoped that "the plug and play side" might have been taken as trying to convey the principle rather than trying to invoke the spirits of the precise technical specification of pnp or upnp or vat or e&oe, i.e. the 'plug it in and the magic thingies all work on their own'.

            This is obviously my day for being misunderstood...

  2. Anonymous Coward
    Anonymous Coward

    That is a strong password

    that password is a unique to device 12-hex digit + 7 common letters, which would to brute force attack be longer to crack than most passwords. One bank I used to have accounts with has a 12 char limit on passwords.

    1. TimeMaster T

      Re: That is a strong password

      If the attacker was brute forcing you would be right.

      But there are ways to get the MAC address of a remote computer with only the IP address.

      1. Robert Helpmann?? Silver badge
        Childcatcher

        Re: That is a strong password

        But there are ways to get the MAC address of a remote computer with only the IP address.

        On the plus side, I believe at least one of these allows owners to change their MAC address. On the minus, none ever will. Additionally, most MAC ranges are registered by company, so an attacker could rely on a rainbow table rather than being forced to use a brute-force attack to compromise one of these boxes.

        1. MacGyver

          Re: That is a strong password

          "On the plus side, I believe at least one of these allows owners to change their MAC address. "

          I'm betting that the password is dynamic based on the current MAC and not the original.

          This is why all source code should be available for review upon demand. It's hard to hide in the open.

          1. Alan Brown Silver badge

            Re: That is a strong password

            "This is why all source code should be available for review upon demand. It's hard to hide in the open."

            That assumes someone will get around to looking at it.

            There are plenty of cases of "casting an eye over the code" on decade+ old software, only to find the digital equivalent of Bin Laden sunbathing naked on his roof, waving at passing spy satellites - the point being to see something you have to know more or less where to look.

      2. Anonymous Coward
        Anonymous Coward

        Re: That is a strong password

        "But there are ways to get the MAC address of a remote computer with only the IP address."

        Interesting, how do you do that (assuming you are not on the same LAN)?

        1. Roland6 Silver badge

          Re: That is a strong password

          There is a good description of the exploit here [you will need to translate]: http://blog.alguien.site/2014/02/hackeando-el-router-zte-zxv10-w300-v21.html

          Basically, by default the router allows access to its 'management' ports from the Internet. Fortunately it would seem the management ports are behind the firewall and hence by using firewall rules, you can prevent direct remote access.

      3. Warm Braw Silver badge

        Re: That is a strong password

        >there are ways to get the MAC address of a remote computer with only the IP address

        If you're on the same LAN, you can likely find the MAC from the ARP table. If your router connects via PPoE, then the head end will have its MAC too. Otherwise, unless public SNMP is enabled by default on the router, it might be tricky.

      4. Alan Brown Silver badge

        Re: That is a strong password

        "But there are ways to get the MAC address of a remote computer with only the IP address."

        In a layer2 network it's easy.

        For something further away than that, it's a lot harder then you seem to think.

    2. Salts

      Re: That is a strong password

      I suspect it is the last 4 digits of the MAC hence XXXXairocon

  3. gollux

    In other news, idiot device developers still deploy telnet.

    1. RavingDaveD

      Long live Telnet

      I'm glad they do allow telnet, saved my life a short while ago where I set my router (via the usual browser interface) to allow external management access via http over the internet/WAN port. What I didn't know was that this then completely disabled http access via internal n/w IP address / browser to manage the router. The system basically would only allow access from a specific IP address from the WAN/DSL port, i.e. the WAN IP as provided by my ISP at the time I pressed the 'go' button. This was a dynamic IP and so unlikely ever to be seen again! Helpdesk of the router manu said can only be fixed by doing factory reset. This would lose all my configs etc.

      Telnet access was still working from internal IP so used this to save configs etc. Did Factory reset and restored saved configs et voila, all back to normal!

      So, Telnet gets my vote

      1. Loyal Commenter Silver badge

        Re: Long live Telnet

        telnet from internal IP isn't the problem. The problem is that the manufacturers make these devices that allow remote admin from the WAN side (by whatever mechanism), and then compound their crime against common sense by hard-coding a user name and password for it.

        The first thing any sensible person should do when getting a new piece of network kit such as a router is to go into the configuration settings and make sure all WAN-side access is disabled. That, and check for firmware updates. These days, it's often trivially easy to do so by going to the gateway address in a browser (usually 192.168.0.1, 11.0.0.1, or similar), logging in with the default credentials (9 times out of 10 it's admin/12345 or similar) and changing those settings, along with the default password.

      2. D 13

        Re: Long live Telnet

        @ RavingDaveD

        That's a much better argument for backing things up before you make changes than for keeping telnet.

        1. Down not across Silver badge

          Re: Long live Telnet

          @ RavingDaveD

          That's a much better argument for backing things up before you make changes than for keeping telnet.

          I think you're kind of missing the point (slightly). The point (IMHO) is about having CLI access over the network. It wasn't about telnet vs ssh, but more whether there is any CLI access or not. As much I'd prefer ssh, I'd still rather take telnet than no CLI access as all.

    2. Alan Brown Silver badge

      " idiot device developers still deploy telnet."

      Some of them allow it to be switched off/on (AVM), but it's still telnet.

  4. Stevie Silver badge

    Bah!

    Just Bah!

  5. Anonymous Coward
    Anonymous Coward

    ASUS admin-via-telnet

    Just bought an ASUS router for home (not on the list). No 'Net-facing telnet but internal admin-via-telnet, no ssh, possible. So I tried it and there I am. logged in as root. I turned it off via the web setup.

    1. Roland6 Silver badge

      Re: ASUS admin-via-telnet

      I assume you used a second Internet connection to test the absence of Net-facing telnet et al?

      The issue with the ZTE router was that the presence of Net-facing Telnet was not included in the user documentation.

      My Huawei D100 by default allows internal LAN Telnet connections, but not WAN connections and there is no facility for changing these settings. However, it does give me control over whether the webserver can/cannot be directly accessed from the Internet.

  6. Mike 16 Silver badge

    Cui Bono

    Since this is about telnet access from the WAN side, I assume it is not a cockup, but something demanded/requested by carriers. As for detecting/mitigating it, the TOS for some (many? well, at least Comcast) pretty much forbid use of any sort of monitoring on the WAN side. Because, of course, the Internet runs on Coyote Physics, where nothing bad happens until you _notice_ that you are standing on thin air.

  7. David Roberts

    Shields Up?

    Perhaps the first thing you should do with a new router is use Shields Up to check if your router has any open ports?

    I haven't used CLI on a router for a long time (used to have a Perl script to tune the ADSL) but I suspect that there is probably a lot more functionality under the hood on most routers than is exposed via the web interface. So access to the CLI (which will probably be Telnet) internally is IMHO a good thing on balance.

    Not externally!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020