1mo ago

Undocumented Commands Found In Bluetooth Chip Manufactured in China Used By a Billion Devices.

www.tarlogic.com

Tarlogic detects a hidden feature in the mass-market ESP32 chip that could infect millions of IoT devices

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. 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.

Update: The ESP32 "backdoor" that wasn't.

cybersecurity @infosec.pub

Tea @programming.dev

1mo ago

Undocumented Commands Found In Bluetooth Chip Manufactured in China Used By a Billion Devices.

www.tarlogic.com /news/backdoor-esp32-chip-infect-ot-devices/

Technology @lemmy.zip

Tea @programming.dev

1mo ago

Undocumented Commands Found In Bluetooth Chip Manufactured in China Used By a Billion Devices.

www.tarlogic.com /news/backdoor-esp32-chip-infect-ot-devices/

Show Context

193 comments

I just re-read the article and yes, you still need physical access.
The exploit is one that bypasses OS protections to writing to the firmware. In otherwords, you need to get the device to run a malicious piece of code or exploit a vulnerability in already running code that also interacts with the bluetooth stack.
The exploit, explicitly, is not one that can be carried out with a drive-by Bluetooth connection. You also need faulty software running on the device.
- "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."
  I of course don't know details but I'm basing my post on that sentence. "Backdoor may be possible via ... rogue Bluetooth connections."
  
  Looking at the article, the exploit requires you to be able to send arbitrary data to the Bluetooth device over a physical connection. This means that a properly secure application will be protected from drive by connections, but if the application has an exploit that either lets an attacker write arbitrary values to the Bluetooth controller, or more likely contains a general arbitrary code execution exploit, then you could use this to rewrite values to the chip that would let you "persist" certain changes to the Bluetooth chip that would be difficult to notice.
  I would consider this a moderate concern, as this will definitely increase your options if you're looking to be able to make an attack that targets a specific device and this gives you a few additional persistence options, but any attack would have to be designed for a particular program running connected to a Bluetooth chip.
  A more likely concern in my opinion would be the possibility of a supply chain attack, where someone compromises a Bluetooth chip that they know will be used to construct a particular part.
  I don't think that it's super likely that either of these will affect the average person, only corporations and governments where espionage is an actual threat, as if you can find a Bluetooth IOT device that you want to mess with, like a Bluetooth enabled door lock, then you're more likely to be able to find an arbitrary code execution attack which causes it to unlock immediately. Being able to spoof a different Bluetooth device isn't likely to give you that big of an advantage when you're working with a device that was already vulnerable for a different reason.
  
  thank you for the nice analysis. this should really be voted highest.
  
  Thank you for the analysis, very insightful!
  Do you reckon this is more of an oversight or bug in the BT stack, or a deliberately places backdoor as the title seems to suggest?
  
  From what I can tell from looking at it, this seems like something deliberately left in, but not for malicious reasons. The op codes referenced simply give access to lower level parts of the boards programming. ESP32's are already a user programmable board, a valid use case is to run your entire application on one if the code being run is lightweight enough to not interfere with the Bluetooth code. Either during development, or during runtime, these undocumented codes are likely used to run specific commands on the board.
  The actual issue as far as I can tell, since normally it's valid usage to rewrite the board over USB, is that ESP32 boards also offer ways to encrypt device code, and require it to be signed, and you are presumably able to mess with this in order to dump code that was expected to be securely encrypted, and overwrite code on devices that was intended to require signing. (https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/security/secure-boot-v2.html#background)
  Proving what someone was thinking when they programmed something is extremely difficult unless you can find written evidence of someone specifically saying if they did something or not, but this all seems like a legitimate minor exploit in a device that wasn't built by, or intended for, people who are working against highly resourced attackers. This is still not a concern for normal people who aren't concerned about being attacked by spies, and if a nation state wanted to hide a vulnerability in something then there are far easier paths to take than one that only works if you can steal a microcontroller so you can connect to it over USB.

193 comments