Injeção de teclas por Bluetooth no Android, Linux, macOS e iOS

Artigo original ↗ Discussão no Hacker News ↗

Implementações de Bluetooth em Android, Linux, macOS e iOS contêm uma vulnerabilidade de injeção de teclas (CVE-2023-45866) que permite a um invasor próximo se passar por um teclado e enviar comandos sem confirmação do usuário, em alguns casos mesmo quando o dispositivo apenas tem Bluetooth ativado. Os comentaristas analisam como diferentes pilhas ficaram expostas — desde padrões inseguros ou guiados por compatibilidade retroativa no BlueZ do Linux até o comportamento de pareamento automático “mágico” da Apple — e observam que atualizações recentes de sistema corrigem o problema em muitas plataformas, embora sistemas Apple mais antigos permaneçam sem patch. A mitigação prática vai desde desativar o Bluetooth ou reforçar a configuração (por exemplo, `ClassicBondedOnly=true` no BlueZ) até preferir periféricos com fio, enquanto permanecem dúvidas sobre a exposição do Windows e sobre o trade-off mais amplo entre conveniência sem fio e segurança.

Escopo da Vulnerabilidade

  • CVE-2023-45866 permite que dispositivos Bluetooth se passem por teclados e injetem teclas ao abusar do comportamento de pareamento “não autenticado” na especificação Bluetooth, além de bugs de implementação.
  • O ataque pode funcionar sem confirmação do usuário e, em alguns casos, sem que um teclado confiável existente esteja ativo.
  • Impacto prático: abrir terminais, instalar software (quando não há autenticação extra), discar números ou disparar ações incômodas; ataques mais graves podem exigir encadeamento com outras vulnerabilidades.

Notas Específicas por Plataforma

  • Android
    • Descrito como “um prato cheio”: vulnerável sempre que o Bluetooth está ativado, não apenas quando está detectável.
    • O boletim de segurança do Android de dezembro de 2023 inclui uma correção; alguns derivados (por exemplo, DivestOS) também retroportaram patches para versões mais antigas.
  • Linux / BlueZ
    • O problema subjacente foi corrigido em 2020, mas foi distribuído desativado por padrão (“insecure default”) por compatibilidade com dispositivos mais antigos.
    • A mitigação é a flag de configuração ClassicBondedOnly=true; algumas distros e o ChromeOS agora a habilitam por padrão.
  • macOS / iOS
    • Vulnerável quando o Bluetooth está ativado e um Magic Keyboard já foi pareado.
    • Corrigido nas versões atuais (macOS 14.2, iOS 17.2), mas não retroportado para macOS 13 / iOS 16, o que frustra usuários que dependem de dispositivos antigos “suportados”.
    • Os detalhes de como o pareamento do “Magic Keyboard” é abusado permanecem pouco claros; há dúvidas sobre se apenas o pareamento histórico já é suficiente.
  • Windows
    • Não mencionado no texto; não está claro se é afetado ou apenas não foi testado. Alguns querem detalhes arquiteturais; outros observam que existem ataques separados no estilo HID por meio de outras ferramentas.

Mitigações e Praticidade

  • Conselho comum:
    • Desativar o Bluetooth quando não for necessário (difícil ou não persistente no iOS/macOS; fácil no Android).
    • No Linux, definir explicitamente ClassicBondedOnly=true e reiniciar o Bluetooth.
  • Alguns argumentam que o risco é menor em telefones bloqueados ou em dispositivos em que instalar apps exige biometria/senha; outros observam que muitos dispositivos ficam desbloqueados ou despertam facilmente.
  • Quiosques e máquinas sem supervisão são vistos como especialmente expostos.

Segurança vs Usabilidade / Sem fio vs Com fio

  • Forte tema de “conveniência/compatibilidade retroativa vs segurança”, com críticas a padrões inseguros e comportamentos de pareamento automático.
  • Debate sobre Bluetooth em geral: visto por muitos como frágil e inseguro em comparação com conexões com fio; outros relatam experiência estável e de baixa latência com hardware moderno.
  • Vários participantes reafirmam a preferência por teclados com fio tanto por confiabilidade quanto por segurança, embora outros priorizem ergonomia e estética de configurações sem fio.