Los Honda Civic y el valet parking malicioso

 (juniperspring.org)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • La unidad principal del Honda Civic modelo 2021 puede aceptar actualizaciones firmadas con claves de prueba públicas de AOSP a través de la ruta de actualización por USB, lo que permite a un atacante con acceso físico ejecutar código arbitrario
  • Las actualizaciones de Honda se aplican mediante Android recovery, y aunque el binario recovery haya sido modificado, la lógica de verificación de firmas de verify_file coincide con la de AOSP base
  • Si se firma con la clave de prueba pública de AOSP y se da el formato correcto a la unidad USB, se puede instalar cualquier código deseado sin su ni setuid; a este ataque se le llama EvilValet
  • La nueva herramienta ota-builder facilita preparar archivos de actualización que la unidad principal acepta, y apk-rebuilder convierte archivos de actualización en un árbol de salida útil para la ingeniería inversa
  • El proyecto ya completó la mayor parte de la investigación, pero el repositorio no está abandonado y aún necesita contribuciones en información de versiones, toolchain, temas personalizados y mejoras al mapeo de AIDL

Contexto de la actualización del proyecto

  • Hace 3 años se publicó el trabajo inicial para entender y hacer ingeniería inversa de la unidad principal del Honda Civic modelo 2021, y esta actualización resume el progreso desde entonces
  • La reacción inicial fue muy alentadora, y el mayor avance surgió al entender el proceso de actualización

Las llaves del reino

  • Honda permite actualizar la unidad principal por USB y, al final, un archivo de actualización AOSP firmado dentro de la unidad USB se prepara y aplica mediante Android recovery
  • Existen varias comprobaciones específicas de Honda, pero en res/keys seguían presentes las claves de prueba de AOSP conocidas públicamente, y la lógica de firma verify_file del binario recovery modificado también coincide con la de AOSP base
  • Si se formatea correctamente la unidad USB y se firma con la clave de prueba pública de AOSP, se puede instalar cualquier contenido en la unidad principal incluso sin acceso root previo
    • No hace falta el acceso root habitual basado en configurar setuid en su
    • Si la unidad principal tiene energía y el atacante puede acceder físicamente al puerto USB más frontal, es posible ejecutar código arbitrario en la unidad principal por medio de la ruta de actualización
  • Este ataque se parece a un evil maid attack, en el que alguien obtiene acceso físico a una habitación de hotel, pero como aquí hay que acceder al interior del vehículo, se le llama EvilValet
    • En un escenario de ejemplo, si el encargado del valet parking del hotel instala una actualización por USB, el conductor no notará que la unidad principal fue modificada cuando le devuelvan el auto
  • Este texto no es una documentación técnica detallada; para más información, consulta Display Audio Update Files
  • La nueva herramienta ota-builder permite preparar fácilmente archivos de actualización aceptados por la unidad principal
    • Aún está en una etapa temprana, pero por ejemplo ya volvió trivial crear un archivo de actualización que instale un binario su con setuid habilitado
  • Hay razones de peso para pensar que todas las actualizaciones están firmadas con la clave de prueba pública de AOSP, aunque no se ha tenido acceso a todos los archivos oficiales de actualización ni a los sistemas de archivos de todas las variantes de unidades principales
    • Las unidades principales verificadas tenían la clave de prueba de AOSP en res/keys, pero como tenían historial de instalación de HondaHack, también es posible que la clave se haya inyectado en el keystore
    • El archivo de actualización de software de la UE disponible públicamente, MRC_EU_SW_v12_4.zip, está firmado con la clave de prueba y fue descargado de un foro público sin modificaciones
    • Es muy probable que todas las actualizaciones estén firmadas con la clave de prueba de AOSP, pero se necesitan contribuciones que respalden o refuten esta hipótesis

Construcción de herramientas

  • Además del proceso de actualización, el trabajo más útil fue el desarrollo de apk-rebuilder
  • apk-rebuilder toma como entrada archivos de actualización del Honda Civic obtenidos en internet y genera un árbol de archivos de salida limpio que automatiza el trabajo manual que normalmente tendría que hacer una persona de ingeniería inversa
    • Realiza interpretación de recursos
    • Realiza reconstrucción de código .smali
    • Realiza reempaquetado de archivos APK
    • Realiza extracción del ramdisk
    • También realiza otras tareas
  • Como no se puede publicar el código fuente real de Honda, apk-rebuilder funciona como una forma de tomar archivos de actualización que el repositorio público no hospeda y producir código .smali de Honda, recursos de imagen y más
  • El resultado generado sigue una estructura de directorios clara y puede referenciarse desde la documentación sin subir los archivos sensibles en sí

Trabajo pendiente y solicitud de contribuciones

  • Versiones conocidas

    • El proceso de actualización es vulnerable y depende en gran medida del número de versión
    • El número de versión puede falsificarse, así que no limita la capacidad de ejecutar código no firmado
    • Para crear un archivo de actualización, hay que conocer la versión que espera la unidad principal
    • Modificar el software de la unidad principal con una versión que no coincida con la compilación en uso puede provocar comportamiento inesperado y un recovery loop
    • Quienes conduzcan un Honda Civic de décima generación y tengan conocimientos técnicos pueden contribuir en la sección Known Versions, Display Audio Software del repositorio
    • Usuarios especialmente audaces pueden leer el código de ota-builder e intentar flashear una actualización, pero si la unidad principal no coincide con el dispositivo de referencia, puede entrar en recovery loop y quedar parcialmente inutilizada

  • Toolchain

    • En la máquina local existe un toolchain experimental y en desarrollo
    • Este toolchain toma código .c candidato y lo compila para ARMv7 con la misma versión de compilador y las mismas banderas de compilación que el binario original del proveedor
    • Este toolchain fue esencial para entender el proceso de actualización
    • En su estado actual usa mucho Docker, pero está desordenado y muy adaptado a flujos de trabajo específicos; se quiere publicar una implementación más limpia

  • Temas personalizados

    • Mientras se hacía vibe-coding en apk-renderer, se exploraron parcialmente los temas personalizados
    • Los temas personalizados están dentro del fork del framework AOSP de Mitsubishi, y es probable que sean difíciles de distribuir porque las apps de la unidad principal están reducidas para esperar IDs de recursos codificados a mano
    • Para distribuir temas personalizados, probablemente haría falta modificar quirúrgicamente el framework del proveedor y escribir herramientas para automatizarlo
    • Este trabajo no es simple y quizá no valga mucho la pena, pero las contribuciones son bienvenidas

  • Mejoras a aidl-rebuilder

    • Ya se empezó a trabajar en una herramienta que analiza archivos .smali para generar y mapear todas las interfaces AIDL de la unidad principal
    • La herramienta funciona, pero aún no se ha revisado lo suficiente su precisión
    • Este trabajo abre la puerta a apps personalizadas, como un velocímetro virtual

Ideas sobre documentación y LLM

  • Se da más peso a la tooling que a la documentación de referencia
  • Si herramientas confiables y deterministas mapean el código de la unidad principal a una forma más fácil de entender, los usuarios pueden consultar esa forma con un LLM para responder preguntas concretas
  • Como el código de la unidad principal es la fuente de verdad, se puede reducir la carga de mantener documentación de referencia que podría desviarse del código real
  • Una guía para que usuarios se conecten a la unidad principal con ADB sigue siendo útil
  • Mantener documentación separada sobre el comportamiento del código Java se vuelve una carga de mantenimiento cuando el propio código Java ya puede ser consumido por un LLM

Cierre

  • La mayor parte del trabajo de investigación previsto sobre la unidad principal ya está completado
  • Podría seguir siendo un proyecto al que dedicar tiempo, pero en adelante es probable que el enfoque cambie hacia otros proyectos
  • El repositorio no está abandonado y los PR siempre son bienvenidos

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Opiniones en Hacker News
  • La actualización del Honda Civic de 10.ª generación se distribuye por Honda mediante una memoria USB con formato especial y, en esencia, es un paquete de recuperación de la época de Android 4.2.2rc1 al que Honda solo le agregó una verificación de versión
    Esa verificación de versión se puede engañar, y el paquete está firmado con las claves de prueba públicas de AOSP, así que con solo tener acceso físico al puerto USB delantero se puede firmar y flashear un paquete arbitrario, y ejecutar código arbitrario en la unidad principal
    No hace falta root/su; lo probaron hasta el final en un Civic 2021, y también confirmaron por separado que el archivo de actualización oficial de la UE usa firmas con claves de prueba de AOSP
    • AOSP significa Android Open Source Project
    • La unidad principal de Acura del mismo año modelo también está basada en Android 4.x, así que quisieron analizarla, pero se quedaron atascados al intentar conseguir el archivo de actualización; da curiosidad saber cómo obtuvieron ese archivo
    • Bastantes sistemas de infoentretenimiento de otros autos también están basados en AOSP. Al descargar una actualización de Hyundai, recuerdan que en la práctica era una imagen de Android
  • La mayoría de los autos en circulación tienen una seguridad pésima en el infoentretenimiento y la electrónica a bordo, y con los micrófonos, cámaras, receptores GNSS, wifi y Bluetooth que traen los autos actuales, se están convirtiendo en plataformas móviles de vigilancia
    En marzo de 2026, el Information Security Manual del gobierno australiano añadió un control que indica no conectar dispositivos gubernamentales al infoentretenimiento del vehículo, ni ver material sensible o mantener conversaciones sensibles dentro o cerca de vehículos conectados
    https://www.cyber.gov.au/business-government/asds-cyber-secu...
    • ¿NC no es la categoría más baja dentro del esquema de sensibilidad?
    • Esto parece razonable. Es una radio de automóvil, no un sistema crítico
      Las personas que podrían ser vulnerables a este tipo de ataques ya tienen procedimientos y equipos de confianza para hacer su trabajo, y las agencias policiales de EE. UU. también tenían reglas parecidas para autos de alquiler desde que apareció OnStar
      La mayor parte de la información telemática riesgosa para la gente común de todos modos ya se vende
  • Por un lado se lucha contra la pérdida constante de propiedad del hardware en la mayoría de los dispositivos de nuestra vida, pero cuando aparece un dispositivo más abierto, igual lo atacan
    En tecnología, el modelo de amenaza siempre partió de la idea de que si un atacante tiene acceso físico al dispositivo y tiempo, ya ganó
    • ¿Pero realmente está abierto para que el público lo modifique? El fabricante tiene que decidir una dirección: o abrirlo por completo para que quien lo necesite pueda reforzarlo por su cuenta y entender los compromisos, o cerrarlo por completo y hacerlo seguro
      El estado intermedio actual es el peor: un dispositivo que invade la privacidad porque vigila al usuario durante toda la conducción y, al mismo tiempo, un dispositivo inseguro que entrega esos datos a cualquiera con un poco de interés
    • En la reciente vulnerabilidad de BitLocker puede verse una situación parecida. Da curiosidad si ahora se resolverán casos nuevos o terminará gente presa gracias a hardware de almacenamiento que ya se puede desbloquear
      Si tus datos pueden ser incautados, quizá sea mejor no guardarlos localmente; según la ley podrían obligarte a desbloquearlos, pero en EE. UU. deberías estar protegido aunque te niegues a entregar la contraseña
      Técnicamente, Google y Apple mejoraron mucho la seguridad física, y GrapheneOS va un paso más allá sobre esa base al reducir la superficie de ataque y sumar buenas funciones. En particular, con la adopción más amplia del reinicio automático, en los teléfonos ya se puede matizar la conclusión de que “si hay acceso físico, se acabó”
      https://grapheneos.org/features#auto-reboot
      https://discuss.grapheneos.org/d/35728-demystifying-phone-un...
    • Eso tampoco significa que se pueda renunciar a la seguridad de los dispositivos locales. Un dispositivo físico también tiene seguridad de inicio de sesión y quizá incluso cifrado completo de disco
      Que un atacante lo bastante sofisticado y persistente pueda comprometer cualquier dispositivo con acceso físico no significa que haya que ponérselo fácil a cualquiera
  • Aquí Honda parece mucho más razonable que otros fabricantes de autos
    Si un valet malicioso puede acceder físicamente al auto, no va a perder tiempo hackeando la unidad principal; simplemente esconderá un dispositivo de escucha en alguna parte del vehículo
    Además, no parece probable que un conductor de Civic sea objetivo de una agencia de inteligencia
    • No sé si es broma, pero tiene bastante poco sentido. También es poco probable que Honda lo haya hecho así a propósito
      La unidad principal suele contener información histórica, como la base de datos SQLite de contactos que quedaron tras la sincronización, historial de ubicaciones y datos pasados en telemetría o archivos de registro
      Además, la unidad principal a menudo puede acceder al bus interno del vehículo y, aunque haya un firewall como un módulo Gateway, por lo general es débil. Como en el caso famoso de Honda donde era posible desbloquear y autorizar el encendido sin material criptográfico a través del bus CAN de los faros, el infoentretenimiento puede ser mucho más potente que un simple rastreador
      Y además, insertar código en la unidad principal o extraer los datos que ya contiene deja muchas menos huellas que colocar un rastreador aparte
    • Si es sarcasmo, está bien, pero si no, no entiendo por qué un conductor de Civic no podría ser objetivo de una agencia de inteligencia
      El Civic es uno de los autos más comunes, así que se mezcla bien con el entorno, y mucha gente “de apariencia común” como científicos, ingenieros, periodistas y abogados puede manejar un Honda Civic
      Un dispositivo de escucha escondido dentro del auto puede ser descubierto, pero algo instalado directamente en el firmware del vehículo tiene menos probabilidades de ser encontrado
    • ¿De verdad crees que un científico o ingeniero aburrido con acceso a información confidencial no va al trabajo en un Civic común y corriente?
  • Una vez escuché a un gerente de producto decir con orgullo que el firmware estaba firmado por el servicio interno de firma de la empresa. Eso en sí está bien
    Pero la pregunta real era si el firmware estaba firmado por una exigencia interna, no si el procedimiento de actualización del firmware verificaba la firma; y en la práctica no verificaba nada
    • He visto una “solución” parecida. El algoritmo de firma se ejecutaba directamente desde el paquete de actualización

“si no, ¿cómo actualizas el algoritmo de firma?”, y lo peor es que en algún momento sí estaba bien hecho
el equipo de seguridad exigió firmas “seguras post-cuánticas”, cambiaron el método de firma y en ese proceso entró como regresión

  • Con un nombre como BobbyTables2, habría esperado que pensara de inmediato en la forma correcta de verificar firmas PGP de correo
  • Creo que hay una línea entre la seguridad y mantener los dispositivos útiles a largo plazo. La amenaza de que alguien instale malware de espionaje en el auto mediante un ataque estilo valet malicioso parece baja
    Pero cuando estos autos pasen, después de más de 10 años, a manos de gente con ganas de meterles mano, la capacidad de abrir el software y personalizarlo será una gran ventaja
    Ojalá surja una comunidad que haga modificaciones útiles y alargue la vida útil del dispositivo. Parece mucho mejor que que el usuario final arranque la unidad principal original y meta una unidad tipo “tablet Android” de Aliexpress, con probabilidades de tener peor seguridad y peor calidad de ingeniería que el dispositivo de Honda
  • Esto también podría ser una buena señal de que ni siquiera intentaron bloquear el sistema frente al propietario
    • No está bien permitir acceso root a cualquiera que entre un momento al auto. Es parecido a dejar en la oficina una laptop siempre encendida con un shell abierto
      Si por defecto no iban a confiar en ninguna actualización, debieron haber ofrecido un mecanismo para que el verdadero propietario pudiera aprobarlas
    • Es mucho más probable que haya sido resultado de incompetencia que algo amigable para hackers
      Si realmente hubiera sido intencional, habrían puesto algo como un bootloader desbloqueable que requiriera una llave especial, o un interruptor de difícil acceso
  • Puede que haya sido mala idea convertir el auto en una computadora gigante con ruedas. Se necesita más investigación
  • Me pregunto qué tan bien está el resto de la seguridad. La unidad principal probablemente esté conectada a un gateway CAN; quizá se pueda invocar por telemática, o tal vez exista una nueva forma de abusar de CarPlay/Android Auto para hacer que se comunique con tu casa
    • Si tienes acceso físico al auto y quieres que se comunique con tu casa, recomendaría poner un rastreador GPS debajo del tapete
      Eso funciona en más marcas que un método que solo sirve para una generación del Honda Civic, y probablemente también sea más rápido de instalar
  • Veo cada vez más proyectos reduciendo la documentación del código con la idea de que “el código bien diseñado se puede consultar con un LLM” y concentrándose en cambio en documentación de procedimientos funcionales de ejecución
    La probabilidad de que, en cualquier momento, toda la documentación de un proyecto esté realmente alineada y actualizada con el código es bajísima
    En general estoy de acuerdo con esa dirección, pero la premisa depende por completo de que el código esté bien diseñado
    • Es mejor ver las pruebas unitarias como documentación que la documentación misma
      Las pruebas pueden mostrar el uso previsto y casos límite interesantes, y como se siguen ejecutando y pasan, también sabes que están actualizadas
      Es una gran ventaja poco valorada al agregar más pruebas
      Si parece probable que un desarrollador vaya a preguntar por cierto comportamiento o caso límite, vale la pena tener una prueba que demuestre directamente la respuesta, en vez de hacerlo razonar todo otra vez con inferencias de código o lenguaje natural