Vulnerabilidad de inyección de entradas por Bluetooth en Android, Linux, macOS e iOS

 (github.com/skysafe)
2 puntos por GN⁺ 2023-12-17 | 1 comentarios | Compartir por WhatsApp
  • CVE-2023-45866 es una vulnerabilidad de omisión de autenticación en los stacks Bluetooth de varios sistemas operativos que permite conectar un teclado falso e inyectar pulsaciones sin confirmación del usuario
  • Un atacante cercano puede intentar acciones como instalar apps, ejecutar comandos arbitrarios y enviar mensajes usando solo una computadora Linux y un adaptador Bluetooth común, sin equipo especial
  • Las condiciones de vulnerabilidad varían según la plataforma: en Android lo clave es que Bluetooth esté activado; en Linux/BlueZ, que esté en estado discoverable/connectable; y en iOS y macOS, que un Magic Keyboard esté emparejado
  • Android 11-14 se mitiga con el nivel de parche de seguridad 2023-12-05, pero Android 4.2.2-10 no tiene corrección, y en BlueZ una corrección de 2020 estaba desactivada por defecto
  • Las acciones que requieren contraseña o autenticación biométrica no pueden completarse solo con inyección de teclas, pero los dispositivos sin parche siguen expuestos a ataques Bluetooth de proximidad

Inyección de entradas Bluetooth sin autenticación

  • CVE-2023-45866 es una vulnerabilidad que permite inyección de pulsaciones Bluetooth sin autenticación en Android, Linux, macOS e iOS
  • En varios stacks Bluetooth es posible una omisión de autenticación que permite a un atacante conectarse a un host discoverable e inyectar entradas sin confirmación del usuario
  • Un atacante cercano puede establecer una conexión Bluetooth no autenticada con un dispositivo vulnerable y realizar las siguientes acciones mediante pulsaciones de teclas
    • Instalar apps
    • Ejecutar comandos arbitrarios
    • Enviar mensajes
  • El ataque no requiere hardware especial y puede realizarse con una computadora Linux y un adaptador Bluetooth común
  • Los detalles completos del exploit y el script PoC se publicarán durante la semana de ShmooCon, del 12 al 14 de enero

Condiciones de ataque por plataforma

  • La vulnerabilidad funciona engañando a la máquina de estados del host Bluetooth para que empareje un teclado falso sin confirmación del usuario
  • El mecanismo subyacente de emparejamiento sin autenticación existe en la especificación Bluetooth, y errores de implementación lo exponen como superficie de ataque
  • En dispositivos sin parche, las condiciones necesarias varían según el sistema operativo
    • Android: es vulnerable si Bluetooth está activado
    • Linux/BlueZ: Bluetooth debe estar en estado discoverable/connectable
    • iOS y macOS: es vulnerable si Bluetooth está activado y un Magic Keyboard está emparejado con el teléfono o la computadora
  • Una vez que el atacante se empareja con el teléfono o la computadora objetivo, puede inyectar pulsaciones con los privilegios de la víctima
  • Las acciones que requieren contraseña o autenticación biométrica no pueden realizarse solo con inyección de teclas

Una vulnerabilidad antigua revelada tras MouseJack

  • La investigación de MouseJack, publicada en 2016, se enfocó en protocolos inalámbricos propietarios de periféricos, no en Bluetooth
  • Esta investigación comenzó al analizar Bluetooth y el entorno de Apple tomando como objetivo el Apple Magic Keyboard
  • En macOS e iOS se descubrió inyección de pulsaciones Bluetooth sin autenticación, y en ambas plataformas podía explotarse incluso en Lockdown Mode
  • Después, al confirmarse vulnerabilidades similares en Linux y Android, parecía más una falla del protocolo que un simple bug de implementación; la revisión de la especificación Bluetooth HID mostró que eran ambas cosas
  • Algunas vulnerabilidades son más antiguas que MouseJack, y fue posible reproducir la inyección de pulsaciones hasta Android 4.2.2

Impacto en Android y estado de los parches

  • Los siguientes dispositivos y versiones de Android se confirmaron como vulnerables en las pruebas
    • 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
  • El nivel de parche de seguridad 2023-12-05 mitiga la vulnerabilidad en Android 11-14
  • Android 4.2.2-10 no tiene una corrección disponible
  • El calendario de divulgación es el siguiente
    • 2023-08-05: vulnerabilidad reportada a Google
    • 2023-12-06: divulgación pública
  • Google indicó que la corrección del problema que afecta a Android 11-14 se entrega a los OEM afectados, y que todos los dispositivos Pixel actualmente soportados recibirán la corrección en la actualización OTA de diciembre

Impacto en Linux/BlueZ y parches

  • Las versiones de Ubuntu confirmadas como vulnerables en las pruebas son 18.04, 20.04, 22.04 y 23.10
  • Según Google, ChromeOS no es vulnerable y, aunque no se probó directamente, la configuración de BlueZ parece mitigar la vulnerabilidad
  • La vulnerabilidad en Linux fue corregida en 2020 como CVE-2020-0556, pero esa corrección estaba desactivada por defecto
  • Se sabe que ChromeOS es el único sistema operativo basado en Linux que tenía esta corrección activada
  • El parche de BlueZ para CVE-2023-45866 activa por defecto la corrección de 2020
  • Parches relacionados de BlueZ:
  • Información relacionada con Ubuntu:
  • Información relacionada con Debian:
  • Información relacionada con Fedora:
  • El calendario de divulgación es el siguiente
    • 2023-08-10: vulnerabilidad reportada a Canonical
    • 2023-09-25: vulnerabilidad reportada al Bluetooth SIG
    • 2023-10-02: caso abierto con CERT/CC
    • 2023-12-06: divulgación pública

Impacto en macOS e iOS

  • Los siguientes dispositivos se probaron en macOS y se confirmaron como vulnerables
    • 2022 MacBook Pro, macOS 13.3.3, M2
    • 2017 MacBook Air, macOS 12.6.7, Intel
  • Lockdown Mode en macOS no bloquea el ataque
  • macOS Sonoma 14.2 corrige la vulnerabilidad
  • El calendario de divulgación para macOS es el siguiente
    • 2023-08-01: vulnerabilidad reportada a Apple
    • 2023-12-06: divulgación pública
  • El dispositivo confirmado como vulnerable en iOS durante las pruebas fue un iPhone SE con iOS 16.6
  • Lockdown Mode en iOS tampoco bloquea el ataque
  • El calendario de divulgación para iOS es el siguiente
    • 2023-08-04: vulnerabilidad reportada a Apple
    • 2023-12-06: divulgación pública

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-17
Opiniones en Hacker News

  • Tuve que investigar un poco para confirmar esto, pero para estar a salvo, en Android conviene apagar el Bluetooth cuando no se use. Aunque mientras lo estés usando, sigue siendo vulnerable
    Mi Pixel recibió la actualización de seguridad del 2023-12-05 y este problema quedó corregido, pero no estoy seguro sobre dispositivos que no sean Pixel
    En Linux, basta con abrir /etc/bluetooth/input.conf y configurar ClassicBondedOnly=true. En mi caso no tuve que agregarlo, solo descomentar la línea. En la próxima versión de bluetoothd el valor predeterminado será true, pero puedes configurarlo manualmente ahora, y después debes reiniciar el servicio de Bluetooth
    Sobre macOS o iOS no sé, porque no tengo esos dispositivos

    • Siempre me molestó que después de una actualización de iOS el Bluetooth vuelva a activarse. Durante mucho tiempo me pregunté por qué pasa eso si en realidad ni siquiera lo uso
      El Wi-Fi también está como queso gruyere: no se puede apagar por completo desde el Centro de control
    • En bluez v5.70-4 de Fedora 38, parece que el valor predeterminado es true desde el 7 de diciembre
      $ rpm -q --changelog bluez | grep CVE-2023-45866 -C1
      * Thu Dec 07 2023 Peter Robinson - 5.70-4
      - Add mitigation for CVE-2023-45866
    • Es una lástima que en iOS sea tan engorroso apagar el Bluetooth. En Android es deslizar y tocar; en iOS hay que deslizar, mantener presionado dos veces y tocar dos veces
      Después de pasarme desde Android lo intenté durante un tiempo, pero al final me rendí
    • Si ves esa página, dice que solo funciona en cosas que no requieren contraseña ni autenticación biométrica
      Si bloqueas activamente el teléfono cuando no lo usas, y si mientras lo usas se envían pulsaciones de teclas se verían en la pantalla, entonces no parece tan terrible dejar el Bluetooth encendido
    • Me pregunto si hay alguna forma de verificar si GrapheneOS corrigió esto en la rama sunfish (4a). Como es un Pixel 4a estoy atado a Android 13, y necesito Bluetooth para abrir la puerta del auto
      Si GrapheneOS lo corrigió, por fin sería un motivo para cambiarme, pero como mi teléfono actual funciona perfectamente, es difícil justificar comprar uno nuevo

  • Me llama la atención que Windows no se mencione en absoluto. A primera vista suena como una buena noticia, pero para poder evaluar el riesgo habría que saber por qué Windows no está realmente afectado
    Por ejemplo, si se supiera que en el stack Bluetooth de Windows existe una estructura equivalente a ClassicBondedOnly=false de BlueZ, entonces en entornos que quieran reforzarse habría que vigilar que ese valor esté en true
    O quizá el stack funciona de una forma completamente distinta y las consideraciones sean totalmente diferentes
    Me entusiasman los videos con muchos PoC y demos, pero Windows tiene mucha cuota de mercado y muchos administradores de sistemas que podrían asustarse, así que sería bueno tener información. Incluso “todavía no hemos intentado atacar Windows” sería información útil

    • Puede que Windows no sea vulnerable a este ataque específico
      Pero si creas un dispositivo Bluetooth con Flipper Zero, en cuanto un cliente Windows se conecta lo reconoce como teclado y puedes hacer que ejecute los comandos de PowerShell que quieras. Yo solo lo probé para abrir YouTube y hacer un RickRoll; no intenté nada ilegal
      Ahora tengo todos los Bluetooth apagados, pero no sé cómo quitar bluez sin romper Linux
    • Quizá sea porque en Windows rara vez el Bluetooth funciona bien en circunstancias normales
    • Dijiste que el stack Bluetooth de Windows equivale a ClassicBondedOnly=false de BlueZ; ¿acaso querías decir ClassicBondedOnly=true?
    • Creo que es porque todavía no lo han intentado en Windows

  • Ahora que la industria eliminó las conexiones físicas de audio de los teléfonos y nos empujó a lo inalámbrico, es genial ver noticias como esta. Muy bien hecho

    • Los DAC USB-C son baratos y fáciles de conseguir
    • Esta vulnerabilidad consiste en inyectar pulsaciones de teclas en teclados y mouse inalámbricos conectados.[1] Con la adopción de USB-C por parte de la industria de teléfonos, las conexiones cableadas son más fáciles que nunca
      [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...

  • Esta vulnerabilidad funciona engañando a la máquina de estados del host Bluetooth para que se empareje con un teclado falso sin confirmación del usuario. El mecanismo subyacente de emparejamiento sin autenticación está definido en la especificación Bluetooth, y errores específicos de implementación lo exponen a un atacante
    Pero ¿por qué habrían querido permitir un emparejamiento silencioso? Me gustaría saber con más detalle cuál era el propósito previsto del mecanismo problemático

    • Según la especificación Bluetooth, es por muchos dispositivos que no son computadoras. Por ejemplo, para que al emparejar el primer control con una PlayStation no tengas que conectar un mouse USB y hacer clic en “permitir emparejamiento”
      En los dispositivos realmente afectados, no sé por qué lo dejaron así
    • Es simplemente un diseño antiguo de una época más ingenua. Las especificaciones modernas no lo permiten, pero los stacks Bluetooth tenían desactivado el comportamiento nuevo para maximizar la compatibilidad

  • Este problema se corrigió en macOS 14.2 e iOS 17.2
    https://support.apple.com/en-us/HT214036
    https://support.apple.com/en-us/HT214035

  • En Arch Linux se corrigió a partir de bluez 5.70-2 [1]
    [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

  • Me pegó la parte de “en ese momento Bluetooth me parecía intimidante, así que simplemente asumí que era seguro”. Parece que de esa intimidación nace el mito de que, en algún lugar por encima de una pila tecnológica compleja, hay gente que realmente entiende lo que hace, y que no estamos sosteniendo con palitos un castillo construido sobre arena.

  • Dudo que sea práctico contra teléfonos o computadoras, pero si estás en la posición de tener que administrar kioscos para que nadie los manipule, la vida se volvió un poco más interesante.

    • Hace unos 10 años, por accidente expuse a Internet una máquina Linux con VNC abierto y sin contraseña. En cuestión de minutos alguien se conectó e intentó ejecutar algo con entradas de teclado automatizadas, pero claramente eran acciones dirigidas a Windows.
      Si logras plantar con éxito una sola puerta trasera, puedes trabajar a partir de ahí.
      En un ataque dirigido, podría bastar con enviar una pulsación de Shift cada minuto para evitar que se active el bloqueo de pantalla y luego ir físicamente a la máquina más tarde para hacer algo.
    • En una computadora, también parece posible esconder en algún lado un sudo o su envenenado y agregarlo al $PATH.

  • Con USB pasa algo parecido. Si conectas un teclado a un puerto “solo de carga”, funciona. Lo probé directamente en Android y aquí me regañaron diciendo que, en la práctica, no era explotable.

    • ¿Acaso el puerto de Android se usa solo para cargar? También es muy útil para HDMI y puede usarse con periféricos.
      Aun así, no veo esto como una vulnerabilidad. Es simplemente una función útil. El problema aquí es que alguien puede hacerlo sin que el usuario se dé cuenta, incluso durante tareas sensibles.
      El genial proyecto publicado ayer https://mitxela.com/projects/smsc también podía usarse con un teléfono de esta manera.
    • Me da curiosidad qué dispositivo Android tiene físicamente un puerto “solo de carga”.

  • La vulnerabilidad de Linux se corrigió en 2020 (CVE-2020-0556), pero esa corrección quedó desactivada de forma predeterminada. Se sabe que solo ChromeOS la activó, pese a que Ubuntu, Debian, Fedora, Gentoo, Arch y Alpine publicaron avisos.

    • Me tomó 30 segundos verificar si había entrado en NixOS[1]. Dediqué otros 30 segundos y vi que fue parchado el 2023-12-08 a las 08:23 GMT+13, un día después de que se publicara el artículo.
      Pero si el aviso de la distribución dice que con solo actualizar se corrige[2], no entiendo qué significa que “la corrección estaba desactivada por defecto”. ¿Quiere decir que después de actualizar todavía hace falta cambiar la configuración manualmente? La corrección de NixOS parece invertir el valor predeterminado.
      Si querían decir que los usuarios que configuraron explícitamente ClassicBondedOnly=false tienen que cambiarlo, podrían haberlo escrito de forma mucho más clara.
      [1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
      [2] https://ubuntu.com/security/notices/USN-4311-1