Exploiting embedded APIs by dumping firmware
Picture this. You have an embedded application running on an IoT device but cannot access the source code for it. How can you exploit its API (Application Programming Interface) to gain additional control over the system when you know little to nothing about it?
The answer might be by hacking the hardware and dumping the firmware. By understanding how to dump and analyze firmware, you can identify weaknesses in the system’s security that may be exploited to gain access and control.
So let me take you on a whirlwind tour of how to hack IoT devices by tapping their hardware microchips to swipe its software and extract the API artifacts you want to observe, understand, and attack.
Back to basics: Why firmware is important
Firmware is code stored in an embedded system’s read-only memory (ROM). The software controls all the hardware components, such as networking devices and sensors, used by IoT applications.
It works similarly to other software programs: devices require commands to interact with each other and their environment, which the firmware provides. The problem is that, unlike other software programs, the code in the firmware cannot be seen by the user and thus can be difficult to access and modify.
In addition to providing commands, the firmware also contains sensitive data, such as credentials and encryption keys used to secure communication between devices on a network. It’s this kind of information that we want to be able to access when trying to gain control of an embedded system.
If you are lucky, you might be able to access the base firmware images directly from a vendor on their website. In many cases though, you still want to get the firmware from an actual device so you can gain access to the configuration data too.
So let’s figure out how to do that. For the rest of this article, we will walk through hacking the hardware of an old Hak5 Wifi Pineapple I have lying around. If you don’t know what a Pineapple is, it’s one of the industry-standard Wifi pentesting platforms used by many pentesters in the field.
Hardware Hacking Recon: Locating where the firmware resides
Device firmware typically lives in flash memory chips, which often have eight pins connecting to the board and usually connect directly to the device’s CPU or microcontroller.
They are usually pretty small.
Typically though, these chips will include a serial number on top of it that you can use to search on Google to find their datasheet.
Because of their size, it can sometimes be difficult to identify the information on the chip. One method of identification that can help is by taking your smartphone, turning on the flashlight, and using the zoomed camera lens to help identify it. By taking pictures of the chip, you can further digitally zoom in and read it.
I use a slightly different approach. I leverage a USB-based digital microscope I bought on Amazon for $50 that supports focus controls and has its own onboard LED light. It becomes almost trivial to zoom in and take pictures of all the different chips on the device.
Let me show you the results of using a digital microscope to find the flash chip on the Wifi Pineapple:
Once I have collected any and all identifying markings on the chips, I go to Google and research everything I can about it, with a particular focus on the datasheets in hopes of discovering a flash chip.
Spying on the SPI: Tapping chips to dump the firmware
Once you have identified the candidate flash chip you want to dump, it’s time to really understand how it works.
With any luck, it will be an SPI (Serial Peripheral Interface) chip. SPI is a synchronous serial protocol that allows us to communicate with the chip over a dense and reliable bus. It’s important that we understand what each pin on the chip does, and if we did our recon right, the datasheet for the chip will give us all that information.
In old parlance, the SPI chip is the slave device to a master, usually some sort of microcontroller that reads and processes the embedded firmware. We want to pay particular attention to pins that relate to master in, slave out (MISO) and master out, slave in (MOSI).
Being more inclusive these days, chip manufacturers have started to name this Data Out (DO) and Data In (DI) accordingly. Just know that MISO = DO and MOSI = DI. Got it? Good.
To dump the firmware, we have to identify the following pins:
- CS: Chip Select
- MISO: Master In Slave Out (data output)
- GND: Ground
- MOSI: Master Out Slave In (data input)
- Vcc: Voltage common collector, for powering the chip.
- SCLK: Serial Clock Input
During recon, I detected an SPI chip on the Wifi Pineapple with the serial number MX25L6406E. Searching on Google, we can find it is a 64M-BIT CMOS SERIAL FLASH from Macronix. You can find the datasheet here.
If you look at the datasheet, you can find this pinout that matches the chip holding our target firmware:
So we have what we need:
CS ----- PIN #1
MISO ----- PIN #2
GND ----- PIN #4
MOSI ----- PIN #5
SCLK ----- PIN #6
Vcc ----- PIN #8With this information in hand, we can go about tapping the chip.
Tapping the chip
There are several ways to do this. One way would be to use micro test probe clips and probe each pin individually. While this works, it can be pretty tedious and prone to failure and frustration.
An easier way is to use an appropriate SOIC (Small Outline Integrated Circuit) test clip. For a typical SPI chip, this is a SOIC8 clip. Then you need to match the pins on the clip and chip and wire it accordingly.
WARNING: Make sure your target device is turned off and unplugged. The methodology covered here is for tapping a chip passively when the device is NOT powered on.
If you are lucky enough, you may have a test clip that is already wired with a ribbon cable. If that is the case, one wire will be a different color (usually red) to denote pin 1.
Knowing which pin is “pin 1” on a chip is pretty straightforward. You are looking for a bump or dimple on one corner of the chip. This is always pin 1. You will also note this on the diagram in the datasheet.
So clamp the test clip so that pin one matches pin one on the chip.
Connecting tap to a chip reader
Now that we have clipped the chip with the SOIC8 clamp to tap it, we have to connect the other end to something that can read the chip. There are several devices you can use for this, including:
- Hydrabus
- Bus Pirate
- The Shikra
- Flipper Zero
- CH341A programmer
I have all of the above and find the most success when using the CH341A programmer. It’s a perfect balance of being able to read and write everything from EEPROMs to SPI chips.
I have friends who swear by their Hydrabus or Bus Pirate. YMMV. But when it comes to consistency and success, I have had far more success with the CH341A. In fact, I tried using my Hydrabus and my Flipper Zero against the Wifi Pineapple several times. All were inconsistent… failing more times than succeeding. But my CH341A succeeded every single time.
You can buy one for yourself on Amazon for anywhere between $10 and $20.
The CH3421A usually comes with a breakout board that has an 8-pin ribbon connector to 8-pin programmer converter, which allows it to plug the SOIC8 test clip right into it, and then right into the programmer.
TIP: On most CH341A programmer boards, a picture will be printed on it showing which slots are for 25XX chips vs. 24XX. When reading SPI chips, you want to have the breakout board pins closest to the USB dongle in the 25XX slots. Pin 1 should be on the left side (closest to the chip locking handle) in the middle of all the slots. It will look something like this:
Once the SOIC8 test clip is connected to the CH341A you can plug the programmer into a USB port on your computer. Once connected, you will see indicator LEDs light up on the CH341A; you might even see LEDs on the target device light up as you power up the SPI chip.
Now it’s time to dump the firmware with some open-source software called flashrom.
Dumping the firmware
OK, so you tapped the flash. Clipped the chip. Prayed to your favorite d13ty. Time for all this hardware hacking to pay off.
To extract the firmware ROM you need software that can interface with the programmer and send the proper instructions to the chip to read it. I use a tool called flashrom for this.
The first thing we want to do is verify we tapped the chip correctly. The tool includes an exhaustive list of chips that it can detect and read. So if you simply tell flashrom that you want to use the CH341A programmer, it will try to detect any chip that it can see. The command looks like this:
$ flashrom -p ch341a_spi 
As you can see, it has detected that the chip may be one of several chips. During our hardware recon we determined this was an MX25L6406E flash chip. So the option for “MX25L6406E/MX25L6408E” would be the closest match. We can use the -c option to tell flashrom which chip we want to detect:
$ flashrom -p ch341a_spi -c "MX25L6406E/MX25L6408E"
All good. So now we are ready to do a read using the -r option:
$ flashrom -p ch341a_spi -c "MX25L6406E/MX25L6408E" -r pineapple.rom
It is always a good idea to read the chip twice. This way, you can do an MD5 checksum and ensure the ROM images match, giving you confidence in the dump.
Looks good. Our MD5 checksums match, and we have successfully dumped the firmware from the hardware into a binary file we can work with.
Time to get down and dirty with the bits and bytes!
Analyzing and extracting the firmware
Now that we have the ROM in a binary format we can use tools to extract the bits we care about. The first thing we want to do is understand how the firmware is laid out. A good tool for this is binwalk, which is designed for analyzing, reverse engineering, and extracting firmware images.
To get started, we want to see how binwalk sees the ROM:
$ binwalk pineapple.rom
We can immediately see some interesting things about the firmware:
- It uses the U-Boot 1.1.4 boot loader
- It uses the squashfs filesystem
- It uses a MIPS Linux kernel
This is all great news. It means it should be relatively trivial to extract the firmware. And binwalk can do that for us too:
$ binwalk -eM pineapple.rom
We immediately see binwalk start recursively extracting everything it can. All of it is stored in _pineapple.rom.extracted folder (and deeper).
If we enter that folder and run tree on it, we can see there are 101 directories and 1323 files.
Finding and auditing our API artifacts for vulnerabilities
At this point, we can potentially have a lot of files and directories to wade through. If you scroll through the output of tree though, it will give you a good indication of the structure of the firmware.
In my case for the Wifi Pineapple, I can quickly see the root filesystem at _pineapple.rom.extracted/squashfs-root and can find all the web app and API code at _pineapple.rom.extracted/squashfs-root/www/pineapple.
Of course, your device’s layout will be different. But you get the idea.
At this point, I can detect the Wifi Pineapple web interface is mainly written in PHP. Let’s do a rough code audit with graudit and look for interesting areas in the code that we might want to analyze further.
$ graudit -d PHP -L .
Lots of dangerous functions to look at. Sources and sinks, oh my!
If this sort of code analysis seems new to you, I highly recommend you read my article on tracing exploitability through code reviews and taint analysis.
At this point, you have the API source offline and are in a position to analyze it for potential vulnerabilities.
For extra credit, you can google for how to use the MIPS system emulator with QEMU. It’s possible to chroot this extracted firmware and emulate your IoT device allowing you to work offline to test your proof-of-concept exploits in an emulated environment against this target before launching it against the actual hardware. But that’s beyond this article.
Conclusion
Hopefully, you now have a strong understanding of the steps needed to recon embedded hardware and tap its flash chip to dump its firmware. You should also have an understanding of how to extract the firmware from the binary ROM image and analyze it for possible vulnerabilities in the apps and APIs.
This is just a basic overview but should give you enough knowledge to go forth and start exploring embedded systems and exploiting any security flaws you find in the APIs.
Happy hacking!
BTW, if you like this sort of thing, make sure you grab my free ebook on The Ultimate Guide of API Hacking Resources. It includes tons of online resources that can help you during your API hacking journey.
The post Exploiting embedded APIs by dumping firmware appeared first on Dana Epp's Blog.
*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/exploiting-embedded-apis-by-dumping-firmware
