Performing security assessments against Internet of Things (IoT) devices exposes you to a wide range of technologies, use cases, and protocols. These days, the majority of such devices have a wireless component that allows interaction with them from a distance. Often, this will be WiFi, Bluetoothtm, or RFID / NFC. These wireless devices provide greater and more convenient functionality to the operators and can simplify many inconvenient tasks of the past. Over-the-air (OTA) updates are one example of the proliferation of wireless technology in these devices, which has dramatically reduced the operation burden. In the past, updating a device would mean learning about the update, finding it online, downloading it to your computer, finding the correct cable, trying the device port 3 times until you get the orientation correct, and then launching the correct desktop application all so you can finally update the device. With OTA and wireless communication, updates are now handled with the click of a button in an app or even fully autonomously by the device. But this increases the attack surface significantly. No longer is the threat model simply “an attacker with physical access to the device;” it’s now also “an attacker within wireless range of the device” and “an attacker with network access to the device.” The OTA update methods, in particular, are especially interesting to attackers as they suggest that if the attacker can control the wireless signals, they can put their own code on the device.
Most IoT / Hardware risk-informed security assessments Praetorian performs have a wireless component, like most devices today. It is, after all, the thing that makes an IoT device an IoT device. But what happens when the device doesn’t have a wireless component? Barring supply chain attacks, the threat model is generally restricted to “an attacker with physical access to the device.” This was the situation faced by Praetorian recently on an engagement, and rather than settle on such a limited threat model, we asked ourselves the question:
“What if we could make this device wireless?”
The Threat Model
The device in question was an older model in a product line that has since moved to being wireless-enabled. The device was used in a commercial setting, and so it came with various peripherals to make the interaction process simpler for the operators. One of these peripherals was a docking station that would plug into a computer, with the physical contours of the dock guiding operators to correctly place the device in with almost no effort.
The dock communicates with the host computer using a DB-9 connector and the RS-232 protocol. When the device is plugged into the dock, an application on the host computer interprets the data. The device would communicate with the dock using a 9-pin flexible flat cable. The two different types of connectors, DB-9 and the 9-pin flexible flat cable, are crucial for this attack as the data must be sent from one connector to the other.
Crucially, during the regular operation of this device, an attacker is left alone with the dock in a fully unsupervised manner for 5 to 10 minutes. The first disassembly of the dock took only a minute or two. An attacker with minor practice could easily do this in a minute. If an attacker had a pre-made hardware implant with wireless capabilities, installing such an implant inside the dock in the time they had alone with the dock and then reassembling the dock with little external trace of evidence would be trivial. This hardware implant fundamentally alters the device’s security posture by introducing wireless capabilities into a system architected in the pre-wireless era. The original threat model and security controls were designed without consideration of RF-based attacks, creating critical exposure when wireless capabilities are forcibly added. When presented with this attack vector, the client authorized Praetorian to assess the feasibility of implementing such an implant and evaluate the exposure of unprotected data through covert RF channels.
Preliminary Probing and Shopping
The first step for such an attack is proving it is possible. To do that, we needed to see if we could extract signals and data from the dock in a non-wireless fashion.
The dock contained a PCB that passed the signals from the Device to the DB-9 serial port on the dock. Data came in from the device, passed through some passive components, and then went to the DB-9 connector. Beneath some of the passive components were tiny test points, likely used by the developers to test that the dock preserved the integrity of the data sent from the device.
Using a multimeter, Praetorian first determined which of these test points had active signal changes when plugging the device into the dock and then applied PCB Bites to the identified test points. PCB Bites are a great tool for hardware security researchers to make electrical contact with test points and pins without any soldering.
Praetorian connected these probes to a Saleae Logic Pro 8 configured to interpret RS-232 and discovered the pins where data was transferred, successfully capturing the device’s sync word and initial messages. This revealed two things: the data sent by the device was unencrypted, and the wireless hardware implant would work. By tapping the test points or the DB-9 connector’s pins, we could read all the sent data. The only thing left to do was design the wireless implant in a small enough form factor to fit inside the dock and then prove out wireless access.
We had a few design goals for the wireless implant:
- Small enough to fit inside the dock with all the necessary components (including a battery)
- Can be created during the assessment’s time frame
- Being able to connect to the implant wirelessly
Many of the more popular development boards for microcontrollers would butt up against the space Praetorian had to work with inside the dock, so we opted to use tiny form microcontrollers and boards. Due to time constraints in the assessment, we chose to use pre-assembled boards that would solve our specific needs instead of making our own. We opted to use WiFi as the wireless technology instead of Bluetooth. WiFi would be easier to get working correctly in our time frame, and it meant we could create a web server that anyone could connect to. And finally, since we were making only a proof-of-concept, we allowed ourselves to power the implant over USB-C and to continue using the PCB Bites.
With these goals, Praetorian purchased two pre-made boards from Adafruit: the Adafruit QT Py ESP32-C3 WiFi Dev Board with STEMMA QT and the Adafruit RS232 Pal. These boards were tiny, with the ESP32 microcontroller being only 22.0mm x 17.8mm x 5.7mm / 0.9″ x 0.7″ x 0.2″. They trivially fit in gaps in the dock. The RS232 Pal was necessary to translate the dock’s voltage levels (which spanned -10 V to +6 V) into something the QT Py ESP32 could understand and then broadcast.
Creation and Demonstration
Praetorian assembled the boards on a breadboard to create this proof-of-concept tool. With only a couple of components, the wiring was simple.
The board on the top is the QT Py ESP32. ESP32 microcontrollers are capable of handling both Bluetooth and 2.4 GHz WiFi fully in the microcontroller’s casing. The operational distance was limited without an external antenna, but it would be sufficient for demonstrative purposes. In this picture, the microcontroller is on the dev board’s underside.
The board on the bottom is the RS232 Pal. The Pal has two sides: high-voltage (HV) and low-voltage (LV). On the left side of the board is the high-voltage side. The high voltage side takes in data signals and voltage levels from the target device, sends them to be translated to lower voltage levels in the black integrated circuit in the center, and finally sends out the low voltage side. This process can be reversed as well, with data being sent from the low-voltage side to the high-voltage side. In this picture, the red wire on the left (HV side) is used to read data from the test points or pins on the dock. The yellow wire on the right (LV side) transmits data to the QT Py ESP32.
For the proof-of-concept, we only showed the implant’s Receive capabilities. If we wanted to show a bidirectional data flow, we would need to add two wires: one right above the yellow wire that handled data transmission to the LV side of the RS232 Pal and one above the red wire on the left to send the data to the Receive test point or pin on the dock.
With the wiring correctly hooked up, Praetorian proceeded to make a simple Arduino program that would define two serial connections: One between the QT Py ESP32 and the computer we used for development to relay the tapped data; and one from the dock to the QT Py ESP32 (by way of the RS232 Pal). Rather than immediately going to the complex scenario of hosting a web server, we wanted to prove that the core idea was sound with this specific setup. A few minutes later, we could plug the device into the dock and have all of the unencrypted data sent to the serial console on our computer.
Hardware implants come in a few varieties. Some will immediately transmit data as they get it. Others will broadcast a hidden WiFi network, store the tapped data for a short time, and allow people who know of its existence to download the data. Others require the implant to be physically retrieved to get the data. For our proof of concept, we opted to connect the implant to our WiFi network and host a web server there. The Arduino IDE we were using to program the microcontroller included simple examples of hosting a web server on an ESP32. We used this as a basis for our modifications, which included wiretapping the data and streaming it on the web page.
After a couple of hours of hacking away at it, we thought we had a working solution and went to test the device. We loaded the webpage, inserted the device into the dock, and were greeted with the following:
The series of As was part of the “sync word” used to signify that a set of data would be coming next, like a rudimentary three-way handshake in TCP. The rest of the data is the ASCII representation of the binary data being sent by the device. For example, the `[` does not represent an actual left bracket being sent by the device but instead the hexadecimal byte 0x58, which encoded various pieces of information that the device sent.
The attack was successful. We added the ability to read all of the data that was sent across the dock by the device. Further testing revealed that if we added additional wires, we could transmit data to the device or the host computer, opening up opportunities to sabotage the information being sent or reprogram the device. The vulnerability itself was not that we could add a hardware implant, but that we could add one to exploit the lack of encryption and signing on the messages being sent to and from the device we were testing. Additional vulnerabilities could be chained with this one to take complete control of the device Praetorian was testing.
We had made the device wireless.
The Real World
In a real-world scenario, an attacker would require a few things that we did not explore as part of this attack.
- Preparation and foreknowledge
- A method to extract data that did not rely upon the target’s WiFi network
- Pre-made implant that could clamp on to the electrical contacts
This attack cannot be done ad hoc during the 5-10 minutes the attacker has alone with the dock and would require studying the dock beforehand to craft the implant. However, this is not insurmountable, as at the time of this blog post, there were at least 10 such docks and devices on eBay for reasonable prices.
The extraction method would also likely change: In our proof-of-concept, we connected to our private WiFi network. An attacker would rarely have that luxury in the target environment, and even if they did, they would still need to know the exact IP to connect to. The implant would likely host its own WiFi network as an access point in a real-world scenario. This network would not advertise its SSID, and it would have a pre-determined name. An attacker within range could connect to the pre-known SSID with the correct credentials and access the statically assigned IP address. The implant could also be improved to have an antenna, increasing the range of the network. Some implants in the real-world use radios such as LoRA to send the data to receivers kilometers away.
The most difficult challenge to overcome is ensuring the implant maintains electrical contact with the dock. We used PCB Bites and gravity to ensure this in our proof-of-concept, but that is not feasible in a real-world scenario. While quickly soldering two wires to the pins may be possible with a portable soldering iron, it is a somewhat risky approach. A more likely scenario would be creating a custom PCB that could be tightly “hung” on the dock with pins that would make contact at the correct locations, relying on a friction fit.
Outro
When faced with a seemingly limited threat model of “an attacker with physical access,” we asked ourselves a simple question: “What if we could make this device wireless?” Rather than accepting the constraints of the system as designed, we demonstrated how a few tiny boards, some creative thinking, and a couple of hours of development time could fundamentally transform the attack surface of a supposedly “secure” air-gapped device.
When we presented the report to the client, they were thrilled with the attack and said it transformed their understanding of what was possible.
This kind of “what if” thinking exemplifies how Praetorian approaches security assessments. We don’t just check boxes or follow standard testing procedures – we think like real attackers, challenge assumptions, and explore creative attack paths that others might miss. In this case, a $30 microcontroller and some clever engineering revealed how a five-minute window of physical access could turn into persistent wireless vulnerability.
The next time you’re looking at your security assumptions, ask yourself: what if those constraints aren’t as fixed as they appear? What if the attack surface could be dramatically expanded with a creative approach? Better yet, let Praetorian help you answer those questions before an attacker does.
Ready to see what other creative security insights we might uncover in your systems? Contact our team at praetorian.com.
