Embedded computing is very much about making a computer as small as possible, yet still being able to run the core network or I/O components. Embedded devices are also about reducing costs by reducing the number of chips, such as memory and storage components.
When we do this, we also have a much smaller footprint that our host operating system can run with-in. In order to do that, we have made smaller kernels, use ramdisks to reduce write cycles to flash, slower CPUs, etc. The developers of these devices tend to focus on only core functionality, and security is forgotten about or as a last stop before being shipped as "Customer Premise Equipment". However, many of these devices are catching up to most modern computers- coming with 128Megs of RAM, 256megs – 32 gigs of flash, etc. With this in mind, the need to conserve has become greatly reduced.
Remember the 1990's?
The dream of poor security is still alive in embedded Linux distributions[BAW1] . For example, shadow passwords are not the default for many embedded Linux distributions. Busybox is a great resource; however it lacks a lot of the security features of the modern Linux distributions, as you still need to harden the system out of the box. For example, inetd.conf still has a lot of the services enabled by default. This was system-hardening 101 back in the early 2000's. By default you must login as root. I don't know how much more I can expand on how bad this is.
Oh what the heck, let me count the ways:
1) Lack of auditing
2) No user controls over system modifications
3) In this case, get root one system, your have root on them all
4) Developers choose poor passwords, and that gets moved into the prod build
5) Root passwords never get rotated
6) sudo, make me a sandwich "sudo: command not found"
So now lets talk about the way we can infiltrate these systems:
- Brute force the root login (easy stuff, with a poor password)
- Cause a buffer overflow in the web application that is used to manage the system (as root)
- Find the write community of the SNMPd, and go to town.
- Open up the device, and dump the contents of flash via JTAG (Join Test Action Group)
Now that I have your attention, stay tuned for part two of our discussion. We'll talk about what steps I took to exploit these devices, review tools such as IDA Pro, JTAG debugging, file system searching, and buffer overflows…
