Under the Covers
Figure 23 shows the main board of the HN1200.
Figure 23: Main Board
The processor used is a Marvell Orion 88F5182. Hammer documents that the unit has 64 MB of RAM installed. The Ethernet is provided by a Marvell 88E1111 chip. Internally, it's clear that the HN1200 runs Linux. To see if I could get into the box for some more details, I started my usual poking around. First, I did a port-scan, which turned up nothing much of interest. Next, I looked deeper into the configuration menus to see I could find a way to get inside.
To accomplish this, I
simple HTTP proxy
that allowed me to change the parameters after the validation had already occurred. My first test was to embed a
Syntactically this tells the underlying shell in the HN1200 to execute the command enclosed in the back quotes before executing the rest of the command. When I used this address, I got an email error, but then the lights flashed and the box rebooted. Bingo, I had a hole. In addition, since reboot is a privileged command, this also told me that the command was executed with root privileges. This was a good start, but to get further into the box I needed to do more than just execute a single command.
What I wanted was a way to execute a whole script of commands. To do this, I could place a script on a network share, and then put a reference to the script in the email address field. However, I had a problem. As mentioned earlier, I didn't know the full path of the mounted disks and that is what I'd have to use for execution purposes. I could now execute commands on the box that would tell me the path, but I also had no way to get the output of the commands. Time to look deeper. The logging features of the HN1200 appeared to have been a dump of the system log common on Linux systems. If I could get my commands to send their output to the system log, I could then use the HN1200's logging menu to see what I needed.
To try this out, I took a guess that the "logger" command would be present on the box. logger is a command used to send arbitrary messages to the system log, and if it was present, I'd have what I needed. To check it out, I formed an "email address" like so:
As before, when I hit the "Send Test Mail" button, I got an error, but when I went to check the HN1200 log, I saw the result of the "mount" command which told me the physical location of the mounted drives. Now I was getting somewhere. With this info in-hand I wrote my script, placed it on the drive, referenced it from the email form and began to dig even deeper. In short order, I had the password file edited to give my standard user root privileges and a valid home directory.
Next, I found that a telnet daemon was present on the box, but not configured or running. To fix this, I added a telnet configuration line to the inetd server, rebooted, fired up a telnet client and presto, I was in with root privileges. Game over. Note that in order to perform these steps, I already had to have the administrator password, so this is not a security hole that just anyone could take advantage of.
Once I was in, I could debug the earlier issues I had with NFS and with sending the alert email. NFS was pretty easy to fix since I now knew the physical location of the mounted shares (accessible under /nfs/). The only hiccup was with OSX's finder. It attempts to mount NFS shares using a high port, which most NFS servers don't like. The solution is to modify the NFS configuration file on the HN1200 or to just do the mount from the OSX command-line with the proper options. Once I had made my adjustments, I found NFS worked fine.
The other problem I wanted to check out was the alert email error I had gotten during testing. I quickly found the PHP script that was sending the email and determined that the problem was occurring during the conversation with my ISP's SMTP server. Normally SMTP servers are pretty lax about accepting email from unknown sources, but with the explosion of SPAM occurring, some are tightening up. In this case, my ISP was rejecting email from the box due to the "From" address used, giving an error about a "valid sender domain." I couldn't fix this problem, so I moved on.
More poking around revealed a fairly standard set of utilities. The Linux kernel was version 2.6.12, the filesystem was ext3, Samba was being used for CIFS support, busybox was used for most utilities, and mini-httpd was the web server. One interesting non-standard feature I saw in-use was Trustees. Trustees is an advanced permission capability that evidently Hammer needed to use in order to maintain proper user access-control. With all of the GPL'ed software in-use, Hammer should be providing source code in order to comply with the terms of the GPL license, but my review of their web site found nothing. I hope that this is just an oversight that will be corrected soon.