Un investigador de seguridad ha descubierto un método para ejecutar cualquier comando con privilegios de root en la unidad de navegación de un Renault Latitude de 2014. El sistema afectado es una unidad TomTom Carminat LIVE que utiliza una versión personalizada de Linux 2.6.28.10, lo que pone de manifiesto la vulnerabilidad de los software de navegación antiguos en los vehículos.

Un investigador de seguridad ha encontrado una forma de ejecutar cualquier comando con derechos de root en la unidad de navegación de un Renault Latitude de 2014.

La unidad es un sistema central TomTom Carminat LIVE que ejecuta un sistema personalizado basado en Linux 2.6.28.10. La investigación fue publicada el 2 de noviembre de 2026 y muestra cómo el software antiguo de los coches aún puede esconder debilidades graves.

El investigador es Rasmus Moorats. Él no empezó con la intención de hackear nada; solo quería arreglar el reloj después de que terminara el horario de verano en Estonia.

La opción "Set time" (Configurar hora) no estaba disponible, y el menú de ajustes no se abría sin una tarjeta SD de mapas original. Analistas de NNS.ee señalaron que el problema proviene de la forma en que la unidad lee un archivo de script desde la tarjeta SD.

Describieron una cadena de pequeños fallos que, al unirse, otorgan el control total del dispositivo. Coches como este son comunes, y muchos guardan años de contactos telefónicos y datos de ubicación. Los coches más nuevos enfrentan riesgos similares, como se vio en los fallos de Bluetooth de PerfektBlue que pusieron en riesgo a millones de vehículos.

Hackean el software de navegación Linux de 15 años de un coche Renault

La unidad tiene más protección de la que esperarías de un software de 2011. La mayoría de las particiones son de solo lectura, "noexec" (que bloquea la ejecución de programas), o ambas cosas.

El sistema también verifica las tarjetas SD con DRM, por lo que una tarjeta en blanco o copiada es rechazada. Las imágenes de actualización también llevan una firma, así que el investigador no pudo simplemente flashear una imagen del sistema modificada.

Para estudiar la unidad de forma segura, construyó un emulador con QEMU. El emulador le mostró qué archivos lee la unidad de la tarjeta SD al arrancar. Uno de ellos es master.script, un pequeño script que automatiza acciones de la pantalla. Un programa llamado ttn lo analiza, y ttn se ejecuta como root.

Dos comandos en ese script resultaron útiles. SHEX ejecuta un programa del sistema, pero solo acepta una palabra, por lo que no se pueden pasar argumentos.

El comando LOG escribe una línea de texto plano en un archivo y tiene un error de salto de directorio (path traversal). Al añadir "../" a la ruta del archivo de registro, el escritor puede salir de la carpeta prevista. Como ttn es root, cada escritura también se realiza como root.

Ninguno de los dos fallos era suficiente por sí solo. El sistema de archivos raíz era de solo lectura y la tarjeta SD no podía ejecutar programas. Entonces, el investigador tomó prestado un truco de los exploits de kernel.

Usó el comando LOG para escribir en /proc/sys/kernel/core_pattern, el ajuste que le dice a Linux qué hacer cuando un programa falla.

Escribió allí un comando de tubería (pipe) que hace que el kernel inicie /bin/sh con un script de la tarjeta SD. El kernel entonces ejecutó el script como root.

Para provocar el fallo, usó SHEX para iniciar /bin/dbus-monitor, que se interrumpe cuando no encuentra el bus del sistema. El script final tenía solo tres líneas de largo.

Su primera prueba fue sencilla: la carga útil reinició la unidad. Después utilizó el acceso para hacer una copia de seguridad del almacenamiento interno con dd. Encontró el ajuste de hora en /mnt/flash/settings.dat y cambió el desplazamiento de UTC+3 a UTC+2.

Por qué el software antiguo de los coches sigue siendo un riesgo

Este caso fue un proyecto de investigación realizado con acceso físico al coche, por lo que no es una amenaza remota. Un criminal tendría que insertar una tarjeta SD preparada, y el conductor tendría que responder "Sí" al aviso "¿Ejecutar master.script?".

Eso limita el riesgo, pero no lo elimina. Un coche compartido, un alquiler o una visita al taller podrían darle a alguien esa oportunidad. El problema más profundo es el diseño. La unidad confía en un script de un medio extraíble, ejecuta el analizador como root y no limpia las rutas de los archivos.

Estos son errores comunes en dispositivos embebidos y duran mientras el coche esté en la carretera. Un coche puede conducirse durante 15 años o más, y las unidades centrales rara vez reciben parches.

Los investigadores siguen encontrando el mismo patrón en vehículos más nuevos. Un fallo de infoentretenimiento en el Nissan Leaf mostró cómo un componente de Bluetooth débil podría permitir el control de puertas, espejos y dirección. Esa unidad ejecutaba Linux 3.14, que data de 2013.

Las unidades centrales también son un objetivo para los criminales que quieren ganar dinero. Un informe reciente sobre malware en pantallas de coches Android describió un descargador de varias etapas que utilizaba la ruta de actualización integrada para unir pantallas infectadas a una botnet de proxies y fraude publicitario.

Incluso en ese caso, el informe no mostró el control de la dirección o el frenado. Los dispositivos antiguos con Linux también están expuestos de otras maneras. La botnet Kairos, por ejemplo, toma el control de dispositivos Linux que permiten inicios de sesión de root vía Telnet sin contraseña.

Los propietarios de coches antiguos tienen pocas opciones. Deberías mantener las tarjetas SD y memorias USB desconocidas fuera de la unidad central y comprar tarjetas de mapas solo a vendedores de confianza. También deberías preguntar al concesionario si existe alguna actualización de seguridad.