[Ed note: Most of the headlines for this story uses the security vendor's description of this is a "backdoor", which is getting called out as deliberate clickbait and hype given the physical access needed to load malicious code --hubie]
Undocumented commands found in Bluetooth chip used by a billion devices
The ubiquitous ESP32 microchip made by Chinese manufacturer Espressif and used by over 1 billion units as of 2023 contains an undocumented "backdoor" that could be leveraged for attacks.
The undocumented commands allow spoofing of trusted devices, unauthorized data access, pivoting to other devices on the network, and potentially establishing long-term persistence.
This was discovered by Spanish researchers Miguel Tarascó Acuña and Antonio Vázquez Blanco of Tarlogic Security, who presented their findings yesterday at RootedCON in Madrid.
"Tarlogic Security has detected a backdoor in the ESP32, a microcontroller that enables WiFi and Bluetooth connection and is present in millions of mass-market IoT devices," reads a Tarlogic announcement shared with BleepingComputer.
"Exploitation of this backdoor would allow hostile actors to conduct impersonation attacks and permanently infect sensitive devices such as mobile phones, computers, smart locks or medical equipment by bypassing code audit controls."
The researchers warned that ESP32 is one of the world's most widely used chips for Wi-Fi + Bluetooth connectivity in IoT (Internet of Things) devices, so the risk of any backdoor in them is significant.
In their RootedCON presentation, the Tarlogic researchers explained that interest in Bluetooth security research has waned but not because the protocol or its implementation has become more secure.
Instead, most attacks presented last year didn't have working tools, didn't work with generic hardware, and used outdated/unmaintained tools largely incompatible with modern systems.
Tarlogic developed a new C-based USB Bluetooth driver that is hardware-independent and cross-platform, allowing direct access to the hardware without relying on OS-specific APIs.
Armed with this new tool, which enables raw access to Bluetooth traffic, Targolic discovered hidden vendor-specific commands (Opcode 0x3F) in the ESP32 Bluetooth firmware that allow low-level control over Bluetooth functions.
In total, they found 29 undocumented commands, collectively characterized as a "backdoor," that could be used for memory manipulation (read/write RAM and Flash), MAC address spoofing (device impersonation), and LMP/LLCP packet injection.
Espressif has not publicly documented these commands, so either they weren't meant to be accessible, or they were left in by mistake.
The risks arising from these commands include malicious implementations on the OEM level and supply chain attacks.
Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections.
This is especially the case if an attacker already has root access, planted malware, or pushed a malicious update on the device that opens up low-level access.
In general, though, physical access to the device's USB or UART interface would be far riskier and a more realistic attack scenario.
"In a context where you can compromise an IOT device with as ESP32 you will be able to hide an APT inside the ESP memory and perform Bluetooth (or Wi-Fi) attacks against other devices, while controlling the device over Wi-Fi/Bluetooth," explained the researchers to BleepingComputer.
"Our findings would allow to fully take control over the ESP32 chips and to gain persistence in the chip via commands that allow for RAM and Flash modification."
"Also, with persistence in the chip, it may be possible to spread to other devices because the ESP32 allows for the execution of advanced Bluetooth attacks."
BleepingComputer has contacted Espressif for a statement on the researchers' findings, but a comment wasn't immediately available.
= https://www.documentcloud.org/documents/25554812-2025-rootedcon-bluetoothtools/
= https://reg.rootedcon.com/cfp/schedule/talk/5
= https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-devices/
(Score: 2) by VLM on Tuesday March 11, @01:47PM
Popular in ALU world also. There's a lot of chips with crazy hardware onboard that would take a long time to test every transistor end-to-end but there are often shortcuts to test function blocks faster.
There's a long history here. The pentium fdiv bug IIRC boiled down to there's a 2K lookup table that accelerates division and they didn't exactly have a direct way to look at table contents, and some some numbers on the masked rom were wrong; not many, but to a first approximation "some" in 2048 divisions might be occasionally messed up on the very last step. Its an approximation algo so if the first or mid steps were messed up it would self correct but the last step of calculation can't be fixed later; it was not detected in early testing because most of the time the error is in like the last digit of the floating point result. Anyway the PR disaster encouraged everyone who makes ALUs to include test stuff on chip; if Intel had included a way to look at the values in the masked rom, there's only 2048 of them, it would have been pretty obvious if a couple were wrong.
Presumably, some chips shipped with single transistor fails in that 2K masked rom array; probably not many, but I'd assume some shipped. In the old days "CPU testing programs" actually made sense. Not sure they do now, if CPUs are tested more throughly than the past. Then again they're more complicated now. My favorite CPU from the 70s/80s was the 6809 and it could never had a FDIV bug because it didn't have on-chip floating point division hardware LOL. It did have a hardware multiplier that worked and was easy to test because it was an 8x8 it doesn't take long to enumerate all possible multiplies; much longer task to enumerate all possible double precision floating point mults LOL.