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 no solo eran conocidas públicamente sino que 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 encriptadas 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 script de instalación de Linux que creaba un archivo ZIP adecuado para realizar una actualización del sistema.
Resulta que la clave de cifrado en ese script es la primera clave de ejemplo CBC AES de 128 bits que figura en un documento NIST
El script 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 script 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 no iba a ser tan fácil: una parte de los datos suministrados, al menos, 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 que un lector nos llamó la atención esta semana.
“Resulta que la clave de cifrado [AES] en ese script es la primera clave de ejemplo CBC AES de 128 bits que figura en el documento NIST SP800-38A [PDF]”, agregó.
Aparte, el consenso en la criptocomunidad parece ser que CBC es difícil de usar correctamente y se recomiendan otros enfoques. Microsoft advirtió el año pasado que el uso de AES CBC con relleno puede no ser seguro.
“Microsoft cree que ya no es seguro descifrar los datos cifrados con el modo de cifrado simétrico Cipher-Block-Chaining (CBC) cuando se ha aplicado un relleno verificable sin garantizar primero la integridad del texto cifrado, excepto en circunstancias muy específicas”, dijo la empresa . “Este juicio se basa en investigaciones criptográficas actualmente conocidas”.
Pero la culpa de Hyundai no es la mala implementación de AES CBC; está usando otra clave publicada en línea como un secreto.
Con esa clave simétrica, Feldman pudo extraer el contenido de uno de los archivos de imagen de firmware encriptados 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.
“Como ya tenía la contraseña zip y la clave de cifrado, decidí buscar la clave de firma”, explicó Feldman. “Con un poco de suerte, no solo dejaron la clave pública sino también la clave privada”.
Su suerte se mantuvo, en cierto modo. Feldman encontró dentro de la imagen del firmware la clave pública RSA utilizada por el actualizador y buscó en línea una parte de esa clave. Los resultados de la búsqueda apuntaron a una clave pública común que aparece en tutoriales en línea como ” Ejemplo de cifrado y descifrado RSA con OpenSSL en C “.
Ese tutorial y otros proyectos que implementan OpenSSL incluyen dentro de su código fuente esa clave pública y la clave privada RSA correspondiente.
Esto significa que Hyundai usó un par de claves públicas y privadas de un tutorial y colocó la clave pública en su código, lo que le permitió a Feldman rastrear la clave privada. Por lo tanto, pudo firmar los archivos de Hyundai y hacer que el actualizador los aceptara según the register.
Es especialista en ciberseguridad con más de 16 años de experiencia en seguridad de la información. Conoce muy bien la inteligencia de amenazas, la gestión de riesgos, la evaluación de vulnerabilidades y las pruebas de penetración, el análisis forense cibernético y la tecnología de seguridad en la nube (AWS, Azure, Google Cloud). Ocupó varios puestos de investigador de ciberseguridad en diferentes empresas. Tiene experiencia en diferentes industrias como finanzas, atención médica, marketing, gobierno, finanzas turísticas, aerolíneas, telecomunicaciones y biometría.