Do you remember home network-attached storage devices?

Breaking into an Old Iomega Home Media Network Hard Drive (Cloud Edition)

Back in 2010 I bought an Iomega network drive with a name that is so impossible to remember that I can only assume the marketing committee that came up with it were fired en masse shortly after launch.

A week ago I discovered it in the back of a cupboard and thought that it might be fun to hack into it, possibly to convert it into something useful.

Summary

So what is this article all about — a hard drive?

Well, that’s what it’s pinned to, and a heads up: it is going to get technical. However, you may well get something from this writeup even if you don’t have an Iomega HMNHD(CE) drive on your shelf. The overall aim of this article is three-fold:

• To give people with a little bit of an understanding of Debian Linux a “howto” that actually explains the meaning of the terms and commands used. These are sadly almost always lacking.
• To illustrate how terribly insecure network devices were ten years ago, and by extrapolation how terribly insecure our new shiny devices and cloud services almost certainly are too.
• To record a memory of a couple of fun evenings messing around with hardware and software in the way I used to five or ten years ago.

So let's get cracking. I mean, hacking[0].

The drive

Physically it’s still a gorgeous device — brushed steel, simple sleek design, with Terminator and the Matrix overtones to it. Even after a decade of being bashed about every time my wife asked me to move my computer rubbish somewhere else.

Just have a look:

It’s about the size of a flat brick.

Unfortunately, the software on it was junk. I barely used it, and the Register used to repeatedly post articles about how the latest firmware updates bricked the device. I note that ten years on Lenovo isn’t doing much better with the brand [1].

Now, this unit was the earlier one-USB port machine, with a 1TB Seagate Barracuda 7200 hard drive (SATA interface), and a small embedded PC inside using an Arm ARM926EJ-S processor that runs at 367 MHz in an Oxford Semiconductor OXU810DSE network drive chip package, unsurprisingly designed for network drives [1].

Iomega had great success with the Zip drive, back in the day when we were all still using floppy disks, but never managed to regain the former glory. It was absorbed by Lenovo, and eventually, the name was ditched. Their website is now a parked domain that forwards you on to a gambling and advertising site.

An ignoble end.

If at first you don’t succeed…

The specifications and web searches indicate that the device runs a version of Debian, but it has been locked down so all you can do it access it through the Microsoft SMB protocol and a web interface. There is also a bunch of other functionality such as FTP, Torrent, some kind of really old Facebook integration that I am sure doesn’t work anymore, and so on.

The device runs a modified version of Debian 5.0 (also called Debian Lenny) — to use a car metaphor: if Linux is the underlying engine of … well, Linux based operating systems, then Debian is like the transmission and gearbox system (and Ubuntu or Mint or some other distribution is the way the bodywork and dashboard of the car looks).

Some people are going to claim that that’s an oversimplification, but I think it works.

But back to my disk, which is like a dune buggy of the car world — the problem is you can’t ssh into it (ssh is the secure shell — a server running sshd can allow an administrator to log in over the network and start using the machine as though it is their own and it’s on their desk).

Iomega has tried to block the ignition, and you need to be able to start the engine yourself if you want to get in and mess with it.

So at first, I thought I would try to load a custom Linux operating system onto it using various techniques such as a USB stick and pressing the power and reset buttons on the device, as described by OlderZeus [3], who I think was using a later model of the drive. It didn’t work. However, the repository provided useful information about the operating system that my drive was likely to be using.

Time to use a screwdriver and actually dig into the guts. Two black screws at the front remove the front panel, and then you unplug the fan, and pull out the actual guts of the device from the other end.

The disk drive can then be pulled away from the PCB board after removing four more silver screws. It’s a SATA, so to connect it to (in my case) a Ubuntu PC required a SATA to USB connector. I took apart an external USB 3.0 hard drive I had using this video: [4] and replaced the disk inside with the one from my Iomega, but you can also just buy such a converter from Amazon.

Back it up!

The drive was attached to my computer and whirring away nicely. Time to find out more about it.

Each of the physical disks attached to your computer are called sdX, where X is a letter. There’s a simple command: lsblk

sda 8:0 0 111.8G 0 disk 
├─sda1 8:1 0 16M 0 part 
└─sda2 8:2 0 111.8G 0 part 
sdb 8:16 0 465.8G 0 disk 
├─sdb1 8:17 0 512M 0 part /boot/efi
└─sdb2 8:18 0 465.3G 0 part 
 ├─ubuntu — vg-root 253:0 0 464.3G 0 lvm /
 └─ubuntu — vg-swap_1 253:1 0 980M 0 lvm [SWAP]
sdc 8:32 0 3.7T 0 disk 
├─sdc1 8:33 0 3.3T 0 part /media/kf106/Backup
├─sdc2 8:34 0 513M 0 part 
└─sdc3 8:35 0 375.4G 0 part /media/kf106/65b54686-b3b7–4729-bed5–7e2e79b3b484
sdd 8:64 0 996.8G 0 disk
├─sdd1 8:65 0 20.0G 0 part
└─sdd2 8:66 0 9768G 0 part

Each disk is split up into things called partitions: a disk is like a filing cabinet, and the partitions are like the drawers. The disk inside the Iomega drive was a Seagate 1TB 7200, so it has to be sdd, as 996.8GB is close to 1TB.

It’s also the last disk in the list.

So, before messing about with the contents of the disk, I wanted to make a complete backup. For this you use the dd command. Which stands for “copy and convert”. Why not cc then? The C compiler already took that.

This command makes a complete copy of the drive, compresses it, and stores it on my larger backup drive:

sudo dd if=/dev/sdd | gzip -9 > /media/kf106/Backup/drive.img.gz

sudo means “run as the superuser”, or basically a god of the system, because ordinary users aren’t allowed to use potentially dangerous commands like dd, which can accidentally completely wipe your drive if you don’t know what you’re doing.

dd is the “copy the disk” command.

if=/dev/sdd means “the input file is the disk known as /dev/sdd” (in Linux everything is a file, even a disk or a USB device — it’s the underlying model of Unix).

So that part will read the disk from start to end, bit by bit and print it out.

But it doesn’t print it out, because | means “send the printout to the next command”, which is gzip, a compression program. And -9 means “compress it as much as you can”.

Finally > means send the compressed data to a file, and that file is called drive.img.gz.

See, it looks like gibberish, but when you break it down, Linux commands do actually make sense.

It took a while to run. About three hours in fact, but now I am safe in the knowledge that if I mess up the drive I can always revert back to the original drive and have it work again.

You too should back up your data before you start messing about.

Guessing and going for it

Now I guessed that the 20G partition, sdd1, was where the Debian installation was, and the 996G partition, sdd2, was where the data was stored. The drive can be accessed at a kind of “raw” bits and bytes level, but if you want to actually see the data as files and stuff, you need to “mount” it.

And if you want to remove the drive, you need to “unmount” it.

So I guess drives are like horses — you can glean a lot by admiring them from afar, but if you want to ride them, then mounting is the way to go. Note: I am allergic to horses, so I have no idea if this analogy makes sense.

The first step is to make a place to mount the partition of interest:

mkdir ~/iomega-debian

And the second step is to … mount it, go to it, and have a look:

sudo mount /dev/sdd1 ~/iomega-debian
cd iomega-debian
ls

Bingo! This is what I saw:

Now that is a classic Debian filesystem. The bin, home, etc, sbin, sys and var folders give it away. There’s a quick way to find out the version:

ls etc/*{release,version}
cd etc
cat debian_version

Debian puts a file with the version number in the etc folder, but different versions use different names, so the first line looks for files called something with release or version in the name.

This installation has the version in a file called debian_version, and the cat command prints that file out to the terminal.

And the Iomega HMNHD(CE) drive that I had returned: 5.0.3.

A quick web search revealed that this is Debian Lenny, released in 2009 [5]

You can’t change gears unless the motor is running

The problem with only having access to the file system of a Debian installation is that, as far as I am aware, you can’t go and install more software.

Now there is this command called chroot, which allows you to go to a folder containing an operating system and switch to running from that folder rather than your usual OS, but this setup is 32 bit, and my machine and Ubuntu OS is 64 bit.

So chroot won’t work — my machine is ever so sophisticated, and this is a simpler system from a simpler time. I had a look around to see if there was a way of emulating a 32 bit system, and there is: debootstrapchroot [6].

But I have a general rule, which is that if a command is really long, then it’s probably really complicated to get it to work. And looking at the instructions for debootstrapchroot, my rule was yet again proven right.

Another approach seemed more appropriate.

Use what’s there

What I wanted was to be able to ssh into the system. What if sshd, the secure shell server, was already present, but disabled?

Time to use the find command to find it.

sudo find . -name “sshd”

This starts in the folder you are in, and looks downward for any file called sshd. It didn’t find the secure shell server program.

sudo find . -name “ssh”

This found something ssh-ey: ./usr/lib/apt/methods/ssh — but it’s not looking promising.

Another approach is needed.

Telnet to the rescue

Back in the olden days, before secure shells became all the rage, there was a more basic unsecured version called telnet. If ssh is like your car having an ignition that requires a key, then telnet is like a car with a handle at the front that anyone can crank to start the engine.

Obviously that’s not safe, and that’s why no one uses telnet anymore. But I thought, why not have a look. The equivalent of sshd for telnet is in.telnetd, of course. The “in” stands for Internet.

sudo find . -name “in.telnetd”

And there it is, in ./usr/sbin/in.telnetd — these are the kinds of breakthroughs that give you a sense of elation when you’re hacking.

Now, I’m not going to pretend that I knew in advance how to enable a disabled telnet server. It took quite a bit of googling and pulling pieces together. I ended up disconnecting the disk and reassembling the Iomega about four times before I got it working.

Oh, that was a spoiler, wasn’t it?

Anyway, here is what I did (with a few dead-ends that I tried removed from the story):

First I followed [7]:

Edit /etc/inetd.conf to be the following:

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

The inetd.conf file is basically already correct, so all you have to do is delete the # sign and some other crud from the beginning of the line. This file tells the operating system what telnet server you are using and how it is to be run.

And then I followed the rest of the instructions: create an /etc/init.d/inetd script and some symbolic links to various executables, exactly as described in [7].

And I reassembled the Iomega, and it didn’t work. For two reasons —

1. I didn’t know the root password,
2. root isn’t allowed to telnet in.

Usually the latter is for a good reason, because if you restrict root (remember: the superuser who is basically god-on-the-machine) to only log in while physically next to the machine, you have a much more secure system.

But this was one of those cases where I really, really needed to be a god.

So now I’m going to show you how to do 1. and 2.

Changing god’s password

There’s a file in Debian installations called /etc/passwd, which contains … well, not exactly the password, but a hash of the password. When you enter the password, the system uses something called a hash function.

Hash functions are like one-way doors into Narnia: you can go through them, and on going through you change, but you can’t go back. So the password system doesn’t store the password, it stores the hash. And when you enter your password it’s immediately hashed, and the system checks that your hash matches the one stored. If they do you’ve logged in. If they don’t, you’re kicked off.

But if someone hacks the system, they can’t reverse-engineer your original password from the hash value stored.

There are, however, other methods. So let's look at the first line of the passwd file:

root:$1$$IqH.8BV8l9Uhl3qbv9FMq/:0:0:root:/root:/bin/bash

This site: [8] explains the format — colons are used as delimiters. So we know that this is the password line for root, the $1$ tells us that the hash function is MD5, and the correct password hashes to IqH.8BV8l9Uhl3qbv9FMq .

And this site [9] tells us that ysap7EeB9ODCrO46Psdbq is the hash of the password “guest”.

So editing the former to be the latter, gives us root login access with password “guest”.

And that’s why you don’t want people to have physical access to your actual hard drive. It’s that simple to gain root access.

(Later I ran some brute forcing software and found out that the original password was “1”, which seems like a very insecure choice on Iomega’s part for the root password).

Letting god in

Remember, root is blocked from logging in using Telnet. How is that blocking enacted?

Well, there are these configuration files, called pam files, which are part of the “pluggable authentication modules”. One of those files has a line in it that blocks root, so that line just needs to be commented out.

The pam config files are in etc/pam.d/ and the one we want is called login.

So, edit login:

sudo nano etc/pam.d/login

and comment out the following line with a #:

account required pam_access.so

Again, a reminder that this is risky, because now anyone who guesses that the root password is “guest” can log in. I made sure I was working on a local network with no internet access.

Reassembly

With all that done, all that was needed was to reassemble the Iomega drive. And it needed to be put back in its case, because there were two small golden protrusions at the bottom of the PCB board that needed to be in contact with the case for the system to actually boot up.

They are marked H8 and H9 in the picture below:

Watch out for H8 and H9

You have to be careful when sliding the drive chassis and board back in that these don’t catch on the edge of the case and get pulled off.

So, with all the screws back in, and the fan plugged in, it’s time to connect up the power and the ethernet cable.

Conclusion

And then I was in:

Root access to an Iomega HMNHD(CE)

Of course, the story doesn’t end there. There’s how I managed to get apt-get to work, and exploring the webserver folder and finding the Iomega “ET calls home” code, which now calls a gambling site instead (with the lovely name of Slotty Vegas). I wonder if they’ve noticed old network drives trying to talk to them?

But those are tales for another day if I feel like telling it and anyone is actually still interested.

Perhaps I’ll try to compile the Bitcoin source code on it one day and make it into a cool standalone node. For some definition of the word “cool”.

Update: the story continues at https://medium.com/@keir_85660/breaking-into-an-old-iomega-home-media-network-hard-drive-cloud-edition-part-ii-fd96b692379f

References

[0] Anonymous(2002), “Maximum Security” retrieved from https://www.informit.com/articles/article.aspx?p=30048

[1] The Register (2019), “ Patch now before you get your NAS kicked: Iomega storage boxes leave millions of files open to the internet“ retrieved from https://www.theregister.com/2019/07/16/iomega_nas_boxes/

[2] Oxford Semiconductor (2008), “OXU810DSE Dual Drive Network Attached Storage System Device with Encryption” retrieved from https://www.semiconductorstore.com/pdf/NewSite/Oxford/OXU810DSE_PB.pdf

[3] https://github.com/olderzeus/Iomega-HMNHDCE

[4] https://www.youtube.com/watch?v=1RQv9raiPQg&feature=youtu.be

[5] https://wiki.debian.org/DebianLenny

[6] https://wiki.ubuntu.com/DebootstrapChroot

[7] http://archive.linuxfromscratch.org/lfs-museum/2.3.1/LFS-BOOK-2.3.1-HTML/x1922.html

[8] https://www.cyberciti.biz/faq/understanding-etcpasswd-file-format/

[9] https://sourceforge.net/p/mediatomb/discussion/440751/thread/14488f68