The Mouse Trap: Micky Mouse Hacks: Password Cracking is A Waste of Energy

Get Disney On `Em

In the past year or so I've noticed a growing number of people stumbling on the same issues when getting into embedded systems design and hacking. It's odd how very few blogs are focusing on solutions to these very common problems. So, when I have a chance, I'm going to drop some tips and tricks here and there to help people out.

I'd like to pretend that these are difficult tricks, and my ego is my cross to bear ;-), but the reality is these are simple ways of dealing with annoying hindrances in performing viable engagements with clients. There is no reason for someone to spend money paying for an engineer or auditor to perform work that can be sidestepped in less than a minute. So, the solutions I'll present in the "Mickey Mouse Hacks" blogs will serve to illuminate quick-and-dirty ways to minimize the time it takes to get to real work.

It's easy to get distracted by shiny things. Don't.

But, like I said, these solutions are largely easy breezy, and to anyone that spends more time engineering than hacking, should already be in your general tool belt. It seems that, from the forum posts, and blog posts I'm seeing asking the same questions over and over, that people do indeed have these tools, they just forget about them as they aren't often used by adversarial researchers.

Consoles, TTYs, and JTAG, Oh my!

Just like the cheesy Disney songs we hear people relentlessly singing in public (yes, Dads, I can tell that's a Frozen tune you're trying not to hum) embedded systems are pretty consistent. In other words, whether engineers intend to or not, they all pretty much sound the same. I know that's hard for some of us to admit, but when boxes are developed with almost the exact same components, competing for the exact same market, at very similar price points, of course the end products look bizarrely similar!

"But, Don! What about intellectual property!?"

You're hilarious!

This is purely a matter of Darwinism. Systems designed for the same environment eventually collapse into the same model. Period. As a result, they usually have the same technologies: Busybox, ARM, Ethernet, bla bla bla. And what's the number one way to visually assess what is going on within an embedded system? A serial console!

Generally, there are three primary goals for a reverse engineer: serial consoles, remote TTY sessions (telnet, ssh, etc), and JTAG; not necessarily in this order.

The easiest target is always the serial console, followed by JTAG. Serial console ports are often TTL pins, and in most modern systems you can at least find a header already attached to the Printed Circuit Board (PCB) you're evaluating. Even if you can't find one, chances are you can discover one quickly by looking for four pins and evaluating those pins with a multimeter. The Voltage levels will dictate whether it is likely to be a standard console.

Alternatively, one can simply obtain the datasheet for the chip being used, and identify which pins are likely to be the UART, then use a multimeter, and maybe some hypodermic needles to tap vias, to identify whether a port has been found.

Regardless of the method, this is usually a small amount of effort at the beginning of any embedded engagement.

However, there is one big restriction. Serial consoles aren't great for long term work. Typically, when assessing an embedded system, the work will primarily be done on a separate box. For most engineers, this means that remotely accessing the target box is highly desirable. But, it isn't enough to simply set up an instance of netcat, or another tool, because engineers typically want the console characteristics that come with Telnet, SSH, and similar protocols. Terminal capabilities were designed for a reason.

As a result, people as of late love to pull out Ye Old John The Ripper and crack that read-only password file. Boring!

JTR In Modern Embedded Systems is This Useful

Use the Serial Console Efficiently

Since we know a serial console is almost always accessible, and we can almost always get shell access with it, we don't need to crack any passwords. Why? Two reasons.

First, if you have console access and JTAG ability, you should never need console login credentials in the first place. You should always be able to interrupt a booting kernel and change RAM contents to ensure that the kernel boots into a mode (such as single user mode) that allows you to manipulate credentials, or boot into a mode where a console is enabled.

This means that we should always at least have writable root access to the serial console, which brings us to point number two: you should never need to crack a password to log in remotely if you have a local shell.

Bro, I'm seriously.

There is an easy reason for this, and it's called the modern Linux kernel. Modern kernels are capable of union (or bind) mounts. This namespace capability allows the kernel to mount files and directories on top of other files and directories. Not familiar with namespaces, unions, or bind mounts? They're actually a feature of the Plan 9 Operating System that was integrated into Linux, along with procfs, and some other excellent Plan 9 concepts.

Point being, applications ran on the Linux system will use whatever file is at the name /etc/passwd. Remember, in namespace environments, this file system path is only a token. It doesn't necessarily reference an exact file, only the concept of a file. Because of this, you can abuse the namespace capabilities of the Linux kernel to place whatever file you want on top of this name, even in a read-only environment!

Read-Only Is For Suckers

This means that if your system performs a cryptographic check on the contents of root '/' or '/etc', and mounts the NVRAM partition read-only, you still win easily with one command:

`mount -o bind` wins every time!

Guess what? You just saved yourself a ton of time and energy cracking a password that doesn't matter. The other benefit? You can now add and remove users at will, and re-add the state to the system on the next boot with a single command.

Now, you can log in remotely with no effort at all because the telnetd application doesn't maintain a persistent file descriptor on the original '/etc/passwd' file. Instead, it will only open the file when it needs it, after you have applied the namespace adjustment. This means that telnetd, sshd, or any other system that deals with user credentials will interpret the data you want it to instead of the data the system engineer wants it to.

Aaaand, we're done.

Some people might complain at this point that this trick must be applied at every reboot, and that because it must be performed every time, it is "easier" to simply crack the password.

Yes and no. Yes, it would be nice to have the password. But, the amount of electricity it requires to crack a password in a reasonable time that isn't simply "root", "12345", or something else guessable, is not worth it. Since any decent engineer will always have at least minicom hooked up to a serial console, you can simply develop a minicom script that will automate the injection of commands when certain "phrases" are seen. This can allow minicom to detect a reboot and wait for an appropriate time to send the given commands.

Since the trick here is one single command that needs repeating, the mount command, there really isn't a lot of overhead. I'd much rather do this than bother with the energy costs of using a GPU cluster, a fast server, or - God forbid - a cloud based password cracking utility.