Prova de Conceito das vulnerabilidades Sweyntooth Bluetooth Low Energy (BLE).
Este repositório é parte do resultado de uma pesquisa do ASSET Research Group.
O SweynTooth cobre uma família de 18 vulnerabilidades em diferentes kits de desenvolvimento de software (SDKs) de Bluetooth Low Energy (BLE) de seis grandes fornecedores de system-on-a-chip (SoC). As vulnerabilidades expõem falhas em implementações específicas de BLE SoC que permitem a um invasor dentro do alcance de rádio acionar deadlocks, crashes e buffer overflows ou contornar completamente a segurança, dependendo das circunstâncias. (Atualização) Também incluímos um script de teste para verificar dispositivos contra a variante BLE KNOB.
Você pode ver mais informações sobre as vulnerabilidades, patches disponíveis e dispositivos afetados no site de divulgação do SweynTooth do ASSET Research Group.
Fitbit, August Smart Lock, Eve Energy, CubiTag e outras coisas "Inteligentes" são afetadas.
Este PoC utiliza bibliotecas bem mantidas, como Scapy e Colorama. A criação e a dissecação de pacotes BLE são feitas por meio de camadas de protocolo Scapy personalizadas (bluetooth4LE e bluetooth.py). Há um merge em andamento para incluir nossas adições no repositório principal do Scapy.
Primeiro, certifique-se de ter Python2.7 no seu sistema e os pacotes Python listados no arquivo requirements.txt.
Se você estiver usando Ubuntu, execute o seguinte:
sudo apt-get install python2.7
sudo pip install -r requirements.txt
Em segundo lugar, o SweynTooth usa o Nordic nRF52840 Dongle para enviar/receber pacotes brutos da camada de enlace de/para o periférico vulnerável via rádio. É necessário gravar o firmware do driver na placa antes de iniciar os scripts Python 2.7.
O binário do nosso firmware está no arquivo nRF52_driver_firmware.zip. Você precisa instalar a ferramenta nrfutil para gravar o firmware na placa. Lembre-se de colocar o nRF52840 em modo DFU antes de gravar (reinicie o dongle USB enquanto ele estiver conectado ao seu PC pressionando o pequeno botão de reset).
Você pode executar os seguintes comandos para instalar as dependências do Python e gravar o firmware:
python -m pip install nrfutil pyserial pycryptodome
nrfutil dfu usb-serial -p COM_PORT -pkg nRF52_driver_firmware.zip
Os scripts funcionam no Linux ou no Windows. Você só precisa alterar o parâmetro COM_PORT para corresponder ao nome da porta do nRF52840.
Se o método de gravação anterior não funcionar, você também pode gravar o firmware usando o nRF Connect App for Desktop, que oferece uma interface prática para gravar o firmware hex (nRF52_driver_firmware.hex).
Após instalar os requisitos, você pode executar um script de exploit usando o seguinte comando:
python Telink_key_size_overflow.py COM7 A4:C1:38:D8:AD:A9
O primeiro argumento é o nome da porta serial (geralmente /dev/ttyACM0 no Linux) e o segundo é o endereço do dispositivo BLE vulnerável. Você pode usar qualquer scanner BLE ou o aplicativo nRF Connect para descobrir esse endereço.
Tomando como exemplo a vulnerabilidade Key Size Overflow, o script fornece a seguinte saída se o dispositivo vulnerável travar após a falha:
Se você deseja usar o SweynTooth por meio de uma imagem Docker para evitar instalar dependências do Python, você pode usar o script auxiliar docker.sh para construir e executar a instância Docker ou baixar a imagem Docker pré-construída (link) disponível na página de releases. O uso de docker.sh está descrito abaixo.
--------- HELP -------------
sudo ./docker run <script_name> <serial_port> <ble_target_address> - Start any sweyntooth script by its name (<script_name>)
sudo ./docker build - Build docker container
sudo ./docker build release - Build docker container and create compressed image for release
sudo ./docker shell - Start docker container shell
---------- EXAMPLE ----------
./docker.sh run extras/Microchip_and_others_non_compliant_connection.py /dev/ttyACM0 f0:f8:f2:da:09:63
Cada script de exploit corresponde a uma falha. A tabela resumo a seguir mostra a correspondência entre a vulnerabilidade e um script para explorá-la nos SoCs afetados.
De modo geral, produtos que usam os SoCs afetados empregam um watchdog para reiniciar automaticamente o BLE SoC quando ocorre uma falha; portanto, nem todos os produtos podem sofrer deadlock. Ainda assim, deve ser possível obter alguma indicação visual ou sonora do produto se ele travar e reiniciar.
A vulnerabilidade mais crítica do SweynTooth é a Zero LTK Installation, que permite a um invasor contornar completamente o procedimento mais recente de pareamento Bluetooth (secure connections) ao forçar um procedimento de configuração de criptografia com uma LTK preenchida com zeros. Para testar seu dispositivo contra essa vulnerabilidade, o dispositivo deve aceitar ou suportar secure connections como método de pareamento. Você pode executar o PoC da seguinte forma:
python Telink_zero_ltk_installation.py COM7 A4:C1:38:D8:AD:A9
Observe que os argumentos COM7 e A4:C1:38:D8:AD:A9 variam de acordo com sua configuração. Se o dispositivo for vulnerável, o PoC produz a seguinte saída:
O script de deadlock LLID limpa o campo LLID ao enviar solicitações de versão ou de pareamento de forma alternada a cada reconexão com o periférico. Isso é feito para acionar a vulnerabilidade nos SoCs vulneráveis da NXP e da Cypress. Ao executar o script contra o KW41Z vulnerável, a pilha fica em deadlock e deve enviar pacotes Link Layer fora de ordem. O script tenta detectar quando a pilha está em deadlock e gera a seguinte saída para dispositivos KW41Z vulneráveis:
Dispositivos Cypress vulneráveis geralmente desativam os anúncios (advertisements) após o ataque. Portanto, você deve ver uma mensagem de erro indicando que uma falha foi detectada. Ao testar este script contra um Fitbit Inspire vulnerável, o smartwatch trava imediatamente ou desativa temporariamente seus anúncios. Ataques intermitentes contra esse dispositivo devem causar um mau funcionamento permanente do BLE, exigindo que o usuário reinicie manualmente o Fitbit Inspire.
Embora o KNOB tenha afetado principalmente dispositivos Bluetooth Classic devido à redução do tamanho da chave para 1 byte, ainda é possível reduzir a entropia da chave de dispositivos Bluetooth Low Energy para 7 bytes (tamanho mínimo de chave em conformidade) durante o procedimento de pareamento SMP. A implicação dessa redução de entropia BLE em conformidade foi discutida em "Low Entropy Key Negotiation Attacks on Bluetooth and Bluetooth Low Energy" por Antonioli, Daniele et. al.
Disponibilizamos um script simples para verificar quais tamanhos de chave são aceitos por um dispositivo periférico BLE. Você pode executar o testador BLE KNOB da seguinte forma:
# Windows
python extras\knob_tester_ble.py COM6 a4:c1:38:d8:ad:a9
# Linux
python extras/knob_tester_ble.py /dev/ttyACM0 a4:c1:38:d8:ad:a9
Não se esqueça de alterar o COM6 e o a4:c1:38:d8:ad:a9 para outros valores de acordo com a porta serial do dongle nRF52 (geralmente /dev/ttyACM0 no Linux) e o endereço do dispositivo BLE em teste. Se a ferramenta detectar que o periférico aceita tamanhos de chave diferentes de 16 bytes, ela os listará conforme mostrado abaixo:
A pasta captures contém algumas capturas de exemplo de cada vulnerabilidade. Também adicionamos alguns casos de não conformidade detectados em alguns SoCs.
A pasta extras contém alguns scripts adicionais relacionados a não conformidades e algumas variantes do SweynTooth. Consulte a tabela de scripts extras em extras/README.md para obter mais informações.
Esta pesquisa foi parcialmente apoiada pela Keysight Technologies.
| Vulnerabilidade | CVE(s) | Fornecedor | Arquivo de script |
|---|