Backdoor não documentado encontrado em chip Bluetooth usado em bilhões de dispositivos
(bleepingcomputer.com)- Foi descoberto um comando Bluetooth sem documentação pública no ESP32, amplamente usado em dispositivos IoT, e o alcance potencial é grande, já que o chip estava presente em mais de 1 bilhão de dispositivos em 2023
- A Tarlogic Security revelou na RootedCON 29 vendor-specific commands no firmware Bluetooth do ESP32 e apontou a possibilidade de leitura/gravação de RAM e Flash, spoofing de endereço MAC e injeção de pacotes LMP/LLCP
- Esses comandos podem levar à personificação de dispositivos confiáveis, acesso não autorizado a dados, movimentação lateral na rede e estabelecimento de persistência de longo prazo, sendo rastreados como CVE-2025-27840
- A viabilidade de exploração remota na prática depende de como a stack Bluetooth do dispositivo processa comandos HCI, sendo mais relevante quando há firmware malicioso, atualização maliciosa ou acesso root já obtido
- A Espressif afirmou que se tratam de comandos de depuração para testes internos e que isso, por si só, não cria um risco de segurança no ESP32, mas pretende remover os comandos não documentados em uma futura atualização de software
Comandos Bluetooth não documentados que permaneceram no ESP32
- O microchip ESP32, da fabricante chinesa Espressif, inclui comandos Bluetooth que não aparecem na documentação pública
- O ESP32 é um microcontrolador que fornece conectividade Wi‑Fi e Bluetooth para dispositivos IoT e, em 2023, era usado em mais de 1 bilhão de dispositivos
- Os comandos descobertos podem ser usados para as seguintes ações
- Spoofing para se passar por um dispositivo confiável
- Acesso não autorizado a dados
- Movimentação para outros dispositivos dentro da rede
- Possível obtenção de persistência de longo prazo
Descoberta da Tarlogic e ferramenta de pesquisa
- Miguel Tarascó Acuña e Antonio Vázquez Blanco, da Tarlogic Security, da Espanha, apresentaram os resultados da pesquisa na RootedCON, em Madri
- Os pesquisadores avaliam que o interesse em pesquisa de segurança Bluetooth diminuiu, mas não porque o protocolo ou as implementações tenham se tornado mais seguros
- Muitos ataques apresentados recentemente não tinham ferramentas funcionais, não rodavam em hardware genérico ou dependiam de ferramentas antigas e sem manutenção, pouco compatíveis com sistemas modernos
- A Tarlogic desenvolveu um novo driver USB Bluetooth em C
- Independente de hardware e com funcionamento multiplataforma
- Permite acesso direto ao hardware sem depender de APIs específicas de sistema operacional
- Possibilita acesso bruto ao tráfego Bluetooth
Controle de baixo nível permitido pelos comandos
- Foi confirmada a existência de vendor-specific commands ocultos no firmware Bluetooth do ESP32
- O opcode é
0x3F - Eles permitem controlar funções Bluetooth em baixo nível
- O opcode é
- Ao todo, foram encontrados 29 comandos não documentados
- As principais capacidades estão relacionadas a
- Manipulação de memória em RAM e Flash
- Personificação de dispositivo via spoofing de endereço MAC
- Injeção de pacotes LMP/LLCP
- Como a Espressif não documentou publicamente esses comandos, é possível que eles não tenham sido planejados para acesso externo ou tenham permanecido por engano
- O problema é rastreado como CVE-2025-27840
Possibilidades de ataque e limitações realistas
- Os pesquisadores avaliam que esses comandos podem abrir caminho para implementações maliciosas em nível de OEM ou riscos de ataques à cadeia de suprimentos
- A possibilidade de exploração remota depende da forma como a stack Bluetooth do dispositivo processa comandos HCI
- A exploração remota pode se tornar mais provável nas seguintes condições
- Quando o invasor já obteve acesso root
- Quando há malware implantado
- Quando é distribuída uma atualização maliciosa que libera acesso de baixo nível
- Quando há envolvimento de firmware malicioso ou de uma conexão Bluetooth rogue
- Em geral, um cenário de ataque mais realista envolve acesso físico às interfaces USB ou UART do dispositivo
- A Tarlogic avalia que, ao comprometer um dispositivo IoT com ESP32, seria possível ocultar um APT na memória do ESP, controlar o dispositivo por Wi‑Fi/Bluetooth e lançar ataques Bluetooth ou Wi‑Fi contra outros dispositivos
- Comandos capazes de modificar RAM e Flash podem levar ao controle total do chip ESP32 e à obtenção de persistência no nível do chip
Explicação da Espressif e plano de correção
- A BleepingComputer inicialmente procurou a Espressif para comentar o caso, mas não recebeu resposta imediata
- Depois, a Espressif publicou uma posição oficial sobre a descoberta da Tarlogic
- A empresa explicou que as funções encontradas são comandos de depuração destinados a testes internos
- Esses comandos fazem parte da implementação do protocolo HCI (Host Controller Interface), usado na tecnologia Bluetooth
- O HCI é usado dentro do produto para a comunicação entre camadas Bluetooth
- A Espressif considera que, mesmo com a existência desses comandos de depuração, isso por si só não cria um risco de segurança para o chip ESP32
- Ainda assim, pretende fornecer uma correção de software para remover os comandos não documentados
Correção de termos e atualização do artigo
- Na atualização de 9 de março de 2025, o título e o corpo do texto foram revisados para refletir preocupações com o uso do termo “backdoor” para descrever os comandos não documentados
- Em 8 de março de 2025, foi adicionada a posição da Tarlogic
- Em 9 de março de 2025, foi adicionado o ID CVE
- Em 10 de março de 2025, foi adicionada a posição oficial da Espressif
1 comentários
Comentários no Hacker News
Acho que o título induz um pouco ao erro. Se entendi direito, o backdoor aqui significa que o computador pode ler e escrever na memória e nas funções de baixo nível do seu próprio adaptador USB Bluetooth
Isso não parece ser algo explorável por via sem fio. Esses comandos de depuração não documentados são comuns, e já vi recursos parecidos em adaptadores WiFi e receptores GPS. Eles só foram encontrados por engenharia reversa do firmware do chip ou do driver do fornecedor e não estavam documentados; por si só, isso não é um problema de grande impacto. Se ele permite firmware não assinado, aí continua sendo vulnerável do mesmo jeito
Se isso puder ser usado de algum lugar que não seja o host, aí é uma história completamente diferente
A Espressif tem sido quase uma exceção nesse campo em termos de abertura. Ela contribuiu até para toolchains open source em Rust para seus próprios chips e chegou a incentivar publicamente a engenharia reversa da pilha de modem que não podia divulgar por causa de código licenciado. Não gosto da ideia de que o preço por mostrar um mínimo de abertura seja publicidade ruim e nociva
“Dependendo de como a pilha Bluetooth no dispositivo processa comandos HCI, a exploração remota do backdoor pode ser possível por meio de firmware malicioso ou de uma conexão Bluetooth maliciosa.”
Resumindo: se você tem uma pilha de drivers segura e confia em todo o código local, extensões HCI do fornecedor não são um problema
Ainda assim, extensões HCI podem facilmente virar brechas de segurança. O problema é que HCI mistura entrada controlada por atacante, interfaces complexas e parsing delicado. Como a vulnerabilidade BleedingTooth mostrou alguns anos atrás, é fácil cometer erros
Ter esse tipo de recurso também facilita fazer pivot a partir de outras vulnerabilidades, mas na maioria dos sistemas isso está mais para um fruto de fácil alcance
[0] https://google.github.io/security-research/pocs/linux/bleedi...
Mesmo deixando de lado o pior cenário de API web, imagine que você roda um software semiconfiável, por precaução, dentro de uma VM tripla aninhada. Esse software apresenta uma justificativa plausível para precisar de acesso a Bluetooth, e você abre uma exceção. Você não gosta do resultado, apaga o software e reinicializa as três camadas de VM. Parece que acabou, mas o que o malware instalou no ESP enquanto tinha acesso ainda pode continuar lá
Acesso não documentado aos próprios subdispositivos pode ser algo realmente ruim, especialmente quando entra em jogo a persistência
Dá para imaginar um cenário em que o ESP32 é usado não como SoC autônomo, mas como um “modem” WiFi/Bluetooth conectado ao sistema hospedeiro por um link serial
Em teoria, um atacante poderia usar comandos não documentados para escanear, falsificar ou atacar dispositivos Bluetooth próximos. Talvez até sem obter privilégios de root no dispositivo que hospeda o ESP32
Você ficaria surpreso ao descobrir que, com privilégios de root, dá para regravar o firmware de um disco dentro do sistema operacional
O que os pesquisadores encontraram foi um recurso de hardware não documentado que permite que alguém que já tenha privilégios de execução de código obtenha acesso de baixo nível à pilha WiFi do ESP32 mais profundo do que o esperado
Chamar isso de “backdoor” é puro clickbait
Estou confuso. Quer dizer que há alguns comandos não documentados na pilha Bluetooth? Se só código que já está rodando no dispositivo pode acessá-los, parece difícil chamar isso de backdoor
Isso não soa como execução remota de código
Então existe a possibilidade de um programa em espaço de usuário, ou pior, um programa WebBLE, adicionar uma carga maliciosa persistente ao adaptador. Um beacon de rastreamento que permanece mesmo depois da troca da unidade é assustador, mas não é execução remota de código
Em teoria, deve ser possível ter acesso de baixo nível ao próprio chip de rádio Bluetooth conectado, então isso não seria até certo ponto esperado?
Dispositivos com esse tipo de interface de baixo nível são melhores. O problema pode não ser a existência disso, mas a falta de documentação
Antigamente, eu costumava desbloquear dispositivos travados e tomar posse deles em chips sem fio da Qualcomm usando comandos de leitura/escrita de memória via USB. Era leitura/escrita totalmente fora de banda, então talvez não fosse tão bom assim, mas, se isso só puder ser acessado por código já gravado no dispositivo, é até melhor
Slides em espanhol: https://www.documentcloud.org/documents/25554812-2025-rooted...
Em resumo, o que foi encontrado ao fazer engenharia reversa do firmware foram comandos HCI que fazem coisas como leitura/escrita de memória, transmissão de pacotes e configuração do endereço MAC
Isso não é exatamente um backdoor. Não sei se foram os pesquisadores que chamaram assim, ou se é porque a apresentação estava em espanhol, ou se os jornalistas estão chamando de backdoor para conseguir mais cliques
Para usar esses comandos, é preciso ter acesso arbitrário para enviar comandos HCI ao dispositivo. Ou seja, você já está controlando o dispositivo e a forma como ele opera. Não é algo explorável remotamente por meio do link sem fio. Qualquer exploit já exigiria controle total do dispositivo, e nesse ponto a capacidade de mudar o endereço MAC ou enviar pacotes não é nada surpreendente
É uma pesquisa interessante, mas empacotá-la como “backdoor” é realmente brochante. Não sei de quem é a responsabilidade pela escolha da expressão, mas imagino que seja dos jornalistas
Em uma analogia mais familiar, é como descobrir que o controlador Ethernet de um chip IoT comum consegue mudar o endereço MAC ou enviar pacotes arbitrários conforme instruções do firmware. A única diferença é que aqui é Bluetooth
https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...
É por isso que existem ferramentas para Windows como https://macaddresschanger.com/ e o
bdaddrno Linux. A maioria parece ser clone de projetos CSR, e o comando para definir o endereço também é bem conhecido. https://sources.debian.org/src/bluez/5.55-3.1%2Bdeb11u1/tool...E aqui ainda removeram até a exigência do cabo Ethernet
Dá para sair dirigindo uma van branca com “Free Candy / BLE Persistent Threats” escrito nela e, no caminho para a China, passar por detectores de metal enquanto compromete dispositivos
É sem fio, pode se espalhar como worm, envia pacotes arbitrários e consegue se passar por dispositivos arbitrários, e mesmo assim você não vê o problema?
Eu odeio esse tipo de artigo sensacionalista. Agora a Espressif provavelmente vai sentir pressão para se tornar mais fechada
Em desktops e laptops, a gente instala sem pensar duas vezes drivers blob binários opacos rodando no espaço do kernel, e nos próprios celulares controlados pela nuvem nem sequer temos acesso root; mas algumas instruções ESP32 de baixo nível não documentadas, que ainda por cima exigem que o dispositivo já esteja comprometido, viram um vetor de ameaça digno de notícia
Fico realmente me perguntando se algo não se perdeu na tradução. Antigamente eu só acharia isso legal e procuraria uma forma de transformá-lo em rádio definido por software
A pesquisa em si é boa, mas o título é ruim. Como vetor de ataque, exige acesso físico e, em quase todos os casos, é algo que já poderia ser feito de outras maneiras
Um título melhor seria algo como “Comandos não documentados encontrados em chip Bluetooth comum”
Esse título é mentira. Se fosse um backdoor em um chip Bluetooth, teria de permitir que um atacante sem fio obtivesse execução de código no chip
O artigo trata de o driver de dispositivo do aparelho conectado conseguir obter execução de código no chip, o que não viola nenhum limite de segurança
Em um ecossistema de imprensa funcional, isso exigiria uma correção publicada, e também deveria causar um grande dano à reputação do veículo que escreveu a matéria. Infelizmente, isso provavelmente não vai acontecer