The "Pull-out game" of a medical IoT device. Firmware Extraction to a Root shell!

Sometimes the best hardware hacking targets come from the most unexpected of places. In my case I was looking to buy a first aid kit for my lab and was going to use my HSA (Health Savings Account) funds. For people outside of the U.S., HSA is a savings account that lets you set aside money on a pre-tax basis to pay for "qualified medical expenses", or basically just allocate a set amount of your paycheck, before taxes, into an account that you can use for stuff that insurance won't cover (your deductible, copay, coinsurance, and qualified medical expenses (Eligible health products) . 

What I stumbled upon when browsing through a HSA eligible products marketplace/store was a Wi-Fi connected male fertility test kit.
 

The moment I set eyes on this product, I immediately added to cart with the intention to tear it down and do some hardware/embedded reverse engineering:



Flash extraction and my problems with the Bus Pirate.

First part that drew my attention was the Macronix MX25L12833F Serial Flash and instinctually I grabbed my Bus Pirate v3.6

So things didn't go as planned (expected with any HWRE), I kept finding that there are a lot of issues with flashrom and the Bus Pirate (Open GitHub Issue). Despite getting the "Reading flash..." message in the terminal, the process just hanged. I didn't want to deal with the effort of configuring my Bus Pirate, so I opted to use my Shikra, a FT2232H/FT232H based hardware hacking tool (GitHub and usage instructions) (Flashrom FT2232_SPI page). 


Reading with the Shikra, this process took approximately about 5 seconds. While exploring the binary with Ghidra, I also soldered on some wires for access to the UART. Conveniently I can use the Shikra also for UART! 

Gotta get root now!

So, at this point I have a firmware image, and now UART access... do I have root? No, not yet. At this point I played around with U-Boot and set the bootargs to get a root shell, this did not work and I booted into a "nobody" shell, and the passwd/shadow files cannot be read. I'm not exactly a linux/bash expert, and so at the time I thought it was strange that the passwd/shadow files pointed to a /etc path in a JFFS2 filesystem. This turned out to be a crucial detail when I used binwalk later...

The next method I chose to see if I could get the password, was to analyze the firmware image, and this is where binwalk came in handy big time! Of interest was that JFFS2 filesystem, I took a lucky guess and mounted the data from the first JFFS2 partition.



Of interest to me was the JFFS2 filesystem, because I noticed earlier that the passwd and shadow files pointed to a /etc path in a "JFFS2" partition. So after using binwalk to extract the contents of the flash dump, I followed this guide on mounting the JFFS2 filesystem. Some of the modprobe commands don't work, but I still managed to mount the file system anyway. From the mounted partition I then copied the passwd and shadow files and proceeded to use John The Ripper to crack this MD5-crypt hashed password.

Umm... did I use the tool wrong? 



Wait what? It's blank?! So I attempted to login as root, but entering a blank password didn't work... so I thought that maybe I wasn't using the tool correctly. I then proceeded to just copy and paste the hash as the password, and this for some reason worked?!!!


I changed the password promptly after getting root, and I noticed that the hash changed... Weird. Okay, so I then proceeded to change the hash, using vim to edit the shadow file, back to the original and now it lets me enter a blank password. I don't know if this is the result of some misconfiguration, or an security by obscurity method. 

Summary:

In my quick write up of extracting a firmware image to getting a root shell, I learned that I can't rely on my Bus Pirate, and that the FT2232H/FT232H chips are quite well supported and very fast! I'm still scratching my head over why the password hashing seems to be "broken"? 

Comments