In my last post (All your microcells are belong to us) I showed some ways to bypass the security mechanisms, such as anti-tamper, dual SoC and integrated hardware security that exist in the AT&T Microcell, and demonstrated the ability to bypass all of them to get access to the Femtocell’s file system and crack the root password, which ended up being incredibly simple. This goes to show that even with a smart security design, weaknesses in the implementation (in this case, most likely inserted by the ODM Original Design Manufacturer) made it relatively easy to get critical information about how the device works that an attacker can use to get access.
We are most of the way there- but we still need to find a way to get a shell to execute commands on the Femtocell.
Getting a shell
First let’s see if there is anything interesting accessible from U-Boot that we can modify to get shell access. Some ideas include using u-boot’s memory modify to update the firmware, such as disabling the IPTables firewall, updating the root password, etc. That all seems to have a great chance of potentially bricking the Microcell. Maybe there’s something else… U-boot has to have some level of communication with the Linux operating system that it starts. This is facilitated through “bootargs”, which are passed directly to the operating system. We should be able to pass Linux a command via U-Boot to bind a shell to the console…
It really is this simple…
If U-Boot uses the bootargs environment variable to pass commands directly to Linux, how about just asking Linux to bind a shell to the serial console on boot? Note that I’m adding the “init=/bin/sh” to the addmisc variable, which gets concatenated to bootargs during the boot process. For some reason (I suspect bootargs is hard-coded), this variable has better persistence between boots than changing bootargs directly.
— Modify the environment variables
- setenv addmisc $(addmisc) init=/bin/sh
— Boot the femto
- bootm BFC40000
It works like a champ and Linux binds a shell to the console, allowing us to use our credentials from the previous post and login. But there is a second, much more interesting way to get root and shell…
Backdoor = 0?
What is the environment variable “backdoor = 0”? This is where having access to the filesystem that we dumped over serial in the previous blog post really helps. Let’s search the microcell’s file system for any references to backdoor…
Yet another example where searching for “backdoor” at the beginning would have saved a lot of time analyzing the firmware image. Let’s give it a try. From within u-boot, change the environment variable from backdoor=0 to backdoor=1 and then boot the operating system. A basic disassembly of the “wizard” binary with references to Backdoor above reveals that we are looking at the same backdoor mechanism that was discovered by the fail0verflow team last year, a very simple process with a basic command set (shown above) bound to 192.168.157.185 and listening on UDP port 14677 for commands.
Hands down, the most interesting function in wizard is “BackdoorPacketCmdLine_req”. A carefully crafted script allows you to execute ANY linux command on the femtocell with root level access. Let’s start by asking the femtocell to send us /etc/passwd =)
Success!!! Next step- enable telnet via the command line backdoor and try out our credentials…
Here is what’s scary. Until late 2012, the wizard’s Backdoor feature appears to have been enabled on all AT&T microcells and bound to the WAN port. This means that any microcells set up with AT&T’s recommended configuration of the Microcell being connected directly to the home internet connection modem (and therefore accessible from the Internet rather than behind a firewall/AP router) would have been vulnerable to an arbitrary command injection that would run at root level on the femtocell. An attacker could have taken advantage of this vulnerability to create a massive bot-net of AT&T microcells, push out a malicious firmware update, or brick the microcells.
Next blog- the Picochip SoC