Using External USB Devices and REST APIs in Custom IoTSA Plugins
The Keysight IoTSA is a multifaceted, all-in-one IoT security analysis solution. It offers protocol-level fuzzing, targeted audits against known attack vectors, and my personal favorite – firmware analysis. The firmware analyzer can take a binary firmware image, extract its contents, and scan them for common weaknesses. It will build an SBOM, look for known CVEs that affect any of the components, and even scan binaries for new vulnerabilities. I use this feature all the time in my day-to-day research. But the usefulness of the IoTSA doesn’t stop there. One of its main strengths lies in the ability to incorporate your existing workflows and tooling into it through custom plugins. Simply build a docker container that contains whatever scripts and binaries you need and write a python script and a JSON-formatted config file to allow the UI to interact with those scripts and binaries. However, this extensibility goes beyond just software tooling. It is also possible to write plugins that utilize external USB devices and the IoTSA’s own REST API to greatly streamline your IoT research efforts.
One-click Firmware Analysis
An activity that I find myself doing quite regularly in IoT research is extracting firmware directly from a flash chip on a board in order to analyze its contents. This is accomplished using an I/O board such as a Bus Pirate or a Tigard or some other type of flash reader. You connect the I/O board or reader to the appropriate pins on the chip, plug it into your computer, and use a program like flashrom or minipro to read out the contents of the chip and save it to a file. At that point, you can create a new product in the IoTSA’s firmware analysis tool and upload the file to it for analysis. It will scan the file for vulnerabilities and weaknesses as well as build an SBOM and enumerate any existing CVEs. Because I do this exact same process so often, I wanted to automate as much of it as possible, which is why I wrote a custom plugin for it. For this plugin to work, I first had to allow it to access external USB devices. All the plugins in IotSA are essentially docker containers, so allowing USB device passthrough was as simple as adding the following line to my deploy.sh script:
--device=/dev/bus/usb:/dev/bus/usb
This maps the host's raw USB bus directory into the container, giving it direct, low-level access to all USB devices. This allowed me to make a call to flashrom from within my plugin’s runner.py script and have it talk to the I/O board (in this case, a Tigard). Secondly, I needed to access the firmware analysis functionality of the IoTSA from within the plugin. This was again quite easy to accomplish through the use of its extensive REST API calls. There are two API calls that are needed to create a new product and upload a firmware image to it. The first is a POST request to /api/v1/products/ with several bits of JSON-formatted information including firmware type (which can be either Rich OS or Baremetal), manufacturer, and product type (such as “Router and Gateway”, “Wearable Device”, “Smart Appliance”, etc). I added each of these fields as variables in my plugin’s config.json file to allow for their values to be changed for each new product firmware I am extracting. This request, if successful, will return a new product ID which is used in the second API request. The second one is again a POST request, this time to /api/v1/products/[product_id]/analyze_firmware with the filename and contents of the firmware file as the value of the “file” parameter. This will upload the firmware image file, attach it to the newly created product, and immediately start extracting and analyzing its contents. Putting it all together, the bulk of my runner.py script looks like this:
You will notice I only added support for a single type of flash reader, which in this case is a Tigard, but you could expand this quite easily to support any and all types of readers. After compiling all of this into a plugin file, I installed it in the IoTSA and created a test that used my new custom audit. For an example run, I hooked up my Tigard to the SPI pins of the flash chip on an old Arris VAP2500 that I had laying around. This is what it looks like when you run the test:
As you can see, with a single click the IoTSA runs flashrom to extract the contents of the chip on the VAP2500, creates a new product in the firmware analyzer, uploads the newly extracted flash chip contents, and performs a full analysis on it. This by itself already significantly improves my workflow, but it’s only the beginning of what can be done. You could use this same method for extracting firmware via JTAG and SWD interfaces, examining UART logging output, and even integrating with logic analyzers or oscilloscopes. The possibilities truly are limitless.