Resposta da Espressif a comandos backdoor não documentados reivindicados na pilha Bluetooth ESP32.
Recentemente, alguns meios de comunicação noticiaram um press release inicialmente chamando os chips ESP32 de “backdoor”. Vale ressaltar que o press release original da equipe de pesquisa da Tarlogic foi corrigido factualmente para remover a designação “backdoor”. No entanto, nem toda a cobertura da mídia foi alterada para refletir essa mudança.
O que foi encontrado:
A funcionalidade encontrada são comandos de depuração incluídos para fins de teste. Esses comandos de depuração são parte da implementação do protocolo HCI (Host Controller Interface) da Espressif usado na tecnologia Bluetooth. Este protocolo é usado internamente em um produto para comunicação entre camadas Bluetooth.
mas afinal, O que são os comandos HCI?
A pilha de protocolos Bluetooth consiste em duas camadas primárias:
- Controlador Bluetooth (camada inferior) – Lida com operações de rádio, gerenciamento de link e comunicação Bluetooth de baixo nível. Cada chip da série ESP32 implementa um controlador por meio de uma combinação de hardware e software.
- Pilha de host Bluetooth (camada superior) – Gerencia funcionalidade Bluetooth de nível superior, como pareamento, criptografia e interações de camada de aplicativo. Isso é totalmente implementado em software. A série de chips ESP32 oferece suporte a NimBLE e Bluedroid de código aberto como pilhas de host Bluetooth.
Essas camadas se comunicam por meio de uma interface padrão chamada Host Controller Interface (HCI). A HCI define um conjunto de comandos padrão para a pilha do host Bluetooth usar. O controlador Bluetooth implementa comandos HCI padrão junto com um conjunto de comandos HCI específicos do fornecedor que são usados principalmente para inicialização de hardware personalizado no controle, bem como para fins de depuração.
Qual é o problema de segurança relatado?
O problema de segurança relatado destaca que o ESP32 contém um conjunto de comandos HCI não documentados. O problema alega que eles podem ser usados para obter acesso malicioso a dispositivos que executam Bluetooth no ESP32.
O que são esses comandos não documentados?
Os comandos HCI “não documentados” mencionados no relatório são comandos de depuração presentes no IP do controlador Bluetooth no ESP32. Esses comandos são principalmente para auxiliar a depuração (por exemplo, ler/escrever RAM, leitura de flash mapeado na memória, enviar/receber pacotes, etc.) e não desempenham nenhuma função ativa na comunicação HCI de uma pilha de host Bluetooth padrão, como NimBLE ou Bluedroid usada no ESP32.
Esses comandos de depuração, um paradigma comum para implementações do Controlador Bluetooth, auxiliam os desenvolvedores a depurar o comportamento do Controlador. Isso é particularmente útil em soluções de chip duplo.
Arquitetura Bluetooth do ESP32:
No ESP32, o Controlador e o Host são executados no mesmo MCU. O Host continua a se comunicar com o Controlador por HCI. Mas, como ambos são executados no mesmo MCU, o HCI pode ser tratado como uma camada HCI virtual, uma camada interna de comunicação.
Qualquer código que acesse essa camada HCI virtual deve ser executado primeiro no ESP32, com privilégios de execução completos.
mais quais os reais Impactos?
- para a maioria dos aplicativos ESP32, o Host e o Controlador Bluetooth fazem parte do mesmo binário de aplicativo em execução no ESP32. Não há risco de segurança porque o aplicativo já tem acesso privilegiado total à memória e aos registros, bem como capacidade de enviar/receber pacotes Bluetooth independentemente da disponibilidade desses comandos HCI.
- Esses comandos HCI não documentados não podem ser acionados por Bluetooth, sinais de rádio ou pela Internet, a menos que haja uma vulnerabilidade no próprio aplicativo ou nos protocolos de rádio. A presença de tais vulnerabilidades será um problema maior e a presença desses comandos não documentados não oferece superfície de ataque adicional.
- Somente o chip ESP32 original tem esses comandos. Os chips das séries ESP32-C, ESP32-S e ESP32-H não são afetados, pois não têm esses comandos suportados em seu controlador Bluetooth.
Operação do Modo Hospedado ESP32 (Menos Comumente Usado):
Em uma configuração alternativa não tão comumente usada, o ESP32 pode fazer o tunelamento de comandos HCI por uma interface serial (por exemplo, UART HCI) para um sistema host externo. Isso é normalmente usado em cenários onde o ESP32 atua apenas como um coprocessador de comunicação. Esse tipo de uso do ESP32 não é tão comum quanto o modo autônomo de operação.
Em tal sistema, o ESP32 confia totalmente no host. Se um invasor maliciosamente obtiver controle sobre o sistema host, ele poderá emitir esses comandos de depuração para influenciar o comportamento do ESP32. No entanto, um invasor deve primeiro comprometer o dispositivo host, tornando isso um vetor de ataque de segundo estágio em vez de uma vulnerabilidade autônoma. Ou, obtenha acesso físico ao dispositivo para enviar os comandos HCI pela interface serial.
Para essas implementações baseadas em UART-HCI, o ataque não é autoexplorável. Ainda assim, uma correção de software pode desabilitar comandos de depuração por meio de uma atualização OTA para maior segurança. haverá mais atualizações na pilha de software sobre isso em breve.
como Mitigar essa situação?
Conforme resumido acima, não há nenhuma ameaça de segurança real e conhecida que esses comandos não documentados representam. Independentemente disso, a Espressif decidiu tomar as seguintes medidas:
- A Espressif fornecerá uma correção que remove o acesso a esses comandos de depuração HCI por meio de um patch de software para versões ESP-IDF atualmente suportadas.
- A Espressif documentará todos os comandos HCI específicos do fornecedor para garantir a transparência de qual funcionalidade está disponível na camada HCI.
Para resumir, para a maioria dos aplicativos ESP32, não existe nenhum impacto do problema relatado, desde que o produto tenha os recursos de segurança de plataforma recomendados habilitados. Para um pequeno número de casos de uso serial Bluetooth HCI, a forma de mitigar o problema, será desabilitando os comandos de depuração com uma atualização sobre isso em breve.
A Espressif sempre priorizou a segurança e trabalha ativamente em melhorias contínuas de segurança de produtos. existe um reconhecido Processo de Resposta a Incidentes de Segurança de Produtos padrão com um programa de recompensa por bugs subjacente que está ativo desde 2017. Este programa oferece uma recompensa por bugs, encorajando pesquisadores a colaborar para descobrir e corrigir problemas potenciais, aumentando a segurança de todo o ecossistema. Ao mesmo tempo, é recomendável que os usuários confiem no firmware oficial e o atualizem regularmente para garantir que seus produtos recebam os patches de segurança mais recentes.
Fontes oficiais espressif:
https://www.espressif.com/en/news/Response_ESP32_Bluetooth
ESP32 Undocumented Bluetooth Commands: Clearing the Air · Developer Portal