Bad Code Results In Useless Passwords

[HeadlessZeke] was excited to try out his new AT&T wireless cable box, but was quickly dismayed by the required wireless access point that came bundled with it. Apparently in order to use the cable box, you also need to have this access point enabled. Not one to blindly put unknown devices on his network, [HeadlessZeke] did some investigating.

The wireless access point was an Arris VAP2500. At first glance, things seemed pretty good. It used WPA2 encryption with a long and seemingly random key. Some more digging revealed a host of security problems, however.

It didn’t take long for [HeadlessZeke] to find the web administration portal. Of course, it required authentication and he didn’t know the credentials. [HeadlessZeke] tried connecting to as many pages as he could, but they all required user authentication. All but one. There existed a plain text file in the root of the web server called “admin.conf”. It contained a list of usernames and hashed passwords. That was strike one for this device.

[HeadlessZeke] could have attempted to crack the passwords but he decided to go further down this rabbit hole instead. He pulled the source code out of the firmware and looked at the authentication mechanism. The system checks the username and password and then sets a cookie to let the system know the user is authenticated. It sounds fine, but upon further inspection it turned out that the data in the cookie was simply an MD5 hash of the username. This may not sound bad, but it means that all you have to do to authenticate is manually create your own cookie with the MD5 hash of any user you want to use. The system will see that cookie and assume you’ve authenticated. You don’t even have to have the password! Strike two.

Now that [HeadlessZeke] was logged into the administration site, he was able to gain access to more functions. One page actually allows the user to select a command from a drop down box and then apply a text argument to go with that command. The command is then run in the device’s shell. It turned out the text arguments were not sanitized at all. This meant that [HeadlessZeke] could append extra commands to the initial command and run any shell command he wanted. That’s strike three. Three strikes and you’re out!

[HeadlessZeke] reported these vulnerabilities to Arris and they have now been patched in the latest firmware version. Something tells us there are likely many more vulnerabilities in this device, though.

[via Reddit]

18 thoughts on “Bad Code Results In Useless Passwords

  1. “[HeadlessZeke] reported these vulnerabilities to Arris and they have now been patched in the latest firmware version. Something tells us there are likely many more vulnerabilities in this device, though.”

    Good job Zeke, keep this up and some day you’ll get a head! (That sounds dirtier than I thought.)

  2. Well, now I’m worried. Recently TWC pushed out free Arris DG1670 to their customers along with a nice bump in bandwidth. On the first day I had it, I disabled all the features on the box so that it’d act just as a modem (it’s also a wifi ap and router). After reading this article, though, I’m not so trusting of it (especially since I recently discovered that upon disabling its duties as a router, it has shown up at 192.168.100.1 instead of my default subnet).

    I’m not much of a security or networking guru, but two things in his article confused me:
    > “Every page you visit just redirects you…”
    > “let’s pull out the firmware”
    How did he get a file listing from the http service? And where did he get the firmware source code? (It looked to be a php script so maybe it was built right into the page source? I doubt it….).

    1. PHP isn’t compiled, so if it runs in the router, the corresponding php file (source) has got to be inside the filesystem. Since most firmwares are simply an executable+ compressed filesystem, and encryption is rarely used, its easy to inspect how it works.

        1. “admin” it’s a common word in passwords, folder structures and files.
          He could have guessed it or tried on it a software to detect vulnerabilities (look for, admin.txt, config.txt, config.conf, passwd, etc.)
          The firmware could be dumped from the flash memory with some tools or the manufacturer might provide firmware updates that you could try to decode it, decompile it (into assembly) and interpret it (in assembly or using several tools that identifies patterns and guess the programming language in which it was created).
          Reading the string text in the decoded firmware (non binary data) he might have found the path to the config files, one of them “admin.conf”

  3. I am a self-educated enthusiast web dev, and i find this offensive. What a complete piece of crap from someone who never learnt php, web security, and don’t know at all what is md5. This can’t be a mistake i think, too crazy.

      1. As neither, I disagree. The formally educated tend to make obvious mistakes. Autodidacts tend to make non-obvious ones that the educated have been warned against. Between the two, I would take someone that makes mistakes that can be caught. Besides, there is more to a profession than technical competency and those other things can not, by their social nature, be self-taught.

    1. There was merely no configured accounts. Many systems default to allowing remote access for initial configuration. The system still needs to have a user name for the shell however. It is just like any other computing system. Security could have been configured, it just was not.

    1. Terminating the transmission line with a dummy load my not completely eliminate sending and receiving, but should reduce range by at least an order of magnitude unless the circuit board has a junky design.

      By the way, name mismatch on the ssl cert encountered when logging in to post here.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.