Loading ...
Sorry, an error occurred while loading the content.

How To: Hacking the Linksys NSLU2

Expand Messages
  • kekcyara
    When I first read the review of the new
    Message 1 of 1 , Mar 6, 2006
    • 0 Attachment
      When I first read the review of the new <a
      href="http://www.fineelectronics.net/product?t=D-Link-DWL-922-Wireless-USB-Network-Router-Adapter-Kit-802-11g-54Mbps-Includes-DI-524-DWL-G122&i=43120">Linksys
      Network Storage Unit device (NSLU2)</a> I was definitely interested.
      It looked to be small, silent, inexpensive and flexible enough to
      provide backup and file storage to my network.

      My only concerns were reports that it would only work with Microsoft
      Windows and that it formatted its disks with a proprietary
      filesystem . But throwing caution to the wind, I found a deal on the
      web, ordered it and a couple of days later, it arrived in the mail.
      After I hooked up an external drive, connected to it with my web
      browser and configured it using the web interface, the NSLU2 was
      serving files on my home network in no time. Despite Linksys'
      documentation to the contrary, using it with MacOS X and Linux was
      no problem, since both operating systems support the Microsoft SMB
      file server protocol used by the box. Installation complete, right?
      Wrong. I was just getting started.

      As nice as this tiny silent unit was, I couldn't leave well-enough
      alone. I knew it had more potential since internally the little box
      ran Linux. With dual USB 2.0 ports and a 10/100 Ethernet connection,
      this little box has many possibilities. How about NFS along with
      SMB ? Or maybe a print server to go with the file storage?

      Using a USB/Serial converter I could use my X10 interface unit to do
      some simple home automation. A USB/Ethernet converter could turn the
      unit into a little router, or a USB/802.11bg converter could create
      a wireless access point. Full control of the USB ports would really
      open up new possibilities, but how to get into it?

      NOTE!Disclaimer: It goes without saying, but I'll say it anyway.
      Exploring the NSLU2 by looking at its internal file structures using
      any method that doesn't modify its code should leave your warranty
      intact. But modifying the NSLU2 in any way will void your warranty.
      TomsNetworking, Tom's Guides Publishing and I are not responsible
      for any damage that the information in this article may cause to
      your NSLU2 or any data it manages.

      So <a
      href="http://www.linksys.com/download/firmware.asp?fwid=217">download
      a copy of the current firmware</a> before you start, and don't go
      trying to get help from Linksys if you break it.

      A quick port-scan looking for open ports showed nothing of interest.
      Searching through all of the standard menus was fruitless as well.
      It was time to get creative.

      A standard technique for accessing the internals of device such as
      these is to look for back doors. Developers of these devices need
      easy visibility into the running system and often leave a way to get
      in or to run tests. Sometimes this requires special development
      hardware, but it is also common for developers to get into the
      device through the a network connection.

      The obvious place to start looking was in the web interface. I had
      noticed that all of the Administration menus were in a web
      subdirectory named Management. Since I knew that webservers can
      provide a listing of the contents of a directory depending on the
      webserver configuration, I decided to try this simple exploit by
      typing http://192.168.3.77/Management/ into my web browser. Bingo! I
      was rewarded with a complete listing of all of the files in the
      directory.

      NOTE!: This directory listing ability has been removed as of the
      V2.3R25 NSLU2 firmware

      Included in the list of jpg and html files was a little gem called
      telnet.cgi. Step one complete. A potential back door discovered.
      Execution of the script showed the following screen:
      Warning! ....

      Disregarding the warning, I pushed the "Enable Telnet" button. The
      web page refreshed and I was greeted with the same screen except the
      message indicated that Telnet was now enabled! One step closer...

      From a terminal window, I tried it out using an account I had set up
      during the device initialization:

      # telnet 192.168.1.70
      Trying 192.168.1.70...
      Connected to 192.168.1.70.
      Escape character is '^]'.
      NSLU2 login: tom
      Password:
      No directory, logging in with HOME=/
      Cannot execute /dev/null: Permission denied
      Connection closed by foreign host.

      Close but no cigar. A telnet server was running and my username and
      password were accepted, but the account had the shell set
      to /dev/null. This told me that users set up with the web interface
      were valid Linux accounts, but only second-class citizens as far as
      access. This is a common practice for users who can use some
      services, but are not allowed to have an interactive login.

      Attempting to login as root - a standard Linux account - failed
      because I didn't know the password and the obvious ones (admin,
      root, etc.) didn't work. It was time to come at the problem from a
      different angle.

      Linksys documentation claimed that a disk initialized by the NSLU2
      can only be used with the NSLU2, but I didn't believe it. A file
      system is a complicated piece of software and it wasn't likely that
      Linksys wrote a new one for this little box. Some write-ups
      indicated (and a Linksys spokesperson confirmed) that the filesystem
      was a Linux ext3 filesystem because of the partition type, but as
      far as I could tell, no one had tried mounting it.

      Being too lazy to take my NSLU2 initialized disk downstairs to my
      Mandrake Linux system, I downloaded ext2 (a subset of ext3) drivers
      for my MacOs X iBook and plugged the disk into its USB port.

      Tip!: The Mac OS X ext2 drivers I used can be downloaded from the
      ext2 for Mac OS X SourceForge project. There is also a read-only
      ext2 driver for Windows NT/2000/XP that you can try here.

      Up popped two mounted filesystems: a large filesystem with all of my
      data files on it, and a small filesystem with several configuration
      files including my favorite, passwd.

      As expected, the passwd file showed the user accounts I had created
      with a /dev/null for the shell. But there were two accounts that had
      a real shell: root and an interestingly named account -
      ourtelnetrescueuser, that looked like a back door account used for
      debugging or recovery purposes.

      root:WeeOvKUvbQ6nI:0:0:root:/root:/bin/sh
      bin:x:1:1:bin:/bin:
      lp:x:4:7:lp:/share/spool:
      mail:x:8:12:mail:/var/spool/mail:
      ftp:x:14:50:FTP User:/:
      nobody:x:99:99:Nobody:/:
      ourtelnetrescueuser:scFf7ZMXBMl4I:100:100::/home/user:/bin/sh
      guest:scEPG0VnVyqmE:501:501:::/dev/null
      admin:sclzZZfodiRXY:502:501::/home/user/admin:/dev/null
      test_user:scEPG0VnVyqmE:2000:501:::/dev/null
      test2:scEPG0VnVyqmE:2001:501:::/dev/null
      test3:sc50wKPq.zChw:2002:501:::/dev/null

      But in order to use these accounts, I would need to have their
      passwords. I started down the path of cracking the passwords before
      I came out of my stupor and realized all I had to do was edit the
      passwd file and replace the encrypted password with a known
      encrypted password from one of my other accounts! I could also just
      add a valid shell to one of my accounts, but for starters, decided
      to just put a new password in for root and leave the rest of the
      accounts alone.

      As I rebooted the device, I feared my changes would be overwritten
      or that the modified password file would be detected by a checksum
      comparison. If this occured, the NSLU2 could to refuse to mount the
      drive or insist on re-initializing it.

      But as I waited, I heard the familiar beeps from the NSLU2
      indicating everything was normal. After re-enabling Telnet, I tried
      it out:

      # telnet 192.168.1.70
      Trying 192.168.1.70...
      Connected to 192.168.1.70.
      Escape character is '^]'.
      NSLU2 login: root
      Password:
      No directory, logging in with HOME=/
      BusyBox v0.60.4 (2004.07.01-03:05+0000) Built-in shell (ash)
      Enter 'help' for a list of built-in commands.
      #

      Success! I had a command prompt. The ability to get a shell
      completely opened up the device. I could now review the software and
      hardware architecture of the box, looking for ways to extend it.
      Since this device naturally manages a hard drive, it should be
      possible to place new scripts, executables, and drivers on the box.
      Time now for the hard work to begin.
    Your message has been successfully submitted and would be delivered to recipients shortly.