Cómo buscar buenos precios en coches de segunda mano con WebScraping, Big Data & Machine Learning

En el mundo en el que vivimos hoy, donde la tecnología avanza a pasos agigantados, la industria automotriz no se queda atrás. No fue hasta que me mudé a Málaga que me di cuenta de la necesidad de tener un coche, dado que el transporte público aquí no se compara con el de Madrid. Esta necesidad me impulsó a buscar las mejores opciones disponibles en el mercado. 

Figura 1: Cómo buscar buenos precios en coches de segunda mano

con WebScraping, Big Data & Machine Learning

Fue entonces cuando me percaté de dos aspectos cruciales. Primero, que los precios de los coches han aumentado significativamente en los últimos años; y segundo, que no tengo ni idea sobre coches, por lo que las posibilidades de que me engañaran en la compra eran inmensas.  En ese momento, empecé a pensar en cómo podría comprar la Furgoneta Camper que siempre había soñado sin que me costara una fortuna. 

Figura 2: Big Data: Tecnologías para arquitecturas Data-Centric

escrito por Ibon Reinoso con prólogo de Chema Alonso en 0xWord

Entonces me di cuenta de lo útil que sería tener una base de datos con información sobre los precios de los coches según su año o kilometraje. Esto me permitiría hacer un estudio de mercado por medio de técnicas de BigData y Machine Learning y saber si el precio de un vehículo era razonable o si, por el contrario, me estaban intentando vender algo mucho más caro de lo normal.

WebScraping y Análisis de Datos

Para resolver este misterio, decidí realizar un proceso de Web Scraping de las páginas de compra y venta de coches de segunda mano más populares en España. Extraje datos como el precio, el kilometraje y el año de los modelos de coche que más me interesaban en ese momento (nunca ningún dato sensible ni personal de ningún vendedor, ni del coche). 

Fue una tarea laboriosa, ya que las APIs que utilicé solo permitían obtener datos de 100 coches a la vez y, considerando que había cerca de 300.000 coches listados, tuve que implementar un filtro robusto y armarme de mucha paciencia, pero finalmente fui capaz de poblar mi base de datos con los diferentes precios y kilómetros de cada coche en el que estaba interesado. Por ejemplo, de Volkswagen Caddy pude obtener cerca de 700 precios diferentes.

Figura 3: Mi BBDD con Wolkswagen Caddy

Después de hacer el Web Scraping y obtener los precios de los vehículos que me gustaban, ya podía empezar a comparar precios. Pero entonces pensé: ya que estoy automatizando este proceso, ¿por qué no desarrollar un programa que, mediante un algoritmo de regresión lineal, prediga si estoy a punto de hacer una buena o una mala compra? De esta manera, podría saber si el precio de una furgoneta, considerando su kilometraje, es razonable o excesivo. Y eso fue exactamente lo que hice.

Figura 4: Libro de Machine Learning aplicado a Ciberseguridad

de Fran Ramírez, Paloma Recuero, Carmen Torrano, Jose Torres

y Santiago Hernández en 0xWord.

Para lograr esto, pasé varios días investigando, ya que nunca había hecho nada relacionado con estadística ni mucho menos con Machine Learning. Finalmente, desarrollé un programa capaz de entrenar un modelo de regresión lineal. Este modelo utiliza dos parámetros, conocidos como coeficientes (Theta), para ajustar una línea que minimiza la diferencia entre los precios reales y los precios predichos. La función de coste que utilicé mide el error cuadrático medio entre los precios observados y los predichos durante el entrenamiento del modelo. Al minimizar esta función de coste, el modelo ajusta sus parámetros para hacer predicciones más precisas.

Gracias a este modelo entrenado, ahora puedo determinar de manera más informada si una furgoneta tiene un precio razonable en función de su kilometraje. Voy a mostrarte exactamente cómo funciona el programa escrito en Python que diseñé para predecir precios. Al abrir el programa, aparece un menú desde el cual puedes elegir qué deseas hacer.

Figura 5: Programa para predecir buenas o malas compras de coches

En mi caso, como ya tengo mi archivo .csv con todos los precios de las Volkswagen Caddy, decido usar la primera opción y especificar el archivo desde donde se va a nutrir. Más tarde, el programa me pedirá varias opciones de entrenamiento, como el modo visual, entre otras. Estas son características que he añadido, pero no afectan al funcionamiento del modelo.

Como recomendación, sugiero no usar la opción de entrenamiento gráfico "verbosed", ya que puede causar un retraso significativo en el entrenamiento del modelo. Una vez que nuestro modelo esté entrenado, podremos ver que la gráfica de los coches se ve aproximadamente así:

Figura 6: Gráfica de precio vs. kilometros

La línea roja que puedes ver en medio de todos los datos es la que determina el valor que el modelo predice según el kilometraje que le indiquemos. Con todo esto, el modelo ya estaría entrenado. Sólo tendríamos que buscar un coche en el que esté interesado. Por ejemplo, éste en concreto:

Figura 7: ¿Será o no una buena compra?

Una vez que hemos seleccionado un coche, debemos acceder al apartado de predicción de precios en el programa donde tendremos que especificar cuántos kilómetros tiene el coche y, como podemos ver, este coche tiene un precio bastante aceptable y no es mucho más caro de lo que debería ser. Por lo que habría que mirar mas en detalle las características del mismo pero si nos guiamos solo por estos valores podría ser una buena compra.

Figura 8: Está en precio este coche

Con toda la información que tenemos, podría ser muy interesante crear un canal de comunicación automatizado (por ejemplo Telegram) que te avise de los coches que salen con un precio inferior al promedio dado sus respectivos kilómetros. Pero eso es algo que voy a dejar para un futuro. Por el momento hasta aquí llega mi estudio sobre coches y lo que se puede hacer con los datos públicos de los mismos.

Figura 9: GitHub de este proyecto

Si quieres saber más sobre este proyecto que he creado para predecir los precios de los coches utilizando un algoritmo de descenso de gradiente, te dejo aquí el enlace al proyecto en GitHub, escrito en Python. He subido todo el código  documentado y bien organizado para que puedas explorarlo. Siéntete libre de curiosearlo y si te apetece colaborar, también puedes.

Figura 10: Libro de Python para Pentesters 2ª Edición en 0xWord

por Daniel Echeverri Montoya a.k.a. Adastra

Muchas gracias por leer el artículo. Si tienes alguna duda o comentario, no dudes en ponerte en contacto conmigo.

Autor: Daniel Pavón Gómez, área CISO de Telefónica Innovación Digital

Contactar con  Daniel Pavón Gómez

Spotify y el "Retorcido" Interfaz de Usuario en el "Car Mode"

Ya os he contado muchas veces que soy un "Power User" de Spotify Premium desde que llegó a mi vida hace 10 años casi sin darme ni cuenta. Uso casi todas sus funciones, y lo tengo conectado cada minuto en que estoy con el ordenador trabajando en soledad, cada vez que voy en coche, o cuando hago deporte. Es parte de mi vida. Me sirve para programarme sentimientos y estados de ánimo, y es una autentica maravilla de herramienta que te ayuda a elegir el color de la bola con la que quieres jugar en cada momento.

Figura 1: Spotify y el "Retorcido" Interfaz de Usuario en el "Car Mode"

Lo cierto es que para mí, la llegada de Spotify significó la apertura a música que no llegaba a mí más que por los CDs que ya tenía comprados, la radio - y yo soy de piñón fijo con Rock FM -, y las bandas sonoras de las películas. Así que cuando llegó Spotify, mi mapa se iluminó por muchas zonas que no conocía - no sé si todas buenas hoy en día -.

To Like or Not To Like : That's the Question

Y así lo sigo utilizando hoy. Así que cuando encuentro una canción que me gusta, busco al autor, lo sigo, le pido que me haga Radio de esa canción y le doy "I like it!" para que se meta en mi lista de canciones que me gustan para que las recomendaciones - basadas en Machine Learning - se sigan adaptando a mí, y de lo nuevo que sale, me traiga lo que me puede gustar.

Figura 2: Mi lista de Discover Weekly en Spotify

Así que, semanalmente entro a escuchar la lista de Discover Weekly, escucho las canciones de la lista, y voy marcando las que me gustan. Es una forma de todas las semanas meter uno o dos temas nuevos en mi mochila, que me ayudan a compensar las que me traen "Mi Hacker v2.0 (Teenager Edition)" y "Mi Survivor" en la lisa de "Patinaje", donde cada uno de los tres elegimos algunas canción para compartir en los trayectos y luego le damos al "Random" y que toque la que toque.

Figura 3: Lista de patinaje 23/24 con Mi Hacker y Mi Survivor

Pues bien, cuando voy solo en el coche escuchando Spotify tiene una función muy interesante que es "Car Mode", donde el UX/UI cambia completamente, para reducir el número de funciones que se pueden tocar en la pantalla. 

Car Mode vs Normal Mode en Spotify

Que existan esos dos modos es algo que me parece fantástico, para reducir distracciones en la conducción. Y deja funciones como Play, Fordward, Stop, Backward. Y en la parte de abajo tres funciones, que son de lo que voy a hablar en este artículo. No Me Gusta , Modo de Reproducción y Me Gusta. No me voy a meter en cuál ha sido el criterio para elegir esas opciones, pero el caso es que estas son las opciones que hay en el Car Mode. Y yo sé que están ahí, pero....¿por qué las han retorcido? Es anti-intuitivo y genera más problemas en el usuario de los que arregla.

Figura 4: Car Mode - Like a la izquierda - Not Like a la derecha

La idea del Car Mode es "Pocas cosas y botones grandes", y el NO LIKE y LIKE los han dejado, pero si vamos al UX/UI del Modo Normal de Spotify, donde están estas mismas opciones más todas las demás, vemos que esas opciones están justo a la inversa. Es decir, LIKE y NO LIKE, con lo cual para los usuarios que usan el LIKE / NO LIKE habitualmente en el Modo Normal, estas opciones en el Car Mode son anti-intuitivas, y generan enfados, frustración y que se pierdan canciones en las listas.

Figura 5: Normal Mode - Not Like a la izquierda - Like a la derecha

Así que, va aquí mi Petición al Equipo de Producto de Spotify. Por favor, poned el LIKE / NO LIKE en el mismo sitio en el Car Mode y en el Normal Mode, por favor, que esto de desaprender está bien, pero no en todos los rincones de las apps. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El parking que me entrega un trozo de papel en la era de la tecnología... y no lo entiendo #SmartCity

Aparcar en Madrid no es de las cosas más sencillas. Eso es un hecho. Pero tiene una red de parkings repartida por toda la ciudad que funcionan bastante bien. Por eso soy un usuario habitual de ellos, y por eso me los conozco bastante bien. Y hoy os quería hablar de algo, al igual que me sucede con la aplicación de Telpark, que me frustra desde el punto de la usabilidad. Y es trozo de papel que me entregan que sirve para nada. Dejadme que os lo explique.

Figura 1: El parking que me entrega un trozo de papel... y no lo entiendo

La mayoría de los parkings de los que os voy a hablar son parkings que tienen la siguiente característica: Tienen lector de matrícula. Fantástico. Una función de usabilidad que me encanta, pues si has pagado el ticket, cuando te acercas a la barrera a la salida, te reconoce la matrícula, comprueba que está pagado el ticket y se abre sin que tengas que poner el ticket en ningún lector. Fantástico. Me encanta. Y eso significa que: Tiene lector de matrículas a la salida del parking

Figura 2: Lector de matrículas en parking

Ahora bien, si analizamos el proceso, él sabe que el ticket de mi matrícula ha sido pagado porque el ticket lleva, de alguna forma, asociada la matrícula de mi vehículo, que ha leído... a la entrada del parking. Así que: Tiene lector de matrículas a la entrada del parking

Figura 3: Máquinas con lector de códigos de tickets de entrada y una

bonita pantalla táctil donde podría escribir mi matrícula fácilmente.

Fantástico. Así que sabemos que tenemos un parking que tiene lector de matrículas a la entrada y a la salida del parking, la pregunta es... ¿por qué me das un trozo de papel con el ticket? ¿Por qué no me dejas que cuando vaya a pagar escriba mi matrícula en esa bonita pantalla táctil que tienes? Vamos a ver las opciones.

Opción 1: Es por seguridad

La primera respuesta que he obtenido al respecto de esto que me trastorna es que lo hacen por seguridad. Y la respuesta ha sido que para probarlo, he ido a pagar y he llamado al soporte con el botón de ayuda que tienen y he dicho:

- "¡¡He perdido el ticket!!"

Y... ¿adivináis qué me han dicho?

- "No se preocupe, dígame la matrícula, pague y le dejamos salir".

Osea, que si pierdo el ticket, con comprobar mi matrícula me hacen otro ticket y listo. Fantástico. Es decir, que si alguien me roba las llaves del coche, y llega al parking, con decir que ha perdido el ticket resuelto. O sea... que por seguridad nada.

Opción 2: Es porque el sistema no permite hacer ese proceso

A ver, tiene.

•  Lector de matrículas en la entrada.
• Lector de matrículas en la salida.
• Pantalla táctil en la máquina de pagar.

¿Tan difícil es pedir la matrícula del coche y listo?

Opción 3: Es por si falla alguno de los lectores de matrículas

Algo que por lo visto no es fácil, pero.. si eso pasara. Hay un botón precioso que podéis probar a la salida al que podéis llamar y decir:

- "No me funciona el ticket".

Figura 4: Botón de ayuda por si falla el ticktet

Y... ¿adivináis qué me han dicho cuando he dicho eso?

- "No se preocupe, dígame la matrícula, comprobamos el pago y le dejamos salir".

Fantástico. O sea que para las incidencias tenemos un soporte que nos ayuda igualmente. 

Opción 4: Hay obligación legal de darte un ticket físico cuando entra el coche

Pues no debe ser así, porque los parkings más modernizados permiten entrar con apps tipo Telpark y no me dan ningún ticket físico. Todo digital.

Figura 5: Parking automático con Telpark

Conclusiones personales

El sistema está imprimiendo tickets - gastando papel y haciendo que los usuarios se preocupen de no perderlo - solo para reducir un caso. El caso en el que el lector de matrícula no funcione y evitar que llame por botón al soporte.  Podríais decir: "Es que por la noche no hay soporte". Fantástico. Pues que entregue tickets "sólo" cuando no haya soporte. Nos haría la vida mucho más fácil a todos, incluyendo al planeta, y ayudaría a:

• Evitar Colas en la entrada y salida: Muchas veces la gente tiene que maniobrar porque la dichosa máquina de coger e introducir ticket no es cómoda para todos los vehículos, y para muchos exige maniobrar y poner el coche en posición. O cuando se cae al suelo y hay que buscar el ticket.

Figura 6: Tickets de papel. Se pierden. Se vuelan.

Gastan papel. Tinta de impresión. Basura. 

Incomodidad en los usuarios. Preocupación.

• Evitar abolladuras y raspones: Lo mismo que antes pero con las abolladuras. Es decir, que no tengas que acercarte al bordillo donde han puesto la máquina. ¿Algunos habéis catado bordillo alguna vez?

Y para terminar este post en el que hago terapia sobre mis experiencias con los parkings, una serie de opciones más. 

• Telpark soporta muchos parkings  en Madrid, lo que es genial, porque al reconocer mi matrícula, me deja entrar y salir, pagando por la app evitando papel, colas en las máquinas de pago, y preocupación por el pago. Bien por el sistema de las apps para parkings, que en USA se utiliza masivamente.

• Parkings que quieras o no te emiten la factura: Mal. Papeleras enteras de papel y tinta tiradas a la basura. No lo entiendo.

El último mensaje es para los parkings que aún utilizan tickets con bandas magnéticas, de esas que se perturban con la proximidad de dispositivos electrónicos como, por ejemplo, el teléfono móvil, y que si se doblan dejan de funcionar, como, por ejemplo, cuando metes el ticket en la cartera y se deforma un poco. 

Figura 7: Tickets con bandas magnéticas. Horror++

Sed buenos, y quitad esos sistemas, que se diseñaron en 1976, pero ya tenemos otras tecnologías... A ver si las ciudades que quieren ser SmartCities fuerzan a que los parking quiten el ticket de papel y ayudan a todos, que con Cognitive Services de visión artificial se leen las matrículas perfectamente.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Un par de citas para la semana que viene, unas charlas en vídeo y las conferencias del Espacio Telefónica

Hoy os dejo la lista de actividades para la semana que viene que tengo en el radar. No son muchas, así que os las completo las actividades con los vídeos de las dos últimas ElevenPaths Talks dedicadas al mundo del Car Hacking y la ¿Privacidad?. Además, os dejo la lista de las charlas del Espacio Fundación Telefónica esta semana.

Figura 1: Un par de citas para la semana que viene, unas charlas
en vídeo y las conferencias del Espacio Telefónica

Yo esta semana voy a participar en pocas cosas, que la tengo atareada. Pero sí que estaré el día 18 de este mes en la presentación del equipo Movistar Estudiantes para esta temporada, que esa cita no me la puedo perder.

18: ParanoidBox: la caja fuerte digital [Online]

En este webinar impartido por Álvaro Lancho y Marcos Rodríguez, dos invitados especiales, nos hablan sobre su trabajo final de máster realizado en la Universidad Europea de Madrid, en el que presentan una caja de seguridad en la que los datos pueden entrar, pero no salir. El presenta el concepto de una caja de seguridad en la que los datos pueden acceder sin problema alguno, pero no pueden salir. Estos datos solo pueden ser liberados cuando no se pueda comprobar la vida del propietario de los datos. En este caso, los datos serán públicos para que cualquier persona pueda conocerlos.

Figura 2: Codetalk For Devs "ParanoidBox"

Durante el proyecto se han trabajado varios conceptos de identidad digital robusta para la inserción de datos, la redundancia de sistemas para controlar que todos los nodos siguen vivos y no hay riesgos de ataques físicos contra la información, y la comprobación mediante prueba de vida de que el propietario sigue vivo. Un trabajo muy interesante que no puedes perderte.

20: B-Sides [Málaga] [G]

La Peña Overflow, que se define como "un grupo de humanos al que nos une un interés por la seguridad informática. Quedamos los primeros jueves de cada mes para hacer un trivial con preguntas relacionadas con el tema que nos ocupa" organiza las B-Sides en la sala La Trinchera en Málaga para hablar de Seguridad Informática y Hacking. No te lo pierdas, que la entrada es gratuita y la agenda mola. Mira en la web.

Figura 3: B-Sides Málaga

Como os he dicho antes, os dejo las dos últimas ElevenPaths Talks que hemos hecho, de media hora de duración cada una, en ElevenPaths, dedicadas a los temas citados: Car Hacking y ¿Privacidad?

Figura 4: Car Hacking

Figura 5: ¿Privacidad?
Y ya para terminar, la agenda de esta semana  en el Espacio Fundación Telefónica en Gran Vía, que también tienes una agenda cultural que merece la pena:

Figura 6: Agenda de charlas y talleres en el Espacio Fundación Telefónica

Y esto es todo en el post de hoy. Disfrutad el viernes que ya tenemos el fin de semana encima, con muchas cosa chulas. Hoy, como sabéis, están mis amigos de Despistaos en el Festival Oh, See! de Málaga, así que si estáis por allí.... no os los perdáis.

Saludos Malignos!

Jugando al Mario Kart con los coches Tesla. ¡Mamma Mia! (Parte 2 de 2)

Como vimos en la primera parte de este artículo, hasta el momento hemos descrito varios ataques con éxito, pero ahora hay que ver como se podía conseguir atacar a la red neuronal para manipular el sistema de visión artificial del sistema Autopilot de Tesla que detecta la línea de tráfico.

Figura 11: Jugando al Mario Kart con los coches Tesla.
¡Mamma Mia! (Parte 2 de 2)

Para ello, como hemos dicho al final del primer artículo, se utilizaron dos tipos de ataques distintos al sistema de detección de carril en el Autopilot de Tesla que vamos a ver a continuación.

Ataques a la detección de carril en Tesla Autopilor

El primero de ellos llamado Eliminate Lane Attack (Ataque de Eliminación de Carril) tiene como objetivo que el reconocimiento de carril se desactive utilizando algún tipo de marca en el mundo físico. Los ataques que se generaron en el mundo digital se basaban en la distorsión de los pixeles, algo que es complicado de realizar en el mundo físico sin tener realmente comprometido todo el sistema de control de Tesla.

La aproximación principal para lograrlo se basaba en una premisa: la mayoría de la información recogida por la cámara no es útil para el reconocimiento del carril. Es decir, el proceso de la red neuronal que detecta la línea se centra exclusivamente en el carril y una porción del área que le rodea.


Figura 12: Enseña a tu AI a jugar con OpenAI y Deep Learning
La reducción de la complejidad de la imagen es una técnica habitual en el proceso de imágenes utilizando Machine Learning, mi colega Enrique Blanco Henríquez y yo la utilizamos en su día en el blog de LUCA para enseñar a una IA a jugar a Breakout.

Figura 13: La imagen de la izquierda muestra cómo se añadieron algunos
parches en la línea izquierda de la calzada y en la parte derecha se muestra
cómo el vehículo no detectó el retro de la línea.

Así que, y ahora viene la magia, después de varios experimentos se dieron cuenta que agregando recuadros de pixeles de diferentes tamaños en ciertos puntos de dicha imagen del carril y además alterando los bordes de las líneas es posible desactivar el APE (recordemos que es el Tesla Autopilot). De todas formas, este ataque demostró que el sistema APE es bastante robusto y, además, los cambios que hay que realizar en la calzada son demasiado llamativos, por lo que tanto el conductor como el APE podrían detectarlos fácilmente.

El segundo ataque se llamó Fake Lane Attack o Ataque de la Carril Falso y éste tuvo más éxito. Esta vez el objetivo no era desactivar el piloto automático, sino llevar el vehículo hasta donde queramos, como, por ejemplo, cambiar de carril utilizando marcas simples en la calzada. En el modelo digital se dieron cuenta previamente que añadiendo pequeños pixeles uno detrás de otro separados por una cierta distancia en forma lineal, el sistema de visión los detectaba como una línea de carril (ver Figura 14).

Figura 14: Colocando marcas blancas en la calzada se aprecia en la imagen
de la derecha como el vehículo detecta una línea completa donde no existe.

Este modelo digital de ataque adversario es más sencillo de implementar en el mundo real ya que sólo necesitaron colocar pequeñas pegatinas blancas de la misma forma de distribución que en el modelo digital. De esta forma consiguieron que el vehículo siguiera la trayectoria que ellos marcaron en el suelo.

Controlando el Tesla con un mando de videojuegos

Este ataque es más un problema de seguridad de acceso y explotación de vulnerabilidades a los sistemas de los vehículos Tesla. El equipo encontró que después de conseguir acceso root a la ECU (Engine Control Unit) era posible controlar el coche con un mando de juegos Bluetooth. Pero ¿cómo lo consiguieron?

Pues como muchos otros tipos de ataques, haciendo que el navegador principal del Tesla (basado en WebKit) abriera una página maliciosa. Para entender el ataque primero tenemos que ver cómo funciona y como está interconectada la CAN (Controller Area Network) bus del sistema APE, tal y como hemos explicado que hacían otros ataques en la primera parte de este artículo.

Figura 15: Esquema del sistema CAN bus de Tesla.

El sistema APE tiene dos buses principales: CAN1, el cual interconecta los radares del vehículo y CAN0, el cual junto a LB, un dispositivo que actúa a modo de gateway o pasarela de red, el cual soporta protocolos Ethernet y CAN, actúa como sistema de seguridad redundante principalmente.

También existe un bus lógico llamado APE2LB_CAN que interconecta APE con LB, el cual sirve para interconectar APE con dos canales interesantes, PT (PowerTrain) y CH (Chasis). Este último, CH, es la clave de todo el sistema, ya que desde este bus es posible controlar la dirección del vehículo. Pero observando el esquema, es obvio que antes de acceder a él hay romper algunas barreras del mecanismo de seguridad.

Para ello se centraron en un servicio llamado cantx el cual recibe señales intermedias desde el sistema de visión artificial que después las transforma en señales de control del vehículo. En canal de recepción de estos mensajes es el bus lógico APE2LB_CAN y luego son enviados directamente a los buses antes mencionados, PT y CH, siempre a través de la unidad LB (utilizando el protocolo UDP). Aquí es donde entra DSCM o DasSteeringControlMessage, mensaje encargado de controlar el sistema de dirección del vehículo. Este es su formato:

Figura 16: Definición de la estructura DSCM.

El ángulo de giro se define con 2 bytes en angle, counter es un contador de 6 bits que se incrementa cada vez que entra un mensaje, control_type (2 bits) indica el tipo de mensaje enviado por el CAN y finalmente checksum (1 byte) que se autodefine por si mismo. Ahora que ya conocemos un poco más cómo funciona el sistema CAN bus de APE, vamos a ver cómo consiguieron el control de la dirección del vehículo.

Control de dirección de Tesla

Para lograr controlar la dirección de los autos Tesla, inyectar directamente mensajes maliciosos tipo DSCM desde el APE al LB no funciona, ya que DSCM está protegido con una marca temporal o timestamp, el contador y un sistema de redundancia CAN llamado PARTY CAN-bus. Finalmente, el método que funcionaría sería inyectar de forma dinámica código malicioso en el servicio cantx y engancharlo con una función llamada:

DasSteeringControlMessageEmitter::finalize_message()

la cual permitiría rehusar el timestamp y el valor del contador. De todas formas, la clave final se encuentra en el valor del control_type del DSCM. Si se asigna el valor 0x01 y el APE2LB_CAN también se pone a 0x01 indicará que el destino final será el bus CH.

Figura 17: Esquema completo de la implementación final del ataque.

Finalmente utilizaron un mando de juegos conectado a un teléfono móvil, el cual se encargaba a su vez de recibir la señal para luego convertirlas, utilizando el procedimiento que se ha descrito anteriormente, a señales DSCM maliciosas a través de WiFi o 3G. De esta forma es posible controlar la dirección del coche con un simple mando de consola, igual que Mario Kart ;)

¿Qué futuro nos espera respecto a la seguridad de los vehículos autónomos?

Este paper es un gran trabajo que mezcla seguridad informática y técnicas de Machine Learning utilizando DNN, no podemos pedir más. Recomendamos su lectura en profundidad para aprender cómo realizar una ingeniería inversa completa a un vehículo Tesla, tanto de su parte de control como de su cerebro artificial. Tenemos que recordar de nuevo que Tesla corrigió estas vulnerabilidades en dos parches de seguridad que sacaron en 2017 y 2018, sobre todo el que permitía el control remoto del vehículo. El resumen lo tienes en este vídeo que publicaron en Youtube.


Figura 18: Vídeo del trabajo de Tencet Security Research sobre Tesla Autopilot
El otro ataque de las pegatinas en el asfalto no queda del todo claro si fue resuelto ya que Tesla lo tacha de ataque “no realista”. Y en parte tienen razón, ya que el piloto automático se puede desconectar en cualquier momento y fundamentan que el conductor puede tomar el control del vehículo simplemente pisando el freno o agarrando el volante en cuanto detecte la situación de riesgo.

O sea, que parece que funciona, lo que no queda claro es qué pasará cuando no haya conductores humanos en frente del volante para reaccionar a tiempo y seamos simples pasajeros …

View this post on Instagram

Hace poco os hablaba de que había salido en la foto del evento de Microsoft Inspiré que tuvo lugar el alño pasado en Las Vegas. Allí tuve una agenda intensa de trabajo, pero también nos fuimos con Jetskis a la Presa Hoover (ya os dejé alguna foto). De aquel viaje tengo muchos buenos momentos, como éste en el que el mismísimo Kevin Mitnick nos hace una demo del autopilot (el insane mode no está en video) mientras cantamos. Me quedé con las ganas de más Tesla, así que la semana pasada estuve probando el autopilot en un Tesla Model X. ¿Estamos confiados ya para que conduzcan las IA? Mis experiencias han sido buenas, lo reconozco... pero no sé qué opináis vosotr@s....

A post shared by Chema Alonso (@chemaalonso) on Apr 8, 2019 at 1:17am PDT

Una cosa es segura, Kevin Mitnick y Chema Alonso se lo pensarán dos veces antes de activar el Autopilot de Tesla la próxima vez que se encuentren en EEUU ;)

Autor: Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

Jugando al Mario Kart con los coches Tesla. ¡Mamma Mia! (Parte 1 de 2)

Todos hemos jugado alguna vez al fantástico juego Mario Kart de Nintendo. En él, controlamos un vehículo utilizando un mando de juegos en una carrera dentro de un circuito el cual también encontramos repartidos diferentes objetos que nos permiten obtener ventajas (como, por ejemplo, más velocidad) algunos de ellos impresos en la misma carretera.

Figura 1: Jugando al Mario Kart con los coches Tesla.
¡Mamma Mia!(Parte 1 de 2)

Bueno pues parece que ahora controlar un vehículo Tesla con un mando de juegos al más estilo Mario Kart y además añadir marcas en la carretera para engañar al piloto automático (Autopilot) ya es posible, al menos es lo que cuenta este paper titulado "Experimental Security Research of Tesla Autopilot".

Figura 2: "Experimental Security Research of Tesla Autopilot"

Vamos analizar en detalle este interesante documento, mezcla de ingeniería inversa, exploits, vulnerabilidades y Machine Learning. Recuerda, si quieres conocer algunos conceptos y técnicas relacionados con la seguridad y Machine Learning, nada mejor que nuestro libro, "Machine Learning aplicado a la Ciberseguridad: Técnicas y ejemplos en la detección de amenazas"

Figura 3: "Machine Learning aplicado a Ciberseguridad" de 0xWord

Hacking de Autos

Ya hablamos en su día de diferentes formas de hackear autos. Nuestros compañeros hablaron de cómo hackear un BMW i8 - mira que es difícil de encontrar uno de estos, y les dio por este modelo concreto - utilizando un software inyectado para tomar control del CANBus, y hoy en día hemos hablado de herramientas como CANAlyzat0r para buscar vulnerabilidades en CAN Bus.


Figura 4: Hackeando CANBus en automóviles
Centrados en Autopilot, hablamos de cómo los vehículos autónomos podían ser hackeados utilizando falsas señales de tráfico que confundieran a gusto del atacante su sistema de Artificial Vision. Ahora un equipo de investigadores de la empresa china Tencent Keen Security Lab han contado en el paper que hemos mencionado antes, varios hacks un vehículo Tesla.

El primer hack explica cómo es posible engañar a las redes neuronales de los coches Tesla utilizando pegatinas en la carretera, muy similar a la técnica de las señales falsas. El segundo hack explica cómo han conseguido infiltrarse en el piloto automático (APE) donde además han llegado a controlar el ECU (Engine Control Unit), es decir, la unidad que controla el motor, lo que se traduce en llegar a tener acceso total de forma remota a los mandos de control del vehículo.

Antes de continuar, tenemos que destacar que estos problemas (los cuales algunos son de 2017 y 2018) ya han sido parcheados y solucionados por la empresa del gran Elon Musk (ahora es cuando se ha hecho público todo el resultado de la investigación, la cual antes fue reportada a Tesla para que solucionara). Es más, el mismísimo Elon ha felicitado a los investigadores en una actitud que no todas las empresas tienen hacia aquellos que encuentran vulnerabilidades en sus productos.

Figura 5: Tesla Model S

En principio, esta investigación sólo afectaba (al menos este ha sido el único modelo donde se ha realizado la investigación) al Tesla Model S 75, con un hardware de piloto automático versión 2.5 y una versión de software 2018.6.1.

Cambiando la trayectoria del Tesla usando pegatinas en el suelo

El sistema de reconocimiento visual de Tesla con el piloto automático funciona realmente bien en casi cualquier condición (aunque no está recomendado en casos intensos de nieve, lluvia, niebla, etcétera). Existen cientos de vídeos que lo demuestran, pero al ser un sistema de visión puro, la información recibida requiere ser analizada y procesada antes de pasar a las complejas redes neuronales del Tesla.

Es decir, la cámara (o mejor dicho, las cámaras) HDR de 12bits (posiblemente una RCCB) obtiene las imágenes en RAW, lo que significa no se procesa la información durante su captura. Por lo tanto, necesita de un pre-procesado antes de llegar a la red neuronal correspondiente. Esas imágenes se copian directamente en una memoria compartida desde una función llamada tesla:TslaOctopusDetector::unit_process_per_camera la cual se encarga de procesar cada imagen ajustando algunos parámetros como son el tono, nivel de detalle, etcétera.

Todas esas imágenes ya procesadas se asignan su red neuronal correspondiente las cuales se encargarán de diversas funciones, como por ejemplo controlar el coche, analizar objetos, las líneas en la carretera, crear mapas de los alrededores, etcétera. Los investigadores se centraron las DNN (Deep Neural Networks) que se encargan del reconocimiento de las líneas de la carretera y el algoritmo que mantiene el vehículo siguiendo dichas líneas (Autosteer).

Figura 6: Esquema de las conexiones entre el APE (Tesla Autopilot)
y el resto de componentes del vehículo tal y como aparece en el paper.

Para esta función de reconocimiento de líneas y Autosteering, Tesla utiliza una sola gran red neuronal con varias salidas diferentes, en vez de usar una específica para cada acción concreta. La detección de las líneas de la carretera es una de estas acciones que utilizan una gran única red neuronal con múltiples salidas.

Una vez la imagen se ha procesado, se introduce en dicha red neuronal y una vez obtenido el output (salida), esta se envía a una función llamada detect_and_track la cual llamará a diferentes kernels CUDA para realizar diferentes funciones como comprobar los bordes de la línea para ver si están borrosos, añadir máscaras a los bordes de las líneas, ajustar las líneas a una rejilla virtual (generada a partir de la red neuronal que se encarga de mapear el entorno en un mapa virtual), añadir puntos de control en las líneas, etcétera. El siguiente cuadro resume todo el proceso de reconocimiento:

Figura 7: Ejemplo del procedimiento de reconocimiento de imagen,
en este caso de una línea en la calzada.

Antes de poder aplicar cualquier tipo de ataque basado en las imágenes recibidas, es necesario probar el rendimiento y estudiar el funcionamiento de los algoritmos en un entorno digital (antes de pasar al mundo real). Para ello utilizaron algoritmos “adversarios”, una técnica de Machine Learning cuyo objetivo principal es engañar un modelo concreto y su salida correspondiente a través de cambios y manipulaciones en la entrada de la información.

Figura 8: Paper que explica los ataques de Zeroth Order Optimization

Comenzaron con el sistema que detecta la lluvia (el cual utiliza una cámara en vez de un sensor) inyectando diferentes modelos de “ruido” y en concreto un tipo de ataque llamado “Zeroth Order Optimization” (ZOO) o también usando ataques de sustitución. Ambos algoritmos tienen que común que modifican la estimación del gradiente, dicho simplificando mucho el término, es algo parecido modificar el vector el cual ofrece la dirección que ofrece la solución óptima.

Figura 9: En este paper se explican los ataques de sustitución

Estos dos métodos tienen el problema de necesitar grandes cálculos lo que finalmente lleva a una tarea computacional demasiado compleja, casi imposible de implementar con resultados satisfactorios. Finalmente optaron por otro método de ejemplo de ataque adversario utilizando DNN con el algoritmo PSO (Particle Swarm Optimization). Este tipo de ataque se basa en generar un enjambre (swarm) de ruido e inyectarlo dentro de las imágenes obtenidas.

Utilizando esta técnica repetidamente contra las diferentes redes neuronales, es posible ir ajustando la puntuación obtenida en la salida de cada una de ellas hasta conseguir el resultado deseado. Además con la ventaja añadida de que dicha distorsión sólo puede ser detectada por una red neuronal y no por el ojo humano.

Figura 10: Ejemplo de inyección adversaria donde confunde a la IA al
Panda con una Llama sin que los cambios sean detectados por el ojo humano.

Por lo tanto, el objetivo final de la investigación es llevar este ataque en el mundo digital con resultado satisfactoria al mundo físico. En el caso de los parabrisas, lo consiguieron simplemente colocando una televisión justo en frente de la cámara que detecta la lluvia en el cristal e ir proyectando diferentes imágenes PSO (este ataque es poco factible implementarlo en el mundo físico en un escenario real). En pocos intentos consiguieron engañar la red neuronal.

En el caso de la detección de la línea, hay que usar un enfoque diferente. De hecho, realizaron dos tipos de ataques distintos que veremos en la siguiente parte.

Autor: Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

CANalyzat0r: Cómo analizar protocolos en el CAN BUS para hackear coches

En algunas conferencias hemos estado viendo estudios sobre los coches y la seguridad de éstos. Entre ellas las de nuestros compañeros de ElevenPaths en Argentina que se publicó en el artículo "Nosotros también hackeamos un auto". Y hace poco, sin ir más lejos que a la pasada Hackron de este año, un compañero llamado Agustín mostró una charla sobre el coche eléctrico y la seguridad de éste desde el punto de vista de la energía y de la arquitectura. Una charla diferente, pero muy interesante.

Figura 1: CANalyzat0r: Cómo analizar protocolos en el CAN BUS para hackear coches

Es un tema que me llama mucho la atención. Mi amigo Amador Aparicio - co-autor de libro de "Hacking Web Technologies"  también ha estado trabajando el tema, junto a mi otro amigo Jordi Serra - autor del libro de "Esteganografía y Estegoanálisis" -, así lo mostraron en Navaja Negra, con una maqueta muy real. Es un tema que interesa y es que la seguridad en el coche es un punto vital para la sociedad y es un tema bastante serio, como se ha ido viendo en las noticias que hemos ido viendo en los últimos años.


Figura 2: Backdooring CAN Bus en autos
Volviendo a lo que quiero contar hoy, tengo una “bendita” manía y es estar conectado a Kitploit para ver qué herramientas salen, son nuevas, y ver un poco qué hay de nuevo en lo que a herramientas y temáticas se refiere. A veces, hay herramientas que me llaman la atención y decido probarlas, aunque me gustaría probar más de las que puedo, ya que el tiempo siempre escasea. Sin ir más lejos, nuestra querida iBombShell fue publicada en Kitploit.

CANalyzat0r

Esta semana vi una herramienta que llamó mi atención. La palabra CAN aparecía en su nombre y, digamos, tenía un nombre “original”: CANalyzat0r. Me paré a revisar y quise saber más. La herramienta tiene un Github donde se puede descargar la última versión. El proyecto es el resultado de la tesis del investigador Philipp Schmied. Si os interesa el tema debéis echar un ojo a este artículo redactado por el autor donde muestra todos los entresijos de la herramienta escrita en Python.

Figura 3: CANalyzat0r

Ante todo, hay que decir que la idea de crear este tipo de herramienta no es del todo original, pero, ¿qué tiene de nuevo? ¿Por qué crear una nueva herramienta de esta temática? ¿Qué mejora? Son varias las posibles respuestas, pero el autor comenta que incorpora nuevas ideas para analizar los protocolos.

Al final es una herramienta que permite agrupar diferentes funcionalidades en una sola, algo que siempre llama la atención y gusta. Es modular y extensible, es decir, se dispone de documentación para implementar tus propios mecanismos de análisis. Se dispone de una interfaz gráfica que ayuda a manejar la herramienta de manera sencilla y cómoda. Como se puede ver, existen diferentes razones para utilizar este tipo de herramientas.

¿Dónde probar CANalyzat0r?

Se puede probar en el campo de batalla, pero quizá no es lo recomendable para empezar. Existen mecanismos para simular un CAN Bus, como, por ejemplo, el proyecto Instrument Cluster Simulator. Este proyecto genera un SocketCAN virtual, el cual te permitirá hacer uso de la herramienta CANalyzat0r sin necesidad de utilizar en un coche real. Lo mejor es manejar un poco la herramienta en un entorno controlado como es Instrument Cluster Simulator y no jugársela con las pruebas.

Figura 4: Instrument Cluster Simulator

Y una vez que lo tengas configurado, la lista de cosas que se pueden hacer con CANAlyzat0r son bastantes. Estas son algunas de las características que podemos disfrutar:

• Gestión de interfaces.
• Soporta múltiple interfaz.
• Dispone de la capacidad de generar las sesiones como proyectos, lo cual permite almacenarlo en formato JSON y poder reanudar el trabajo más adelante.
• Registro de información y de acciones de forma transparente.
• Sniffing con interfaz gráfico.
• Fuzzing y sniffing.

Figura 5: Sniffer en CANalyzat0r

• Filtros por paquetes para mejorar las posibilidades de representación de la información que nos interesa.
• Funcionalidad para comparar dumps obtenidos previamente.
• Filtrado avanzado de paquetes.
• Búsqueda por acciones concretas en paquetes específicos.
• Soporte de SQLite.
• Generación de archivos PDF y HTML.

Para el análisis de funcionalidades de componentes de los coches, el fuzzing aparece como una técnica potente, sobre todo como punto de entrada. Utilizando esta aproximación, los nodos de tipo CAN puede ser observados como un riesgo potencial. En la imagen siguiente, se puede ver un ejemplo del fuzzing utilizado en la herramienta y su configuración.

Figura 6: Fuzzer en CANalyzat0r

Se puede integrar el fuzzer con el sniffer. Conectar el CANalyzat0r al CAN BUS vía SocketCAN no es complejo. Desde la pestaña fuzzer se puede llevar a cabo esto. Es posible definir una máscara de fuzzing y configurar un tamaño de paquete el cual será aplicado de forma ‘random’. Mientras los paquetes ‘random’ están siendo generados y enviados sobre el CAN bus, es posible utilizar la pestaña de sniffer para ver los paquetes de respuesta. Estos paquetes pueden ser almacenados, reenviados o filtrados.

El ataque de replay puede ser utilizado. Para ello, es necesario capturar paquetes y hacer un dump mientras se está ejecutando en el coche ciertas tareas. Por ejemplo, el desbloqueo de puertas utilizando un control remoto. Una vez este evento o tarea ocurre, se puede conseguir mediante el sniffer. Una vez capturado dicho paquete, se puede reutilizar en un momento determinado. En el siguiente video se clasifica un evento como “Unlock”

Figura 7: Demo de CANalyzat0r

Sin duda, una herramienta interesante. Como comenté anteriormente, interesante para probar a través del simulador del CAN. Seguiré analizando más cosas sobre la herramienta. La seguridad en el mundo del coche puede avanzar y, seguramente, veamos más investigaciones que ayuden a mejorar la seguridad de todos cuando montemos en los coches.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.