Vulnerabilidade de injeção de entradas via Bluetooth no Android, Linux, macOS e iOS

 (github.com/skysafe)
2 pontos por GN⁺ 2023-12-17 | 1 comentários | Compartilhar no WhatsApp
  • CVE-2023-45866 é uma vulnerabilidade de bypass de autenticação em stacks Bluetooth de vários sistemas operacionais que permite conectar um teclado falso e injetar entradas de teclas sem confirmação do usuário
  • Um invasor próximo pode tentar ações como instalar apps, executar comandos arbitrários e enviar mensagens usando apenas um computador Linux e um adaptador Bluetooth comum, sem equipamento especial
  • As condições de vulnerabilidade variam por plataforma: no Android, o ponto central é se o Bluetooth está ativado; no Linux/BlueZ, o estado discoverable/connectable; no iOS e macOS, se um Magic Keyboard está pareado
  • Android 11-14 é mitigado com o nível de patch de segurança de 2023-12-05, mas não há correção para Android 4.2.2-10, e a correção do BlueZ de 2020 estava desativada por padrão
  • Ações que exigem senha ou autenticação biométrica não podem ser realizadas apenas com injeção de teclas, mas dispositivos não corrigidos podem ficar expostos a ataques Bluetooth de curta distância

Injeção de teclas via Bluetooth sem autenticação

  • CVE-2023-45866 é uma vulnerabilidade que permite injeção de keystrokes via Bluetooth sem autenticação no Android, Linux, macOS e iOS
  • Em vários stacks Bluetooth, é possível um bypass de autenticação que permite ao invasor se conectar a um host discoverable sem confirmação do usuário e injetar entradas de teclas
  • Um invasor próximo pode estabelecer uma conexão Bluetooth não autenticada com um dispositivo vulnerável e realizar as seguintes ações por meio de entradas de teclas
    • Instalar apps
    • Executar comandos arbitrários
    • Enviar mensagens
  • O ataque não exige hardware especial e pode ser realizado com um computador Linux e um adaptador Bluetooth comum
  • Os detalhes completos do exploit e scripts de PoC serão divulgados entre 12 e 14 de janeiro, durante a semana da ShmooCon

Condições de ataque por plataforma

  • A vulnerabilidade funciona enganando a máquina de estados do host Bluetooth para parear com um teclado falso sem confirmação do usuário
  • O mecanismo subjacente de pareamento sem autenticação existe na especificação Bluetooth, e bugs específicos de implementação o expõem como superfície de ataque
  • Em dispositivos sem patch, as condições necessárias variam conforme o sistema operacional
    • Android: vulnerável se o Bluetooth estiver ativado
    • Linux/BlueZ: o Bluetooth precisa estar em estado discoverable/connectable
    • iOS e macOS: vulnerável se o Bluetooth estiver ativado e um Magic Keyboard estiver pareado com o celular ou computador
  • Depois que o invasor pareia com o celular ou computador alvo, ele pode injetar entradas de teclas com os privilégios da vítima
  • Ações que exigem senha ou autenticação biométrica não podem ser realizadas apenas com injeção de teclas

Uma vulnerabilidade antiga revelada após o MouseJack

  • A pesquisa MouseJack, divulgada em 2016, mirava protocolos sem fio personalizados de periféricos que não eram Bluetooth
  • Esta pesquisa começou ao analisar Bluetooth e o ecossistema Apple tendo o Apple Magic Keyboard como alvo
  • No macOS e no iOS, foi encontrada injeção de keystrokes via Bluetooth sem autenticação, e ambas as plataformas podiam ser exploradas mesmo no Lockdown Mode
  • Depois, vulnerabilidades semelhantes também foram confirmadas no Linux e no Android, parecendo mais uma falha de protocolo do que um simples bug de implementação; ao verificar a especificação Bluetooth HID, constatou-se que era ambos
  • Algumas vulnerabilidades eram mais antigas que o MouseJack, e foi possível reproduzir a injeção de keystrokes até no Android 4.2.2

Impacto e status de patch no Android

  • Os dispositivos e versões Android confirmados como vulneráveis nos testes foram os seguintes
    • Pixel 7, Android 14
    • Pixel 6, Android 13
    • Pixel 4a (5G), Android 13
    • Pixel 2, Android 11
    • Pixel 2, Android 10
    • Nexus 5, Android 6.0.1
    • BLU DASH 3.5, Android 4.2.2
  • O nível de patch de segurança de 2023-12-05 mitiga a vulnerabilidade no Android 11-14
  • Não há correção disponível para Android 4.2.2-10
  • O cronograma de divulgação foi o seguinte
    • 2023-08-05: vulnerabilidade reportada ao Google
    • 2023-12-06: divulgação pública
  • O Google afirmou que a correção do problema que afeta o Android 11-14 é fornecida aos OEMs afetados, e que todos os dispositivos Pixel atualmente suportados receberão a correção pela atualização OTA de dezembro

Impacto e patch no Linux/BlueZ

  • As versões do Ubuntu confirmadas como vulneráveis nos testes foram 18.04, 20.04, 22.04, 23.10
  • Segundo o Google, o ChromeOS não é vulnerável; embora não tenha sido testado diretamente, a configuração do BlueZ parece mitigar a vulnerabilidade
  • A vulnerabilidade no Linux foi corrigida em 2020 como CVE-2020-0556, mas essa correção estava desativada por padrão
  • O ChromeOS é o único sistema operacional baseado em Linux conhecido por ter ativado essa correção
  • O patch do BlueZ para CVE-2023-45866 ativa por padrão a correção de 2020
  • Patch relacionado do BlueZ:
  • Informações relacionadas ao Ubuntu:
  • Informações relacionadas ao Debian:
  • Informações relacionadas ao Fedora:
  • O cronograma de divulgação foi o seguinte
    • 2023-08-10: vulnerabilidade reportada à Canonical
    • 2023-09-25: vulnerabilidade reportada ao Bluetooth SIG
    • 2023-10-02: caso aberto no CERT/CC
    • 2023-12-06: divulgação pública

Impacto no macOS e iOS

  • Os dispositivos testados no macOS e confirmados como vulneráveis foram os seguintes
    • 2022 MacBook Pro, macOS 13.3.3, M2
    • 2017 MacBook Air, macOS 12.6.7, Intel
  • O Lockdown Mode do macOS não impede o ataque
  • O macOS Sonoma 14.2 corrige a vulnerabilidade
  • O cronograma de divulgação do macOS foi o seguinte
    • 2023-08-01: vulnerabilidade reportada à Apple
    • 2023-12-06: divulgação pública
  • O dispositivo testado no iOS e confirmado como vulnerável foi um iPhone SE executando iOS 16.6
  • O Lockdown Mode do iOS também não impede o ataque
  • O cronograma de divulgação do iOS foi o seguinte
    • 2023-08-04: vulnerabilidade reportada à Apple
    • 2023-12-06: divulgação pública

Leituras relacionadas

1 comentários

 
GN⁺ 2023-12-17
Comentários do Hacker News

  • Tive que pesquisar um pouco para confirmar isso, mas para ficar seguro o ideal no Android é desligar o Bluetooth quando não estiver usando. Ainda assim, ele fica vulnerável enquanto estiver em uso
    Meu Pixel recebeu a atualização de segurança de 2023-12-05 e esse problema foi corrigido, mas não sei como está a situação em aparelhos que não são Pixel
    No Linux, basta abrir /etc/bluetooth/input.conf e definir ClassicBondedOnly=true. No meu caso, não precisei adicionar nada novo, só descomentar. Na próxima versão do bluetoothd, o padrão deve passar a ser true, mas já dá para configurar manualmente agora, e depois é preciso reiniciar o serviço Bluetooth
    Não sei sobre macOS ou iOS porque não tenho esses dispositivos

    • Sempre odiei que, depois de atualizar o iOS, o Bluetooth volta a ligar sozinho. Nunca uso de fato e há muito tempo me pergunto por quê
      O Wi‑Fi também fica num estado de queijo suíço em que não dá para desligar completamente pela Central de Controle
    • No bluez v5.70-4 do Fedora 38, parece que o valor padrão é true desde 7 de dezembro
      $ rpm -q --changelog bluez | grep CVE-2023-45866 -C1
      * Thu Dec 07 2023 Peter Robinson - 5.70-4
      - Add mitigation for CVE-2023-45866
    • É uma pena que no iOS seja tão trabalhoso desligar o Bluetooth. No Android é deslizar e tocar; no iOS, são um deslize, dois toques longos e dois cliques
      Tentei manter esse hábito por um tempo depois que saí do Android, mas no fim desisti
    • Nessa página diz que isso só funciona em coisas que não exigem senha nem biometria
      Se você bloqueia o telefone ativamente quando não está usando, e se durante o uso a digitação for enviada isso vai aparecer na tela, então deixar o Bluetooth ligado não parece algo tão terrível assim
    • Queria saber se há alguma forma de verificar se o GrapheneOS corrigiu isso no branch sunfish (4a). Tenho um Pixel 4a, então estou preso ao Android 13, e preciso de Bluetooth para destrancar a porta do carro
      Se o GrapheneOS corrigiu isso, talvez finalmente seja o empurrão para migrar, mas meu telefone atual ainda funciona bem demais para justificar comprar outro

  • Fico curioso com o fato de o Windows não ser mencionado em nenhum momento. À primeira vista parece uma boa notícia, mas eu precisaria saber por que o Windows não é afetado na prática para avaliar o risco
    Por exemplo, se a pilha Bluetooth do Windows tiver algo estruturalmente equivalente ao ClassicBondedOnly=false do BlueZ, então faz sentido monitorar se esse valor está true em ambientes que se quer endurecer
    Ou talvez a pilha funcione de forma totalmente diferente e os pontos a considerar também sejam completamente outros
    Estou esperando vídeos com bastante PoC e demonstrações, mas como o Windows tem grande participação e muitos administradores de sistemas para entrar em pânico, seria bom ter informações. Até “ainda não tentamos atacar o Windows” já seria uma informação útil

    • Esse ataque específico pode não afetar o Windows
      Mas, se você criar um dispositivo Bluetooth com um Flipper Zero, no momento em que um cliente Windows se conecta ele reconhece como teclado e dá para executar qualquer comando PowerShell que você quiser. Eu mesmo só usei para abrir o YouTube e fazer um RickRoll, nunca tentei nada ilegal
      Agora deixo todo Bluetooth desligado, mas não sei como remover o bluez sem quebrar o Linux
    • Talvez seja porque no Windows o Bluetooth raramente funciona direito no dia a dia mesmo
    • Você disse que a pilha Bluetooth do Windows corresponderia ao ClassicBondedOnly=false do BlueZ, mas por acaso não quis dizer ClassicBondedOnly=true?
    • Acho que é porque ainda não tentaram isso no Windows

  • Que bom ver esse tipo de notícia agora que a indústria eliminou conexões físicas de áudio dos celulares e empurrou tudo para o sem fio. Muito bem

    • DAC USB-C é barato e fácil de encontrar
    • Essa vulnerabilidade trata de injetar entradas de teclado em teclados e mouses sem fio conectados.[1] Com a adoção do USB-C pela indústria de celulares, conexões com fio ficaram mais fáceis do que nunca
      [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...

  • Essa vulnerabilidade funciona enganando a máquina de estados do host Bluetooth para emparelhar com um teclado falso sem confirmação do usuário. O mecanismo subjacente de emparelhamento sem autenticação é definido na especificação do Bluetooth, e bugs de implementação o expõem a atacantes
    Mas por que alguém iria querer permitir emparelhamento silencioso? Gostaria de entender melhor qual era o propósito pretendido desse mecanismo problemático

    • Na especificação do Bluetooth, isso existe por causa de vários dispositivos que não são computadores. Por exemplo, ao emparelhar o primeiro controle com um PlayStation, você não precisa conectar um mouse USB só para clicar em “permitir emparelhamento”
      Não sei por que isso foi mantido assim nos dispositivos que acabaram sendo afetados
    • É só um projeto antigo de uma época mais ingênua. As especificações mais recentes não permitem isso, mas as pilhas Bluetooth deixavam o comportamento novo desativado para maximizar a compatibilidade

  • Esse problema foi corrigido no macOS 14.2 e no iOS 17.2
    https://support.apple.com/en-us/HT214036
    https://support.apple.com/en-us/HT214035

  • No Arch Linux, isso foi corrigido a partir do bluez 5.70-2 [1]
    [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

  • A parte “na época o Bluetooth parecia intimidador, então simplesmente assumi que era seguro” bate forte. Parece que esse mito nasce dessa sensação de intimidação: a ideia de que, em algum lugar acima numa pilha tecnológica complexa, há pessoas que realmente entendem tudo e que não estão sustentando com um graveto um castelo construído sobre areia

  • Duvido que isso seja prático contra celulares ou computadores, mas, se você está na posição de ter que garantir que ninguém mexa em um quiosque, sua vida ficou um pouco mais interessante

    • Uns 10 anos atrás, expus por engano na internet uma máquina Linux com VNC aberto sem senha. Em poucos minutos, alguém se conectou e tentou executar alguma coisa com entrada automática de teclado, mas era claramente um comportamento voltado para Windows
      Se conseguir implantar um único backdoor com sucesso, dali em diante já dá para trabalhar
      Em um ataque direcionado, pode até bastar enviar um pressionamento da tecla Shift a cada minuto para impedir que a tela bloqueie e, depois, ir pessoalmente até a máquina e fazer alguma coisa
    • Em computadores, também parece possível esconder um sudo ou su envenenado em algum lugar e adicioná-lo ao $PATH

  • USB também é parecido. Se você conectar um teclado a uma porta “somente carga”, ele funciona. Testei isso diretamente no Android e levei bronca por dizer que isso não é explorável na prática aqui

    • Alguém usa uma porta Android só para carregar? Ela também é muito útil para HDMI e para periféricos
      Ainda assim, não vejo isso como uma vulnerabilidade. É apenas um recurso útil. O problema aqui é que alguém pode fazer isso sem que o usuário perceba, inclusive durante operações sensíveis
      O ótimo projeto de ontem https://mitxela.com/projects/smsc também podia ser usado no celular desse jeito
    • Fico curioso sobre quais dispositivos Android têm uma porta fisicamente “somente carga”

  • A vulnerabilidade no Linux foi corrigida em 2020 (CVE-2020-0556), mas a correção permaneceu desativada por padrão. Pelo que se sabe, só o ChromeOS ativou essa correção, mesmo com Ubuntu, Debian, Fedora, Gentoo, Arch e Alpine tendo publicado avisos

    • Levei 30 segundos para verificar se isso entrou no NixOS[1]. Mais 30 segundos e vi que foi corrigido em 2023-12-08 08:23 GMT+13, um dia depois de o texto ser publicado
      Mas, se o aviso da distribuição diz que basta atualizar para corrigir[2], não entendo o que significa “a correção estava desativada por padrão”. Quer dizer que, mesmo após atualizar, ainda é preciso mudar alguma configuração manualmente? A correção no NixOS parece inverter o padrão
      Se a ideia era dizer que usuários que definiram explicitamente ClassicBondedOnly=false precisavam mudar isso, dava para escrever de forma bem mais clara
      [1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
      [2] https://ubuntu.com/security/notices/USN-4311-1