Fuzzing de ECU: cómo encontrar fallos en UDS, DoIP y SOME/IP

El fuzzing envía datos malformados, inesperados o aleatorios a un sistema y observa si se producen fallos. En las ECU de automoción es una de las formas más eficaces de encontrar errores de seguridad de memoria y problemas de robustez en las pilas de protocolos antes de que los encuentren los atacantes o el uso en campo.

¿Por qué hacer fuzzing a las ECU?

Las ECU procesan entradas no confiables constantemente: peticiones de diagnóstico por UDS, llamadas a servicios por SOME/IP, tramas en CAN, paquetes por Ethernet. Estos parsers suelen estar escritos en C o C++, a menudo se reutilizan de una generación a otra y rara vez se prueban con entradas hostiles. Una sola escritura fuera de límites en un manejador de diagnóstico puede provocar una denegación de servicio o, peor aún, la ejecución de código en un controlador relevante para la seguridad funcional.

Qué someter a fuzzing

Interfaz	Objetivos habituales
UDS (ISO 14229) sobre CAN / DoIP	Control de sesión, ReadDataByIdentifier, WriteDataByIdentifier, SecurityAccess, RoutineControl, servicios de transferencia
DoIP (ISO 13400)	Identificación del vehículo, activación de enrutamiento, encapsulado de mensajes de diagnóstico
SOME/IP y SOME/IP-SD	Descubrimiento de servicios, llamadas a métodos, serialización de payloads
CAN / CAN FD	Decodificación de señales, segmentación ISO-TP, enrutamiento en el gateway
Inalámbrico (Bluetooth, Wi-Fi)	Emparejamiento, perfiles, tramas de gestión en unidades de infoentretenimiento (IVI) y de telemática

Tres tipos de fuzzing

1. Fuzzing aleatorio (dumb): bytes o tramas aleatorios. Barato y rápido, bueno para encontrar problemas superficiales en los parsers, pero la mayoría de las entradas se rechazan muy pronto.
2. Fuzzing consciente del protocolo (basado en generación): las entradas se generan a partir de un modelo del protocolo, por ejemplo IDs de servicio UDS válidos con subfunciones y longitudes mutadas. Llega a rutas de código mucho más profundas.
3. Fuzzing basado en bases de datos: utiliza las bases de datos de diagnóstico ODX/CDD para saber qué DID y rutinas existen, sus tipos de datos y longitudes, y después muta exactamente esos. Es el enfoque más eficiente cuando se dispone de las bases de datos.

Detectar fallos en hardware real

A diferencia del fuzzing de software, normalmente no se puede acoplar un sanitizer a una ECU. En su lugar, los fuzzers utilizan oráculos:

• Comprobaciones de actividad: la ECU sigue respondiendo a un TesterPresent o a un DID conocido
• Reinicios inesperados: caídas de sesión, respuestas de reinicio de la ECU, DTC registrados
• Anomalías de tiempo: tiempos de respuesta muy alejados de la línea base
• Efectos a nivel de bus: faltan mensajes cíclicos de la ECU bajo prueba
• Monitorización de alimentación y corriente en el banco

Cada anomalía debe guardarse con la secuencia exacta de entradas para que los desarrolladores puedan reproducirla y clasificarla.

Integrar el fuzzing en el proceso de release

El mayor beneficio se obtiene cuando el fuzzing no es una actividad puntual, sino que se ejecuta en cada release de software:

• Ejecute campañas en un banco o en un equipo HIL dentro de la CI
• Haga seguimiento de los hallazgos por ECU y versión de software
• Vincule los resultados con la TARA y los requisitos de ciberseguridad como evidencia para la ISO/SAE 21434

Ese es exactamente el flujo de trabajo que automatiza nuestra suite de pruebas de seguridad AutoST, con motores de fuzzing para UDS, DoIP, SOME/IP y CAN/CAN FD. Para análisis manuales más profundos, nuestro equipo ofrece pruebas de penetración de automoción.