Un desarrollador dice que pudo ejecutar su propio software en el hardware de información y entretenimiento de su automóvil después de descubrir que el fabricante del vehículo había asegurado su sistema usando claves que además de ser conocidas públicamente, resulta que también se habían extraído de ejemplos de programación.

Daniel Feldman, un ingeniero de software con sede en Minneapolis, Minnesota, quería modificar el sistema de información y entretenimiento en el vehículo (IVI) en su Hyundai Ioniq SEL 2021. Para hacerlo, tendría que descubrir cómo conectarse al dispositivo y evitar su seguridad.

Después de tratar de descubrir cómo personalizar las actualizaciones de firmware para el sistema D-Audio2 de IVI, realizado por la subsidiaria de la plataforma de movilidad de la compañía automotriz, Hyundai Mobis, y hacer que IVI las acepte, Feldman encontró una forma inesperada: a través de Google.

El IVI acepta actualizaciones de firmware en forma de archivos ZIP protegidos con contraseña. Feldman descargó una actualización ZIP del sitio web de Hyundai y pudo omitir la protección de contraseña simple en el archivo para acceder a su contenido, que incluía imágenes de firmware cifradas para varias partes del IVI.

Entonces, su objetivo se convirtió en crear sus propias imágenes de firmware y cifrarlas dentro de un ZIP que el automóvil aceptaría, instalaría y ejecutaría, lo que le permitiría tomar el control del hardware desde su propio código proporcionado.

Por suerte, Feldman encontró en el sitio web de Mobis un programa de instalación de Linux que creaba un archivo ZIP adecuado para realizar una actualización del sistema.

El programa incluía la contraseña ZIP necesaria para los archivos de actualización del sistema, junto con una clave de cifrado AES simétrica Cipher-Block-Chaining (CBC) (una clave única en lugar de un par de claves públicas/privadas asimétricas RSA) y el IV (vector de inicialización) valor para cifrar las imágenes de firmware.

Esta información también podría usarse para descifrar las imágenes.

Eso significaba que podía usar la clave AES para descifrar las imágenes del firmware, modificarlas y luego usar el programa para volver a cifrar las imágenes usando la clave AES y empaquetarlo todo en un ZIP protegido con contraseña para que el sistema de actualización IVI de Hyundai lo ingiera.

Pero iba a ser más difícil de lo imaginado: al menos una parte de los datos proporcionados tendría que firmarse criptográficamente con una clave privada RSA y Feldman no la tenía. El actualizador usaría la clave pública RSA correspondiente de la clave privada para verificar que los datos se firmaron con la clave privada secreta correcta.

Por lo tanto, necesitaba encontrar la clave privada RSA para llegar más lejos.

«La secuencia de comandos insinuaba que se estaba utilizando la firma RSA, pero desafortunadamente la clave utilizada para eso no estaba en el código fuente», explicó Feldman en una publicación de blog en mayo . «Resulta que la clave de cifrado [AES] en ese programa es la primera clave de ejemplo CBC AES de 128 bits que figura en el documento NIST SP800-38A [PDF]», agregó.

La culpa de Hyundai dista de ser la mala implementación de AES CBC, misma que hoy en día se considera insegura; La culpa es de Hyndai radica en usar como secreto una clave publicada en línea.

Con esa clave simétrica, Feldman pudo extraer el contenido de uno de los archivos de imagen de firmware cifrados dentro del ZIP de actualización.

Y dentro de los archivos extraídos, encontró el software que maneja las actualizaciones de IVI, un binario llamado updateAgent. En otras palabras, Feldman ahora estaba mirando el mismo código, la herramienta de actualización en el IVI en su automóvil, que necesitaba vencer, lo que le dio una oportunidad deportiva de vencerlo.

Fuente: The Register.