Entradas de la categoría ‘Underground’

iPod

El mundo del hacking es apasionante y cada día nos ofrece nuevas técnicas para explotar agujeros de seguridad en los diversos sistemas informáticos. El pod slurping no es nada nuevo, pero por aquí nos encanta porque está diseñado de una manera tan ingeniosa que recuerda a los primitivos virus de macro, que únicamente se servían de las características propias del sistema operativo (y de un poquito de ingeniería social) para acceder hasta la cocina de las entretelas del aparato.

El experto estadounidense en seguridad informática Abe Usher utilizó el término pod slurping por primera vez hace, más o menos, cinco años. Con él describe cómo los reproductores de MP3, tales como el iPod, y otros dispositivos de almacenamiento masivo USB pueden ser utilizados fácilmente para robar información confidencial corporativa en una empresa. Y todo ello de manera muy simple: conectándolo al ordenador víctima y dejándolo actuar, de manera sutil y disimulada.

Para demostrar esta vulnerabilidad en la seguridad de cualquier empresa, Usher desarrolló una prueba de concepto con la ayuda de una aplicación software que podía buscar, automáticamente, información crítica en las redes corporativas para luego copiarla dentro de un iPod de Apple. Esta aplicación corría directamente desde cualquier iPod y, al ser conectada a una computadora, podía copiar grandes volúmenes de información en cuestión de minutos.

Aquí vamos a utilizar nuestro propio software a modo de tutorial.

No hay que mirar muy lejos hacia atrás para encontrar uno de los primeros episodios de robo con este tipo de dispositivos. En febrero del año 2002, sale a la luz una historia relacionada con un iPod que se utiliza con fines ilegales. En este informe se explica que un consultor informático, llamado Kevin Webb, estaba de compras en una de las tiendas que la cadena CompUSA tiene a lo largo y ancho de EE. UU. Deambulaba por la sección de informática, cuando observó a un joven muchacho caminar hacia donde se encontraba él. El chico se acercó hasta la pantalla de un ordenador Macintosh y, en ese momento, sacó un iPod de su bolsillo, conectando su reproductor a la máquina.

Webb, intrigado por los movimientos del adolescente, se acercó por detrás de él para investigar su actividad. Para su sorpresa, el joven estaba copiándose el nuevo Office de Microsoft para uno de los primeros Mac OS X que, en aquel momento, se vendía por aproximadamente 500 dólares americanos. Se quedó observando un poco más y fue capaz de ver a este chico recopilar algunas otras aplicaciones de software más.

Asombrado por lo que acababa de presenciar, inmediatamente se acercó a un empleado para informar de lo que acababa de ocurrir, pero simplemente recibió una expresión de despiste e ignorancia por respuesta.

Desde aquel incidente se han podido recopilar muchos casos más de robo de información con el solo hecho de conectar un dispositivo USB a un ordenador, de manera subrepticia y sin que prácticamente nadie se dé cuenta. Hasta que, como hemos ya comentado, surgió la locución pod slurping, aludiendo al iPod por ser el primer dispositivo del que se tiene constancia que ha sido utilizado para esta técnica de intrusión y, también, al término anglosajón ‘slurp’ (‘sorber’ o ‘sorbo’).

Vamos ahora a la sección práctica, a ver cómo podemos explotar esta vulnerabilidad. Lo haremos sobre sistemas Windows, pues con otros que necesitan del montaje de las unidades de disco al conectarlas, podría ser un proceso algo más complicado, aunque nunca imposible. El famoso programita de Abe Usher no era otra cosa que una secuencia de comandos en Python que contenía los argumentos y atributos necesarios para llevar a cabo esta técnica en un ordenador con sistema operativo Windows.

La mayoría de los sistemas Windows tienen varias utilidades de línea de comandos integradas que podrían realizar muy fácilmente las tareas de “absorción” de información. El comando xcopy, por ejemplo, es uno de ellos y se puede encontrar hasta Windows Vista. Esta utilidad incluye cierta sintaxis muy básica y puede ofrecernos unas amplias posibilidades de éxito, algo que vamos a demostrar a continuación.

Para nuestro ejemplo necesitamos un equipo con Windows XP o Vista (cualquier versión) y, para ser fieles al origen del término pod slurping, un iPod de Apple (podemos utilizar cualquier otro medio extraíble USB). Las siguientes instrucciones describen cómo hacer uso del comando xcopy y las características de Windows para construir un dispositivo de slurping muy fácilmente.

Paso 1. Abrimos un editor de texto y escribimos las líneas siguientes para, posteriormente, guardarlas en un archivo al que llamaremos autorun.inf. Este archivo en Windows es el que se encarga de lanzar determinadas acciones o aplicaciones cuando se introduce un medio externo de almacenamiento (como ejecutar una instalación al meter un cederrón, por ejemplo).

‘AutoPlay’ en Windows Vista

Este archivito especifica que, al introducir nuestro USB en un equipo, va a lanzar automáticamente el archivo de proceso por lotes llamado start.bat (que luego crearemos). Además, incluye un pequeño engaño, medio ingeniería social, medio phishing: esos textos tras los atributos action y label especifican los literales que van a aparecer en el ‘Explorador de archivos’ y, también, en el cuadro de diálogo ‘Reproducción automática’ (‘AutoPlay‘), ese que se arranca al conectar nuestro dispositivo. Es decir, si alguien nos espía por detrás, va a creer que lo que hacemos es instalar los controladores del dispositivo.

Paso 2. Abrimos otro archivo de texto, escribimos la línea siguiente y lo guardamos como start.bat, el archivo de procesamiento por lotes mencionado antes.

Este fichero batch ejecuta el motor de scripts Windows Script Host enviándole como argumento un archivo de script (script.vbs) que se encuentra en la unidad introducida y un archivo de proceso por lotes (bkup.bat) que es, a la vez, argumento del anterior. Ambos archivos los creamos a continuación.

Paso 3. En otro archivo de texto más escribimos lo que sigue y lo almacenamos como script.vbs, es decir un archivo de script en lenguaje VBScript y que interpreta directamente el motor Windows Script Host.

Esta línea crea el objeto de Windows Scripting Host en memoria para ejecutar un programa que le pasamos como argumento o parámetro.

Paso 4. Un último archivo deberá contener las líneas siguientes, las que se corresponden con el último batch que es, realmente, el que realiza todo el proceso de pod slurping. Lo llamaremos bkup.bat.

Este último fichero crea un directorio en nuestro dispositivo USB con el nombre del equipo al que está conectado y, a continuación, copia (mediante el comando xcopy y varios parámetros modificadores) todos los documentos del usuario de Windows XP (primer xcopy) o Windows Vista (segundo xcopy) al directorio generado.

Paso 5. Y, por fin, copiamos estos cuatro archivos a nuestro iPod o USB preferido, al directorio raíz. Listo, ya tenemos nuestro dispositivo de pod slurping preparado. ¡Sólo queda probarlo!

‘xcopy’ equiscopiando a todo trapo

Y luego ya sólo es cuestión de echarle imaginación, ingenio y fantasía. Por ejemplo, a partir de Windows Vista, disponíamos, a través del Kit de Recursos de Windows, del nuevo comando robocopy (o copia robusta). Esta herramienta proporciona una plétora de nuevas características de copia que incluyen capacidades para el sistema de archivos NTFS, atributos extendidos, opción de reinicio y muchas otras. Además, a partir de Windows 7, robocopy también incluye características de copia multihilo (multithreading), pues antes sólo podía realizar la copia de los archivos en orden consecutivo.

Hoy día, además, con la irrupción masiva de los teléfonos inteligentes, las aplicaciones de este ataque cada vez se vuelven más elaboradas y complejas. Pero, ¿existe alguna manera de evitarlo? Un empleado puede aparentar estar escuchando música en su iPod pero, en realidad, podría estar cargando archivos maliciosos o absorbiendo gigabytes de información valiosa para la empresa.

Una posible solución para evitar el robo de información es implementar políticas de control para el almacenamiento móvil en toda la empresa. Algunos expertos sugieren acciones convencionales como el bloqueo físico o lógico de puertos (algo muy sencillo para cualquier administrador de sistemas); otros plantean acciones más drásticas, como la prohibición del uso de este tipo de dispositivos en los lugares de trabajo. Nos sirvamos de una filosofía u otra, este no es el mejor camino que podemos tomar.

La manera ideal de asegurar el control completo sobre los dispositivos de almacenamiento portátil es mediante la introducción de barreras tecnológicas, tales como soluciones de software que permitan un control total sobre las transferencias de datos hacia y desde dispositivos de almacenamiento móvil por cada usuario en la red.

Sea como fuere, y cómo solemos decir desde estas trincheras digitales, no se pueden poner puertas al campo, y la explotación de los agujeros de seguridad de los distintos sistemas operativos seguirá siendo un hecho mañana y pasado mañana. La cuestión pasa por poner a prueba nuestra capacidad tecnológica y nuestros conocimientos para conseguir retos intelectuales cada vez más complejos e inasequibles. Ese es el desafío, porque robar información es un delito.

Furby

Un Furby es, básicamente, un juguete robótico; electrónico por dentro y de peluche por fuera. Aparecido originalmente en 1998 de la mano de Hasbro, se convirtió en un éxito instantáneo, provocando largas colas de padres de niños esperando en las tiendas de juguetes. Posteriormente, en el año 2005, apareció la segunda generación de Furbys (precedida por una enorme campaña publicitaria), de mayor tamaño que los anteriores, dotados de expresividad facial y un sistema de reconocimiento de voz que permite una mayor interacción con los humanos.

La idea básica es que Furby comience hablando sólo unas pocas palabras y que, con el paso del tiempo, se le puedan “enseñar” más. Además, va cambiando de personalidad y va “aprendiendo” nuestro idioma y dejando de hablar su furbish materno. Realmente, y desde el punto de vista técnico, Furby sólo sigue un programa de software estándar que progresivamente activa más opciones. A ello se le añade una gran cantidad de posibilidades de interacción con los niños: responde al ser acariciado, cuando le tiran de la cola, puede ser alimentado, es sensible a la luz y a la oscuridad, a los ruidos estridentes y a la música, a la posición, etcétera. Los Furbys también pueden comunicarse entre sí a través de un puerto infrarrojos situado entre sus ojos y, además, son capaces de recibir información digital, utilizando sonidos, por medio de la técnica conocida como modulación por desplazamiento de frecuencia (así, por ejemplo, comen diversos alimentos enviados desde una app Android).

Destripando a Furby

Las especificaciones técnicas de un Furby son un misterio y no se revelan para evitar el espionaje industrial. La verdad es que es un cacharro bastante avanzado para ser un juguete, y sus diseñadores guardan celosamente el secreto de su éxito. Para poder acceder a un conocimiento mínimo de su interior es necesario realizar técnicas de ingeniería inversa sobre él, es decir, descuartizarlo, desmembrarlo y mutilarlo para poder acceder a sus tripas e ir identificando, pieza a pieza, cada uno de sus componentes, entendiendo (y a veces intuyendo) cómo funciona el conjunto. Vamos a ello.

1. Placa y componentes principales

Placa base

Lo que podemos observar en esta fotografía es la placa madre, la plancha de circuitería principal donde van pinchados el resto de componentes. El pequeño barrilete dorado que se ve a la derecha de la imagen es el sensor de inclinación (le indica a Furby si está al derecho o al revés), que funciona mediante una pequeña pelotita interior que se mueve y activa un gatillo o disparador.

El chip central rotulado como LM324N es un componente muy común que contiene cuatro amplificadores operacionales, probablemente, para conectar los sensores de Furby. Un amplificador operacional es un dispositivo electrónico, con dos entradas y una salida, que se utiliza, entre otras cosas, para realizar operaciones matemáticas.

El pequeño chip cuadrado (trás de los cables rojo y negro) es una memoria EEPROM 93046 de 1 KB de capacidad, utilizada para almacenar el estado de madurez de Furby y otras variables. EEPROM son tipos de memoria ROM no volátiles que pueden ser programadas, borradas y reprogramadas eléctricamente.

Por último, los dos componente más interesantes de todos se encuentran en las pequeñas placas hija verticales que vemos en la zona superior derecha. La más grande contiene la CPU principal del aparato, es el chip que implementa el cerebro del juguete. La pequeña aloja el sintetizador de voz.

2. La CPU

CPU y sintetizador de voz

En esta foto tenemos la CPU y el sintetizador de voz desmontados. Ambos chips, bajo gotas de epoxi, tienen unos condensadores externos, mientras que la CPU, además, tiene un cristal o resonador cerámico piezoeléctrico para generar su frecuencia de reloj de 3,58 MHz.

La CPU, etiquetada como U1, tiene 25 patillas de conexión, la mayor parte de ellas a la placa base. Lo más seguro es que interactúe con el resto de componentes mediante 9 entradas y 3 salidas. Las 9 entradas son: pulsador de reset (en el compartimento de las pilas), sensor trasero (palmadas), sensor delantero (cosquillas), sensor sonoro (en la oreja derecha), sensor de luz (tras un panel entre los ojos), sensor de velocidad del motor, sensor de bola de inclinación (detecta orientaciones de nivel, de inclinación y “patas arriba”), sensor infrarrojos (cerca del sensor de luz) y pulsador de alimentación (bajo la lengua).

Por su parte, las salidas son: un altavoz de 2 pulgadas (sonido), un transmisor infrarrojos LED (para la comunicación con otros Furbys) y las operaciones de movimiento del motor de 6 voltios nominales (marcha adelante y marcha atrás). Además, cuenta con 6 conectores directos al módulo de sintetización de voz (para este sonido). El resto de conexiones se desconocen para que pueden servir.

En la fotografía siguiente tenemos una visión general del chip de la CPU completa en su interior. Los dos cuadrados verdes de la parte superior son los bancos de memoria que contienen el programa que hace que Furby haga lo que hace: las palabras se puede decir, la forma en que se mueve, la manera de responder a los estímulos… El resto del chip lo forma el procesador real, el cual, muy probablemente, está diseñado en una arquitectura común de microcontroladores, con un núcleo 8051, un Z80 o un 6502.

CPU por dentro

En el borde derecho del chip hay también algunos circuitos de prueba como los que se utilizan en la fábrica para comprobar si la oblea se ha procesado correctamente. Después de las pruebas, estos circuitos ya no son necesarios y son destruidos cuando el chip individual se corta de dicha oblea.

3. El sintetizador de voz

Procesador del habla

Esta imagen muestra una visión general del otro chip principal de Furby, el sintetizador de voz. Al igual que el de la CPU, contiene circuitos digitales, circuitos analógicos, ROM y RAM.

El procesador de voz que monta es, concretamente, un TSP50C04B de Texas Instruments. Este no es un chip que únicamente reproduce muestras pregrabadas, sino que realmente sintetiza diferentes sonidos basados en un lenguaje de programación especial. Esta versión cuenta con 4 KB de ROM, que se utilizan para almacenar todas las frases que Furby puede decir.

El sintetizador tiene 12 pines o patillas de conexión, 6 de las cuales van conectadas a la placa madre; otras llevan la corriente eléctrica, la toma de tierra y los dos cables del altavoz. De las 12 conexiones conocemos, pues, el funcionamiento de 10.

4. El disparador Schmitt

Disparador Schmitt

En una pequeña esquina de la placa base encontramos un chip 74HC14 de las series 74xx de Fairchild. Este dispositivo es un CMOS con disparador Schmitt de salida invertida que, seguramente, se utiliza para amortiguar algunas de las señales de los sensores antes de enviarlas a la CPU. Un disparador Schmitt previene el ruido que podría tapar a la señal original y que causaría falsos cambios de estado si los niveles de referencia y entrada son parecidos.

5. Comunicación infrarroja

Un aspecto interesante de este juguete es su capacidad para utilizar transmisiones de infrarrojos con el objeto de comunicarse con otros Furbys. Al parecer, son capaces de transferir no sólo palabras, sino también estados como, por ejemplo, un resfriado (un Furby estornuda y otro muñeco saludable comienza a estornudar también) y etapas de vida (un Furby pueden aprender palabras en un idioma después de estar en contacto con otro Furby de nivel más avanzado).

Receptor y emisor infrarrojo

Con respecto al asunto técnico, los Furbys utilizan un emisor y receptor de infrarrojos que funcionan en ciclos de aproximadamente 150-200 milisegundos, con un bit time de 2 milisegundos. Los paquetes de comunicación constan de nueve bits enviados seis veces, con un silencio entre cada conjunto de nueve, ofreciendo una tasa de repetición de, más o menos, 100 milisegundos. Esos nueve bits se componen de un bit de inicio, cuatro bits de datos y, al final, los mismos cuatro bits de datos invertidos. Hay un total de 16 señales diferentes que pueden comunicar.

6. La mecánica

Mecánica

Un motor interno impulsa las partes móviles de un Furby. Es un motor reversible de corriente continua montado a un lado del llamado módulo de movimiento (dentro de la mitad superior del juguete). El mecanismo acciona una serie de engranajes rectos de reducción que giran un tornillo sin fin. Este, a su vez, actúa sobre una gran rueda dentada unida a un eje que tiene una serie de lóbulos de leva. Los lóbulos se apoyan sobre unas bielas que mueven los párpados, la boca y las orejas, y hacen bailar al Furby con su bamboleo hacia atrás y hacia adelante.

Cada elemento móvil también puede ser operado de forma independiente si el árbol de levas gira hacia atrás y adelante dentro de un ángulo estrecho. Por ejemplo, mientras Furby baila, el eje gira de manera que hace funcionar sólo el lóbulo del movimiento de balanceo. Esta posición del árbol de levas se comporta como un punto muerto de los lóbulos que impulsan los párpados y las orejas. Durante el baile, ojos y orejas quedan quietos.

7. Hackeando un Furby

Para los hackers y entusiastas del conocimiento y de la ingeniería inversa, el puerto de infrarrojos de un Furby resulta un dulce muy jugoso. El concepto del fin primordial consiste en hacer que Furby haga cosas extrañas estimulándolo mediante órdenes enviadas a través de infrarrojos. Esto ya se ha intentado vía irDA desde un PC o por medio de transmisores de infrarrojos de otros Furbys adaptados para este propósito.

Hack

Asimismo, los hackers sospechan (pues no hay documentación al respecto) que un cierto patrón de señales de entrada podría causar que el Furby entrara en un modo exclusivo de depuración o en un estado especial, en principio inaccesible para personas ajenas a la compañía que produce el juguete. Con el fin de encontrar un comando oculto, se necesitaría ser capaz de enviar comandos arbitrarios a un Furby y pasar mucho tiempo experimentando.

8. Conclusión

Destripando un Furby

Furby fue en su época el juguete del momento, y ha vuelto mejorado y remozado para convertirse en el muñeco robótico del presente. Es entretenido, guasón, jovial y ocurrente, y posee una tecnología, como hemos visto, bastante avanzada para ser un peluche charlatán (también cuesta un ojo de la cara, claro está).

Como cacharro profundamente técnico que es, los geeks, los hackers y los frikis de los avances tecnológicos han puesto sus ojos en él. Le auguramos, pues, larga vida y nuevas funcionalidades. Todo llegará.

NOTA: La fuente de las fotografías es un artículo de Tiny Transistors.

Chema Alonso

Ayer, Chema Alonso (conocido como Maligno) apareció, para sorpresa de los que le seguimos hace años, en el programa ‘El Hormiguero‘ de Antena 3 explicando una de las técnicas que diversos hackers habían utilizado para hacerse con las fotografías de desnudos de famosas en el conocido como Celebgate (bautizado así por las entrañas más irreverentes de 4chan). Chema, para el que aún no le conozca, es Ingeniero Informático, Ingeniero Informático de Sistemas y Doctor en Seguridad Informática, casi nada. CEO en Eleven Paths, uno de los artífices de 0xWORD, Director del Master de Seguridad de Información en la Universidad Europea de Madrid, colaborador en programas radio, autor de libros de hacking y seguridad informática, conferenciante y un largo etcétera de los que quita el hipo sólo con hacerse una idea siquiera. Ah, por cierto, y Productor Ejecutivo en Cálico Electrónico (¿a que esto no te lo esperabas?) y, como no, editor del blog Un informático en el lado del mal.

Antes de seguir, vamos a ver el vídeo del fragmento en el que Chema reproduce un ataque a iCloud, concretamente a una cuenta falsa creada para el evento y que simula pertenecer al mismísimo Pablo Motos, conductor del programa.

Como se puede observar, el ataque es de lo más tontuno del universo; es un viejo phishing de manual de instrucciones alimentado por características de seguridad muy poco fiables del cliente de correo de Gmail para iPhone y de la propia Apple. Él, en su blog, lo explica técnicamente a las mil maravillas, por lo que sólo vamos a hacer un repaso somero para primerizos.

Apple no se empeña mucho en evitar el spoofing de sus direcciones IP, por lo que cualquiera puede enviar un correo electrónico en nombre de la compañía sin que se levante demasiado revuelo. Por su lado, Gmail no se empeña demasiado en hacernos ver que la procedencia no es la registrada para Apple; quizás por desidia, quizás por “la culpa es tuya, arréglalo tú”. Asimismo, el cliente de Google para dispositivos iPhone es bastante difuso escupiendo alertas de navegación externa y, además, lanza dicha navegación en objetos Web View que ocultan la barra de direcciones y, por tanto, la URL (falsa) en la que nos encontramos.

Vamos, un cúmulo de despropósitos que puede hacer que un usuario poco experimentado (o, incluso, uno más o menos experto) caiga como un panchito en la trampa, enviando su cuenta de usuario y su contraseña al atacante sin percatarse del engaño. ¡Y cómo funciona el cerebro humano, señores!, que tras el robo de nuestros datos, la falsa web nos tira un error y nos redirige a la web buena, la real, en la que volvemos a escribir nuestros datos y pasamos a la primera. Nuestra cabeza nos dice “habré introducido algo mal la primera vez”, nunca nos sugiere “me acaban de robar todo lo robable“.

Lo que eché de menos ayer en ‘El Hormiguero’, quizá por falta de tiempo y por las prisas televisivas, fue una aclaración de la solución a este problema, es decir, algo tan sencillo como explicar cómo desactivar los respaldos y las sincronizaciones en la nube Apple, así como eliminar las copias de seguridad que allí ya se encuentren. Algo sencillo de realizar y que termina con el problema de raíz.

En fin, Chema Alonso, aferrado a su inseparable rayado gorro de lana, estuvo como pez en el agua exponiendo un tema que se ha puesto de moda a cuenta de las últimas filtraciones, pero que es tan viejo como la Red misma. El tío en un crack del asunto y vale su peso en bitcoins, por lo que aconsejo a cualquiera que se interese un mínimo por su seguridad digital que le siga en su blog, su cuenta de Twitter, su perfil en Facebook o donde quiera que sea, pero que esté al tanto de lo que cuenta este hombre, que no tiene desperdicio alguno.

Car Hacking

Además de todo ello, un coche actual tiene numerosas entradas y salidas informáticas de datos, como puertos USB, unidades de cederrón, Wi-Fi, conexiones Bluetooth, controles remotos, señales GPS o XM. También, para rizar el rizo, disponemos de diversos sistemas de comunicación o protocolos, como CAN Bus, LIN Bus, MOST, FlexRay, Ethernet, RFID, TPMS o V2V.

Sistemas accesibles

Vamos, que rodamos en auténticos ordenadores muy potentes, con una gran cantidad de aparatos controlados informáticamente y compartiendo información con el exterior constantemente. ¿Qué más quiere un hacker como reto? Cualquier vehículo moderno que circula por nuestras calles es, potencialmente, un ordenador accesible, y un experto en seguridad, un hacker, podría realizar técnicas informáticas de penetración con éxito desde el exterior.

Por acotar un poco este vasto tema, nos vamos a centrar en un único asunto: el control de presión de los neumáticos, técnicamente el denominado Sistema de Monitorización de la Presión de los Neumáticos, en inglés Tire-Pressure Monitoring System, y más conocido por sus siglas TPMS. El TPMS es uno de esos elementos de seguridad activa que, siendo sencillos, nos ahorran problemas, ya que nos recuerdan la importancia de la presión del neumático. En sí, la función del sistema es esta: avisar al conductor de una pérdida de presión de inflado en los neumáticos.

¿Cómo lo hace? Notificando mediante señales luminosas y acústicas cuando la presión de inflado es demasiado baja, en función de lo que se haya establecido en el sistema. ¿Y cómo funciona técnicamente? Pues empleando ondas de baja frecuencia para comunicarse con el ordenador central.

El sistema TPMS monta un sensor colocado en cada rueda que mide la presión de inflado y transmite el dato a una centralita, la cual puede ofrecerlo desglosado por cada neumático o bien mediante un total general; o simplemente avisa cuando los datos reales no cuadran con los que tiene programados. Cada fabricante decide el funcionamiento exacto de su equipo.

Sensor TPMS

Los sensores incorporan una pequeña batería que les da autonomía para funcionar sin depender de la energía del vehículo. Estos sensores pueden medir la presión y la temperatura del neumático, además de informar al sistema (como decíamos, empleando ondas de baja frecuencia) de su posición en la rueda y del estado de su batería. Al cambiar neumáticos, rotarlos o realizar cualquier otra operación de mantenimiento suele ser necesario volver a calibrar los sensores para evitar problemas de medición.

Estos aparatos tiene un ID único de 32 bits registrado en la centralita electrónica como medio de identificación. La frecuencia varía en cada dispositivo, pero, por lo general, oscila entre los 315 Mhz y los 433 Mhz UHF, con una modulación que puede ser ASK o FSK. Sin embargo, y aunque los dispositivos TPMS suelen permanecer en estado de letargo mientras el coche circula a una velocidad inferior a 32 Km/h (aproximadamente), pueden llegar a ser “despertados” con una señal baja de radiofrecuencia de, por ejemplo, 125 kHz.

Leyendo un sensor TPMS

Los posibles ataques que esto implica y que se podrían desarrollar son tres: seguimiento de vehículos, desencadenamiento de eventos y spoofing (o suplantación de identidad). Con respecto al primero de los puntos, es posible realizar el seguimiento de uno o varios vehículos basándonos en sus ID únicos. Se puede configurar una red de múltiples sensores que se encargue de realizar el rastreo de un coche por toda una ciudad. El TPMS transmite cada 60 o 90 segundos mientras no se desencadene una función producida por una emisión RFID. Se puede utilizar, para mejorar el rango de seguimiento, un amplificador de ruido bajo, o LNA.

Para el ataque de desencadenamiento de eventos podemos hacer uso, también, del ID o identificador único para generar eventos cuando el vehículo esté cerca. Y qué tipo de eventos se pueden desencadenar, pues todo depende del grado de perversidad del atacante; alguien con buenas intenciones podría abrir la puerta de un garage cuando el coche está llegando a ella, y alguien con otro tipo de intenciones podría, por ejemplo, detonar un explosivo oculto en la carretera.

Por último, haciendo a honor los ataques de tipo spoofing, podríamos suplantar la identidad del dispositivo para enviar nuestros propios paquetes de datos al sistema central. Estas señales sólo iluminan luces en el tablero o en el salpicadero del coche, pero nuestras inyecciones de código podrían pretender otros objetivos.

En fin, si queremos aprender más sobre todos estos asuntos, porque el hacking de vehículos da para mucha tinta electrónica, podemos recurrir a diversas fuentes. Entre ellas, la web donde podemos descargar las herramientas conocidas como gr-tpms, un software libre (programado en Phyton, para más datos) que sirve para capturar, demodular, decodificar y evaluar los datos de los monitores de presión de neumáticos en automóviles que utilizan GNU Radio (herramienta de desarrollo libre y abierta que provee bloques de procesamiento de señal para implementar sistemas de radio definidos por software). Programado por Jared Boone.

También de Boone es el desarrollo TPMS, un software igual que el anterior pero que sirve para todo tipo, o casi, de dispositivos TPMS genéricos. Otro gran white paper sobre esta materia es el titulado ‘Security and Privacy Vulnerabilities of In-Car Wireless Networks: A Tire Pressure Monitoring System Case Study‘, desarrollado conjuntamente por expertos del departamento de Ciencias de la Computación de la Universidad de South Carolina en Columbia (EE. UU.) y del WINLAB de la Universidad estatal Ruygers de Nueva Jersey , en el municipio de Piscataway (en EE. UU. también).

‘Car Hacker’s Handbook’

Por último, comentar la existencia de un libro o manual gratuito (concretamente bajo licencia Creative Commons del tipo CC BY-NC-SA 3.0) titulado ‘Car Hacker’s Handbook‘ y publicado por Open Garages este año 2014. El libro contempla varios vectores de ataques con los que se podría comprometer la seguridad de un vehículo: sistemas de comunicación, sistemas de información y documentación, metodologías inversas para el protocolos CAN Bus, ataques vía Ethernet, sistemas de llaves e inmovilizadores, lectores de unidades ECU y sistemas embebidos, etc.

Quizás un buen momento para recapacitar sobre la seguridad de los coches del mercado actual y cambiar nuestro flamante vehículo por uno de los de antes, aquellos que la electrónica más moderna que implantaban era el radiocasete donde escuchábamos las machacantes cintas de gasolinera en los largos viajes vacacionales.

Desbordamiento de búfer

Un desbordamiento de búfer (buffer overflow) representa un error de software que se produce cuando un programa no controla adecuadamente la cantidad de datos que se alojan en un área de memoria previamente reservada y dimensionada. Estas áreas de memoria intermedia, o búfer, se utilizan con el fin de evitar que un recurso, ya sea de hardware o de software, se quede sin datos durante una transferencia. Un vaso sólo puede contener el agua que cabe en él, no más (analogía simplona). Si un vaso puede guardar únicamente 330 mililitros de agua, ¿qué ocurre si intentamos introducir más? Pues que se desborda, evidentemente; el agua se sale del vaso y la mesa se moja.

Los programas informáticos funcionan igual y, curiosamente, la mente humana también. El objetivo de un hacker informático es encontrar la dirección de memoria que invoca una pieza de software e insertar un código malicioso en ella. Tras controlar, pues, el flujo de ejecución, el hacker puede inyectar cualquier comando para que la aplicación “obedezca” sus órdenes. La mente humana corre o ejecuta su propio “software” y, con los años, el aprendizaje y la experiencia, construye un conjunto de instrucciones, espacios y longitudes de memoria propios, generando una suerte de “sistema operativo” mental particular y propio, inherente a cada individuo.

Error de desbordamiento de búfer

Cuando un programa informático reserva un espacio de memoria para determinada cantidad de datos y recibe una cantidad mayor, si el software no está diseñado para solucionar el problema, lanza una excepción y bloquea el flujo de ejecución. Nuestra mente reserva también espacios tipo búfer en nuestra memoria para conjuntos de datos predefinidos y conocidos. Si un determinado grupo de datos no se ajusta al espacio que tenemos para él, ¿qué sucede? A diferencia de lo que ocurre dentro de un ordenador, nuestro cerebro no se bloquea de modo inflexible, pero sí que abre una brecha o espacio momentáneo que permite la inyección de comandos externos para manipular el flujo lógico de nuestras acciones.

Para probar este concepto vamos a recurrir a un viejo juego. Observa, querido lector, la siguiente imagen y, de la manera más rápida posible, intenta decir el color de todas las palabras escritas. No leas la palabra, enuncia rápidamente el color en el que están dibujadas.

Juego de los colores

¿Es difícil, verdad? ¿Cuesta, eh? Es la eterna pugna entre los dos hemisferios de nuestro cerebro: mientras el derecho (más global, intuitivo y emocional) intenta decir el color, el izquierdo (más lineal, deductivo y racional) quiere leer la palabra. Es una inyección de comandos en toda regla, nuestro cerebro quiere leer antes la palabra que el color, porque es la forma en la que nuestra mente está “cableada”. En ese momento de confusión, existe código en el cerebro humano que es lo opuesto a lo que la persona está pensando en el instante. Mind hacked!

En el documento titulado ‘Modification of Audible and Visual Speech‘ (modificación de la expresión visual y auditiva, en inglés), publicado por los investigadores Michele Covell, Malcolm Slaney, Cristoph Bregler y Margaret Withgott (de Interval Research Corporation), se demuestra que las personas hablan a una velocidad aproximada de 150 palabras por minuto, sin embargo son capaces de pensar a 500 o 600 palabras por minuto, por lo que parece prácticamente imposible provocar un desbordamiento de búfer humano simplemente hablándole muy rápido a alguien.

También debemos comprender que las personas toman la mayor parte de las decisiones y realizan muchos actos en la vida de manera totalmente inconsciente, como por ejemplo, la forma de conducir hasta el trabajo, sacar un café de la máquina o lavarse los dientes. ¿Alguna vez has conducido todo el camino hasta trabajo y, al llegar allí, no puedes recordar los carteles publicitarios de las carreteras por las que pasaste, o la ruta que tomaste al encontrarte con mucho tráfico o el lugar del accidente que escuchaste en las noticias? En estos casos, el subconsciente se encarga de todo y realiza todo lo que tú haces siempre, sin pensar conscientemente en cada paso. Lo mismo sucede cuando no recuerdas dónde has aparcado.

La mayoría de las decisiones de las personas se hacen de esta manera. Algunos científicos creen, incluso, que los humanos tomamos decisiones hasta siete segundos antes en nuestro subconsciente que en el mundo real, aquel que nos manda información a través de los sentidos. Esta comprensión de cómo los seres humanos trabajan y piensan puede convertirse en una manera muy útil de generar desbordamientos de búfer en la mente humana con el objeto de inyectar comandos.

En el mundo del hacking real, existe un método denominado fuzzing que se utiliza para encontrar errores que puedan ser sobrescritos, y ofrecer el control del software al hacker. Se lanzan grupos de datos aleatorios de diferentes longitudes a un programa para ver cuál de ellos hace que falle. Eso le da al hacker un camino para inyectar su código malicioso intermedio. Del mismo modo, debemos conocer cómo reacciona la mente humana a los distintos tipos de datos o grupos de datos. Por ejemplo, si te acercas a un edificio con dos grupos o hileras de puertas (unas exteriores y otras interiores) y sujetas las primeras puertas abiertas para que entre un completo extraño, ¿qué crees que hará él después? Pues lo más seguro es que pase el umbral y abra y sujete el segundo grupo de puertas para que tú pases. Otro ejemplo: si en una intersección de tráfico dejas pasar a un completo extraño antes que tú, lo más probable es que si se repite la situación más adelante y tú necesitas pasar, ese mismo desconocido te cederá el paso casi sin pensarlo.

Esquema del Fuzz Testing

¿Por qué ocurre esto? La razón tiene que ver con la conocida como ley de las expectativas, que establece que la gente, por lo general, cumple con sus expectativas, esto es, lo que se consigue en la vida no tiene que ser necesariamente lo que se quiere, sino lo que se espera que va a pasar o lo que se espera que pase. Las decisiones se hacen generalmente basándose en lo que la persona siente que el solicitante espera que haga. Bonita manera de comenzar a enviar “datos maliciosos” al “software” cerebral de la víctima.

Todo ello está basado en lo que se conoce como presuposición, un concepto que se explica perfectamente con el siguiente ejemplo. Imagina que enuncio la siguiente frase delante de ti: “Mi vecino conduce un coche verde”. La información que recibes es muy escasa y prácticamente inútil para ti. He hecho que des por sentado, o que presupongas, que no necesitas saber más. Sin embargo, si digo: “¿Sabes que mi vecino, Raúl, conduce siempre un Nissan Note de color verde?”, tu presupones muchas cosas más: que yo conozco muy bien a mi vecino, que sé su nombre, que se llama Raúl, que tiene permiso de conducir, que posee un Nissan Note y que es de color verde. Estoy haciendo que dispongas de mucha más información que antes, algo que me puede interesar que retengas en la cabeza previo pronunciamiento de la siguiente sentencia, la que de verdad me importa para extraer datos de ti.

Existen algunos trucos para poder inyectar comandos embebidos en el subconsciente de tu interlocutor, como el hecho de utilizar sentencias cortas (de tres o cuatro palabras), hacer uso de un leve énfasis en la pronunciación, ocultar esos comandos en frases normales o banales o utilizar el lenguaje facial y corporal para apoyar los comandos. Los buenos ingenieros sociales utilizan acciones de relleno, que son métodos de adicción de elementos que no interrumpen la ejecución, pero preparan una pequeña “pista de aterrizaje” que lleva al código malicioso. Son frases complementarias que ayudan a suavizar el código que se quiere insertar, tales como “Cuando usted…”, “Cómo se siente usted cuando…”, “Cualquier persona es capaz…” o “Como usted…”. Todas estas declaraciones crean una emoción o un pensamiento que permite inyectar código en el subconsciente humano.

Otras técnicas también ayudan, como el hecho de contar historias que enreden al objetivo, el uso de la negación como acto de psicología inversa, o forzar al oyente a usar su imaginación. En todo caso, recomiendo la lectura del libro de Christopher Hadnagy que comentaba al principio, así como de otros manuales y guías de ingeniería social para cualquiera que desee iniciarse en este noble y apasionante arte que es engañar a las personas adultas como si de niños se trataran. Pobres.