Cómo engañar a los sensores de tráfico

En la conferencia RSA EEUU 2016 se expusieron en profundidad los detalles de esta investigación. La presentación puede verse aquí (en inglés)

Los sensores de tráfico comenzaron a aparecer de forma masiva en las ciudades rusas literalmente este último par de años. Al principio, los conductores que usan detectores de radar notaron en los postes ciertas cajas blancas. Sus detectores de radares de velocidad reaccionaban a las emisiones de los nuevos sensores de la misma manera que lo hacían ante los radares de la policía de tránsito.

Pero las autoridades municipales no instalaron los sensores para que los conductores “disfruten” de este efecto secundario. En cada uno de los carriles, los dispositivos cuentan el número de vehículos de diferentes tamaños, determinan su promedio de velocidad y envían la información recogida a un centro de operaciones.

Así lucen los sensores de tráfico en Moscú

Como resultado, la ciudad recibe los datos sobre la carga de las vías y sobre esa base puede, por ejemplo, hacer un plan de funcionamiento y desarrollo de la infraestructura vial. En el informe semanal, las autoridades de transporte metropolitano pueden ver cuáles son las líneas más lentas y cuales las más rápidas, utilizando dos fuentes de datos: el Centro de Organización del Tránsito (TSODD en ruso), y los datos de la compañía Yandex. La segunda columna se basa en la información recopilada por aplicaciones en teléfonos inteligentes, pero habría sido imposible recopilar la información de la primera sin la infraestructura de control vial que estamos analizando.

Cada semana las autoridades municipales publican datos sobre las vías más rápidas y más lentas de la ciudad.

En esencia, los sensores son el nivel inferior de la infraestructura de “ciudad inteligente”, que transmiten datos sobre tráfico “en bruto”, pero sin los cuales es imposible realizar ningún tipo de análisis ni hacer la correcta configuración de los sistemas. Por esta razón, la información que proporcionan los sensores debe ser precisa. Pero ¿lo es en realidad? ¿Puede algo factor externo influir en el funcionamiento de los sensores y la información que recolectan? Trataremos de responder a estas preguntas y entender qué se puede mejorar en la infraestructura informática urbana.

Cómo buscar los dispositivos y los datos que contienen

Cualquier investigación, entre ellas las de los sistemas integrados a los que pertenecen los sensores de tráfico, comienza con la recogida de todos los datos disponibles. Es imposible conocer el aspecto externo de todos los modelos de sensores incluso en un pequeño segmento si no se trabaja con ellos cada día y esto significa que lo más probable es que no se pueda reconocer las marcas de sensores a primera vista. Y en esta situación adquieren un gran valor los logotipos y rótulos adicionales que ponen los fabricantes.

Si al final se logra determinar a simple vista, y con cierto nivel de aproximación, el modelo, el siguiente paso es encontrar en los sitios web de los proveedores o integradores afines una variedad de documentación y, si hay suerte, el software para trabajar con los dispositivos. Es casi seguro que puede obtenerse un folleto de marketing; y hay grandes probabilidades de encontrar un documento de comercialización que contenga más detalles. Tampoco es raro encontrar documentación sobre la instalación, pero lo más afortunado e infrecuente es encontrar una descripción tecnológica completa con el sistema de comandos del dispositivo.

Es conveniente automatizar el funcionamiento de los sensores, para no tener que estar largo tiempo con la computadora portátil cerca de cada poste, no buscar con la mirada los dispositivos y no detenerse junto a cada uno de ellos. Ahora es posible hacerlo, porque no es nada inusual que los elementos de la “ciudad inteligente” usen protocolos de conectividad inalámbrica. Pero para efectos de automatización, lo primero que hay que hacer es entender a qué protocolo responde el sensor, y después, cómo diferenciar los dispositivos que nos interesan del resto.

Para este propósito, se puede utilizar cualquier peculiaridad de las respuestas, cualquier identificador disponible. Por ejemplo, la gran mayoría de las direcciones MAC están registradas por fabricantes específicos (aunque no todas, algunas son anónimas). Además de los identificadores numéricos, los dispositivos suelen tener tienen nombres alfabéticos, que también pueden ser estándar, por ejemplo, el nombre del modelo más un índice incremental.

Todo esto hace que sea posible escribir un escáner para buscar sólo los dispositivos que nos interesan. Uno de los modelos instalados en Moscú utiliza una conexión por Bluetooth. Tanto las direcciones MAC como los “nombres descriptivos” son específicos para cada dispositivo y nos permiten agregar a la base de datos sólo sensores de tráfico, para excluir los teléfonos y televisores inteligentes que puedan estar cerca. La seguridad del Bluetooth es un tema que está más allá del alcance de este artículo, así que no hablaremos de las maneras de comprometer dispositivos Bluetooth. En noviembre de 2015 se notificó al gobierno de Moscú sobre las deficiencias de la configuración.

Registros de los sensores de tráfico que se almacenan en la base de datos

Yo utilicé Python, PostgreSQL y un poco de C. En tiempo real, es decir, al pasar cerca del sensor, el escáner determina la dirección MAC, el nombre descriptivo y las coordenadas. Los campos “fabricante” y dirección se determinan haciendo un barrido de los registros en la base de datos, porque todos los datos necesarios ya se han guardado. Obtener una dirección según coordenadas es una tarea que requiere bastante tiempo, y que simplemente no necesita hacerse durante la etapa de búsqueda de dispositivos. Establecer una conexión Bluetooth tampoco es un proceso rápido, por lo que si se quieren detectar los sensores, es mejor no acelerar, sino por el contario, ir despacio.

¿Qué puede hacerse con el firmware?

La apertura del fabricante con respecto a los ingenieros encargados de la instalación, que requieren fácil acceso a las herramientas y documentos, significa al mismo tiempo su apertura a los investigadores. (Yo respeto este enfoque: en mi opinión, la apertura combinada con un programa de recompensas por encontrar errores da mejor resultado que el hermetismo). Se puede escoger cualquiera de los sensores detectados, instalar en el portátil el software de configuración del fabricante y dirigirse a una de las direcciones almacenadas para conectarse al dispositivo.

Al igual que con cualquier estudio de seguridad de los sistemas embebidos, lo primero que verificamos es si puede llevarse a cabo la modificación del firmware del dispositivo.

El software de configuración permite modificar el firmware del sensor

Sí, a través del acceso inalámbrico se puede modificar el firmware del dispositivo. Obtener el firmware del fabricante no es más difícil que obtener su software. Su formato tiene ciertas similitudes con Intel iHex o Motorola SREC, pero en realidad es un sistema patentado por el fabricante. Dejando de lado la información de servicio ( “:” comando de escritura, números de serie, direcciones de memoria y sumas de comprobación) de los bloques del procesador de señales digitales (DSP) y la unidad de procesamiento principal (MPU), obtenemos el código en sí. Pero no conocemos la arquitectura de los controladores del dispositivo, así que será imposible abrir el archivo con un desensamblador.

Firmware del sensor de tráfico

Aquí, por extraño que parezca, LinkedIn no sólo resulta útil para los arribistas y los departamentos de personal. A veces la arquitectura de los dispositivos no es un secreto, y los ingenieros que alguna vez trabajaron en la compañía están dispuestos a hablar de ella. Ahora, aparte del archivo, tenemos en nuestras manos información sobre la arquitectura para la cual se compiló el firmware. Sin embargo, la alegría nos duró poco. Justo hasta la ejecución del IDA.

Aunque en la documentación no se especifique los tipos de controladores, de todos modos se los puede identificar

Incluso sabiendo cuál es la arquitectura, el firmware es un conjunto de bytes sin sentido. Sin embargo, el mismo ingeniero puede proporcionar información sobre el cifrado del firmware, las tablas de claves de mesa y los algoritmos. Yo no tenía el dispositivo a mi disposición, y en este punto decidí postergar (dejar en modo black box) la modificación del firmware porque me pareció poco prometedora. Reconocemos que, en este caso particular, los ingenieros en microelectrónica saben cómo proteger el firmware. ¿Pero pone esto fin a la investigación del sensor? No, en absoluto.

Y sólo los camiones de carga viajan en la noche…

La actualización de firmware es algo “bueno” porque hace posible añadir nuevas funciones. Pero el software estándar del fabricante cuenta ya con suficientes funciones. Por ejemplo, el dispositivo tiene unos 8 MB de memoria, donde, hasta que se llene, se almacena una copia de los datos de tráfico. Y esta memoria está disponible. El firmware permite cambiar la clasificación según el largo de los vehículos que pasan y también sobre el número de carriles de la vía. ¿Desea una copia de la información de tráfico recopilada? Está bien. ¿Es necesario, por alguna razón, hacer que todos los vehículos que pasan por el carril derecho sean camiones? Es posible hacerlo. Pero esto afectará la precisión de las estadísticas urbanas, con todas las consecuencias que pueda acarrear.

Estos son los datos que recogen y transmiten los sensores de movimiento. Los mismos datos se almacenan en el dispositivo.

El que desee recibir una copia de la estadística metropolitana o ejercer influencia sobre ella, por supuesto, tendría que pasar cerca de todos los sensores, pero no es necesario que ejecute el programa en cada uno de los miles de sensores ni edite la configuración manualmente. En este caso, disponemos de una descripción del sistema patentado de comandos de estos dispositivos. No se puede afirmar que esto se encuentre a menudo durante el estudio de sistemas embebidos, pero en cualquier caso, después de establecer conexión con el sensor a través del software del proveedor, los comandos dejan de ser un secreto, ya que se hacen visibles al sniffer. Pero la descripción en inglés nos ahorra el análisis del protocolo de comunicación en lenguaje de máquina con el dispositivo.

Los comandos documentados del dispositivo permiten prescindir del análisis de tráfico

En realidad, el sensor no tiene implementados los servicios de protocolo inalámbrico Bluetooth. Su protocolo inalámbrico en este caso no es más que un medio de transmisión de datos, a través de un puerto serial convencional. El trabajo del programa con dichos puertos no se diferencia en nada de la lectura y escritura de archivos, el código para enviar comandos es trivial. Para esta finalidad ni siquiera es necesario implementar el funcionamiento normal multiproceso del puerto, porque basta con enviar un byte y recibir la respuesta en un solo flujo.

En resumen: un automóvil que se desplaza a baja velocidad por la ciudad, una computadora portátil con un transmisor Bluetooth potente y un programa de escaneo bastan para determinar la ubicación de los sensores, recopilar los datos de tráfico y si se quiere, modificar la configuración de los dispositivos. Yo no diría que la información de tráfico sea algo altamente confidencial, pero modificar la configuración de los sensores puede afectar su fiabilidad. Y esto puede afectar a los semáforos “inteligentes” y otros equipos de carreteras que basan su funcionamiento en estos datos.

El sensor nos respondió, el equipo recibió el comando. Sabiendo el sistema de comandos, es fácil “traducir” la respuesta

¿Qué hacer?

Resulta que las respuestas a las preguntas sobre la fiabilidad del tráfico y la seguridad de los datos formuladas al principio son negativas. ¿Por qué? Porque no se contaba con ningún tipo de autorización, excepto las previstas por el protocolo Bluetooth, e incluso ésta no estaba configurada de la mejor manera. El fabricante tiene una actitud muy amable con los ingenieros y una gran cantidad de datos sobre sus dispositivos es de acceso público, entre ellos los disponibles en el sitio oficial. En lo personal, me solidarizo con el fabricante y encuentro que su actitud es digna de respeto, porque no creo que la “seguridad a través de la ignorancia” tenga mucho sentido hoy en día: los que lo necesiten, encontrarán modos para conseguir el sistema de comandos y el software de ingeniería. En mi opinión, es mejor combinar la apertura, el programa de recompensas por encontrar errores y la respuesta rápida a las vulnerabilidades detectadas. Sobre todo porque el número de investigadores independientes del hardware y el software populares en todo caso siempre será mayor que el número de empleados de la división de seguridad informática.

En la etapa de la instalación hay que renunciar a los identificadores estándar. Está claro que los vendedores necesitan hacer publicidad de sus productos y las brigadas de servicio técnico deben recibir información adicional acerca de los dispositivos leyendo las etiquetas pegadas, pero aparte de ser conveniente, esto conlleva problemas de seguridad informática. Por último, no hay que confiar únicamente en la identificación estándar, implementada en los protocolos bien conocidos. Cualquier protección patentada adicional implementada de manera competente será apropiada y hará que sea mucho más difícil irrumpir en los dispositivos.

En la conferencia RSA US de 2016 expusimos los detalles de esta investigación. Puede verse la presentación en la página web de la conferencia.