En mayo de 2010, un grupo de investigadores de las universidades de San Diego y Washington, publicaron un informe titulado “Experimental Security Analysis of a Modern Automobile”. El objeto del documento era analizar las vulnerabilidades de los sistemas de control de un automóvil en el caso de que un atacante tuviese acceso físico a un puerto de comunicaciones ubicado bajo el salpicadero del mismo.

Las conclusiones fueron demoledoras, a través de esta interfaz quedan expuestos a un uso malintencionado desde dispositivos que controlan el bloqueo de puertas, pasando por la desconexión de los sistemas de iluminación exteriores, hasta actuar sobre los dispositivos de frenada o la aceleración del vehículo, o activar los airbags.

¿Cómo se ha llegado a esto?

Inicialmente, para controlar las emisiones de los vehículos y reducir las emisiones contaminantes, se equipó a todos los coches con el OBD (OnBoard Diagnose) para informar al conductor con un testigo luminoso del mal funcionamiento del motor. Este sistema ha evolucionado hasta el estándar OBD-II, adoptado por Europa mediante una directiva que ha impuesto la implementación gradual de estos sistemas en todos los vehículos desde el 2000. El interfaz del OBD-II, no sólo es utilizado por el fabricante para el diagnóstico de las funciones exigidas por la directiva, sino también, cada uno, en funciones avanzadas de sus automóviles.

El estándar OBD-II define el tipo de conector, sus conexiones, el protocolo utilizado y el formato de los mensajes. Como he comentado, este estándar define unos mínimos y cada fabricante amplió el sistema asignando pines adicionales del conector o protocolos y mensajes nuevos.

Cada vez que llevamos el coche al taller, nuestro mecánico accede al enchufe accesible debajo del salpicadero y lo conecta a un ordenador que lee los datos almacenados en la centralita de control del vehículo. Este ordenador dispone de un software, bien proporcionado por el fabricante o por terceros, que dispone de una amplia base de datos de marcas, modelos y versiones, y permite un diagnóstico inmediato del mismo, para realizar los ajustes o identificar si algo va mal.

Desde hace años existen dispositivos específicos en el mercado que permiten utilizar el conector OBD-II y con un hardware/software que añade funcionalidades útiles no implementadas por los fabricantes, como por ejemplo, activar el bloqueo de puertas cuando se supera determinada velocidad, o subir las ventanillas y apagar las luces cuando se cierra el coche con el mando a distancia.

Este equipo de investigadores tuvo que realizar un nuevo informe en agosto de 2011 (Comprehensive Experimental Analyses of Automotive Attack Surfaces), donde analizaba las vulnerabilidades de los sistemas de control partiendo de la situación en la que un atacante no tenía contacto físico con el automóvil, sino que aprovechaba la tecnología inalámbrica de equipos conectados físicamente al mismo.

La motivación fue la existencia de múltiples dispositivos de control del vehículo que se comunican con el sistema central a través de sistemas inalámbricos, por ejemplo, sensores de presión en los neumáticos, ordenadores de abordo con funcionalidades de manos libres… y toda una serie de sistemas de ayuda a la conducción que se están incorporando, incluso sistemas de aparcamiento asistido, y que, en muchos casos, reciben datos externos por canales específicos de radio o de internet. Nuevamente, una directiva europea, obliga a que todos los vehículos que se comercialicen a partir de noviembre de 2012, dispongan de sistemas de control de la presión de los neumáticos de serie, en aras de una mayor seguridad de la conducción y la reducción de la contaminación por el mayor consumo derivado de la inadecuada presión de los mismos.

Otros fabricantes desarrollan sistemas de localización, control de desplazamientos e incluso bloqueo de los vehículos si fuese necesario, lo que resulta de gran utilidad a las empresas de alquiler de vehículos para vigilar si sus clientes cumplen con las condiciones del contrato de uso.

Los fabricantes de estos dispositivos, muy especializados en este negocio y con contratos draconianos con las grandes marcas, aplican controles severos en la fabricación, preocupados por la seguridad de los mismos, es decir, que sean fiables y duraderos… ¿e invulnerables?

Estos sistemas integran circuitos de terceros a los que se les exige también los mismos requisitos de fiabilidad. Por centrarnos en el ejemplo de los sensores de presión, seguramente pasarán por una batería de tests en los que se les somete a pruebas de cambios de temperatura y humedad, aplicación de fuerzas centrífugas, etc., para simular las condiciones más extremas a las que serán sometidos sin que merme su exactitud en la medida o fallen las comunicaciones con la centralita de control más allá de los periodos máximos tolerados. Estos dispositivos se alojan en la llanta, dentro del espacio cubierto por el neumático, así que, por lo general, se comunican por bluetooth con la centralita.

Pero estos sistemas disponen de un microcódigo (software) con el que se han programado sus funcionalidades y se gobiernan las comunicaciones con la centralita. Apuesto por que este software es muy robusto y hace sólo lo que tiene que hacer, pero, ¿puede existir alguna vulnerabilidad en el mismo? La respuesta podría ser que sí. ¿Si este software tuviese algún tipo de funcionalidad para que un mecánico lo calibrase en una revisión mediante códigos de acceso celosamente guardados en un dispositivo inalámbrico de diagnóstico propietario? La respuesta sería, rotundamente, sí.

Si trasladamos este ejemplo al ordenador de abordo, donde además del microcódigo para gobernar las comunicaciones, el teclado y la pantalla, el software que se integra es más heterogéneo, desarrollado a su vez por otros y con miles y miles de líneas de código en continua evolución y mejora. ¿Cuántas vulnerabilidades pueden aparecer? ¿Les recuerdo el número de revisiones de software que nos llega a nuestros equipos de sobremesa? Por si les parece exagerado, ¿han comprobado cuántas actualizaciones anuncia Apple para los dispositivos personales, considerados como de los más seguros en el mercado? Y por si aún quedan escépticos, CISCO, el fabricante más conocido y extendido de dispositivos de red (sí, siga el cable de red de su ordenador y llegará a él), publica un mínimo de una actualización del software al mes.

Concluyendo, tal y como está evolucionando el mercado del automóvil y la exigencia de los consumidores, si los fabricantes no toman medidas y decisiones al respecto, la conducción de nuestro vehículo puede estar expuesta a serios problemas de seguridad y el riesgo crecerá exponencialmente a medida que se extiendan estos dispositivos y, en paralelo, otros dispositivos idénticos que pueden utilizarse para explotar sus vulnerabilidades.

En el próximo post analizaremos los nuevos retos para la seguridad en este escenario de aplicación de la tecnología y unas modestas sugerencias a estos gigantes de la automoción para invertir en seguridad y ahorrarse costosas sustituciones de dispositivos en el taller.

Teniendo en cuenta lo dicho de los dispositivos integrados por los fabricantes, ¿aún sigue pensando en comprarse ese cable por 30€ que permite visualizar en su smartphone el funcionamiento interno de su vehículo y que sube las ventanillas reconociendo su voz? Pues le informo que tiene donde elegir y se lo puede bajar gratis, pero es posible que acabe en la cárcel por homicidio involuntario, porque los grandes fabricantes tienen mejores abogados que Vd.

Cuando pude reponerme del susto, analicé la situación. Era difícil pensar qué hacer con el ensordecedor sonido del motor revolucionado, el claxon y la música en los altavoces. El airbag se había activado, todas las luces se encendían y apagaban y empezaba a salir humo negro del capó. El ambiente estaba impregnado de un fuerte olor de los discos de freno, en la consola había un símbolo con una calavera sonriente, sentí miedo e intenté abrir la puerta. Estaba bloqueada y me envolvió el pánico. Una luz cegadora iluminó el interior, un fuerte golpe y todo quedó en silencio. Alguien abrió la puerta y me habló.

Desperté solo en el hospital e hice un esfuerzo por recordar qué pasó en los segundos previos al accidente. Circulaba tranquilamente por la autopista, música clásica, climatizador, “cruise control”…, sólo recuerdo un inesperado frenazo, pero no qué pasó antes. Me entró ansiedad. Necesitaba una imagen que rellenase la transición entre la paz de un paisaje de carretera y la razón de la frenada.

Soy comercial y me considero una persona prudente. He valorado mucho las ventajas que te aporta la tecnología en el automóvil y he considerado estos aspectos a la hora de cambiar de coche. ¡Mira que te gustan las pijadas!, me dicen mis amigos.

Fíjate que, recomendado por un compañero que sabe de esto, me compré una especie de “Tomtom” que, además de funcionar como navegador, me permite ajustar la velocidad de crucero a la máxima de cada tramo de carretera, cierra las ventanillas cuando salgo del coche, activa el bloqueo de las puertas traseras y el maletero independientemente del resto, hace de manos libres y baja la música cuando me llaman, reconoce voz, … y me aporta un montón de gráficas de rendimiento del motor y optimización del consumo, con las que ya me pierdo. El GooglePlay es una mina de virguerías para coche, ¡y todo gratis!

No tardaron en darme el alta y, aunque me enervaba el no recordar esa imagen que me faltaba para encontrar la razón del accidente, el estar vivo y tener un seguro a todo riesgo en el renting, que iba a cubrir todos los gastos y sustituir el coche por otro nuevo, contribuía a que mirase hacia delante y borrase esa obsesión.

Días más tarde, recibí una carta certificada de la “Compañía”:

“Lamentamos comunicarle que rescindimos el servicio con Vd. y le vamos a reclamar judicialmente los gastos del siniestro y el valor residual del vehículo. Nuestro perito ha considerado que ha incumplido las cláusulas del contrato que prohíben la conexión de dispositivos no homologados por el fabricante al sistema de control del automóvil”.

Mi compañero, con una complicidad insultante, me dijo: ¡Eso es que te lo han “hackeado”, tío!

¿Cómo? ¿He incumplido las cláusulas del contrato? ¿Me lo han “hackeado”? Parece que todo el mundo tiene claro qué está pasando, pero yo no. En cuanto tenga más información os la haré llegar.

El pasado 18 de enero, nuestro compañero y “alma mater” de este Blog, el ínclito Manuel Benet, nos sorprendió con una nueva entrada que titulaba “MAGERIT: ¿Sí, o no?“, donde transcribía el artículo 13 del aún por entonces no publicado Esquema Nacional de Seguridad (ENS), y sometía la cuestión a una encuesta informal.

Para los que no conozcan el tema, en España, especialmente en las Administraciones Públicas, tenemos un referente indiscutible en el ámbito de la Seguridad de la Información cuando nos planteamos la metodología de análisis y gestión de los riesgos a seguir: MAGERIT, actualmente en su versión 2.0 y elaborada por el Consejo Superior de Administración Electrónica (CSAE), órgano del Ministerio de Administraciones Públicas encargado de la preparación, elaboración, desarrollo y aplicación de la política informática del Gobierno Español.

Por otro lado, el Esquema Nacional de Seguridad (ENS), Real Decreto 3/2010 de 8 de enero (BOE de 29 de enero), tiene por objetivo establecer la política de seguridad en la utilización de medios electrónicos, y está constituido por principios básicos y requisitos mínimos que permitan una protección adecuada de la información en el ámbito de acceso electrónico de los ciudadanos a los Servicios Públicos.

Volviendo al tema en cuestión, en el área de consultoría de S2 Grupo teníamos nuestro pequeño debate acerca de porqué en el ENS no se aconsejaba directamente el uso de MAGERIT, ni se mentaba implícitamente. Quizás la respuesta estaba en un explícito reconocimiento internacional. Así pues, decidimos investigarlo buscando referencias en ámbitos superiores y encontramos alguna referencia en ENISA (European Network and Information Security Agency) que la identifica junto a otras metodologías europeas e internacionales. Encontramos múltiples referencias en la documentación electrónica accesible de esta agencia, donde cabría destacar una ficha en la que se afirma que su extensión geográfica va más allá de los miembros de la UE y que cumple con determinadas normas nacionales e internacionales. Sin embargo, por otro lado, en el “Inventory of Risk Management / Risk Assessment Methods“, afirma que hay métodos que fueron excluidos deliberadamente de la encuesta, porque los documentos pertinentes no estaban disponibles para los miembros del grupo de trabajo (por ejemplo MAGERIT desde España).

Esta referencia nos dejó estupefactos por las consecuencias que ello pudiera tener. Trabajamos con clientes en las distintas administraciones públicas, donde utilizamos esta metodología, incluso en el sector privado, y su grado de aceptación e implantación es muy alto. Por tanto, valoramos las oportunidades de dirigirnos a personalidades que son referencias en nuestro negocio, por lo que decidimos pensar bien cómo plantear la pregunta y dirigirla, en principio, a quien publicaba el ENS: el Consejo Superior de Administración Electrónica (CSAE), a través de su dirección de contacto (secretaria.csae [en] map [punto] es).

La contestación nos ha agradado mucho, en especial porque la contestaba personalmente Miguel A. Amutio Gómez, Jefe de Área de Planificación y Explotación de la Dirección General para el Impulso de la Administración Electrónica del Ministerio de la Presidencia. Como verán, es suficientemente esclarecedora y no veo oportuno comentarla ni resumirla. Tras solicitar el preceptivo y oportuno permiso para publicarla, aquí la tienen.

Desde aquí, agradecer a Miguel A. Amutio su respuesta y el honor de hacernos partícipes de esta aclaración. Ahora le toca a nuestras administraciones ponerse manos a la obra en la implantación de ese necesario y ambicioso proyecto que es el Esquema Nacional de Seguridad. Por lo demás, nosotros nos vamos hasta el lunes; sean felices y pasen un buen fin de semana.