Rumbo al mundo del Internet de las Cosas

En varias ocasiones, Kaspersky ha investigado los problemas de seguridad de las tecnologías del Internet de las Cosas (IoT), como puede verse aquí y aquí. Nuestros expertos hasta se aseguraron un lugar este año en el desarrollo de la seguridad de los dispositivos prostéticos biomecánicos. Lo mismo aplica a la seguridad de los automóviles inteligentes: nuestras propias investigaciones han demostrado que hay muchos problemas por resolver, como dijimos aquí y aquí.

Este año hemos decidido continuar con nuestra tradición de realizar experimentos a pequeña escala para conocer la seguridad de los dispositivos que se conectan a Internet, pero esta vez nos enfocamos en la industria automotriz. El tema no pierde vigencia con los años y, como han revelado nuestras propias investigaciones en el campo, sigue habiendo problemas de seguridad en el mercado a medida que los vehículos se vuelven más inteligentes, más conectados y, por lo tanto, más expuestos. Pero también existe toda una industria de dispositivos adicionales para mejorar la experiencia de los conductores, desde escáneres de automóviles hasta dispositivos para personalizarlos. Este factor no se analizó por separado, así que conseguimos al azar varios dispositivos diferentes que se conectan a los automóviles y revisamos sus configuraciones de seguridad. Aunque apenas puede considerarse una investigación, este ejercicio nos permitió dar un primer vistazo a sus problemas de seguridad.

Analizamos los siguientes dispositivos: un par de escáneres de automóviles, una cámara para el tablero de mandos, un localizador GPS, un sistema de alarmas inteligente y un sistema de control de presión y temperatura.

Herramienta de escaneo mediante un adaptador OBD: exposición garantizada

El mercado de diagnósticos para automóviles civiles está inundado de todo tipo de dispositivos—inalámbricos y de conexión directa, grandes y pequeños— que funcionan con el conector de diagnósticos OBD2. Estos son aparatos que se conectan al vehículo y comparten datos dinámicos sobre el estado del vehículo. Algunos de estos dispositivos son autónomos, otros dependen de computadoras o teléfonos móviles. Ofrecen muchas opciones de registro y análisis: entre los datos que recopilan están la velocidad del motor, la temperatura, la turbo-carga, la presión del aceite, etc.

También hay aplicaciones que además de leer esta información permiten programar el “cerebro” del automóvil para, por ejemplo, reiniciar la luz de “revisar el motor”. Usar estas aplicaciones para modificar la operación predeterminada del vehículo puede traer riesgos significativos. Además de que puede haber errores operativos que dañen el automóvil, existe un riesgo de que un intruso intercepte y tome control del dispositivo. El peligro se reduce si el dispositivo se conecta por cable, pero si es inalámbrico —y los datos del puerto de diagnóstico se transmiten mediante Bluetooth o WiFi— los riesgos de que sea interceptado aumentan. Por lo tanto, nos interesa saber con cuánto éxito se ocuparon de la seguridad los fabricantes de estos dispositivos.

El dispositivo que analizamos fue desarrollado por un fabricante alemán y publicitado bajo la marca de un reconocido fabricante de automóviles. Por razones de seguridad, no revelaremos su nombre.

El dispositivo se posiciona como un recopilador de datos de carreras que puede grabar un video cuando el auto esté en la pista y superponerle datos telemétricos como la velocidad, información del motor, aceleración, etc.

El dispositivo opera en conjunto con un smartphone iOS o Android que se conecta mediante Bluetooth. Todos los datos se muestran en la pantalla del smartphone. Entonces… aquí vamos. Como queríamos saber si el uso de estos dispositivos representaba algún riesgo para el usuario, la conexión por Bluetooth es un buen lugar para empezar.

Nuestro análisis inicial mostró que el dispositivo se negaba por completo a operar con iPhone: no lo detectaba. Puede que el problema haya sido el firmware, pero eso sigue siendo un misterio. Por lo tanto, todos los experimentos que presentamos a continuación se realizaron con un dispositivo Android.

Para comenzar a trabajar con el dispositivo, primero se debe pasar por un procedimiento de vinculación. Para ello no se requieren contraseñas, cualquiera puede conectarse en cualquier momento. Eso no es bueno.

Pero cuando el dispositivo está conectado, el potencial intruso necesitaría el número de serie para conectar su propio dispositivo al adaptador. El número está impreso en el aparato, por lo que necesitaría tener acceso físico a él. ¿No es así?

En líneas generales, ese es el panorama. El número de serie tiene un formato similar a “000780d9b826”. Y si se lo escribe como “00:07:80:d9:b8:26”, se obtiene la dirección MAC del adaptador Bluetooth que se usó. Entonces, en esencia, se puede descubrir el número de serie al hacer un escaneo de conexiones Bluetooth en los alrededores del adaptador. Y esto es lo más gracioso: este número de serie / dirección MAC también es la contraseña del adaptador.

Es decir, el dispositivo está difundiendo información en toda el área circundante y, de acuerdo con los estándares de Bluetooth, publicando la dirección MAC del dispositivo al público junto con su llave de acceso. Esto significa que cualquier persona puede acceder al adaptador con sólo instalar un simple escáner de Bluetooth en un smartphone y buscar un dispositivo llamado OBD STICK dentro de su rango. Eso es todo.

Las malas noticias para el hacker son que la aplicación en sí misma no le permite tomar control del automóvil, sólo analizar sus datos. ¿Qué pasa si establecemos una conexión al adaptador desde otra aplicación? Intentamos hacerlo con un par de aplicaciones diferentes disponibles en Google Play.

Según los desarrolladores de las aplicaciones, hay una larga lista de funciones que pueden alterar los datos de las dinámicas de manejo de un automóvil. No pudimos poner esto a prueba porque, aunque la aplicación se conecta con el dispositivo, no puede leer los datos del protocolo CAN bus. La aplicación está programada para interactuar con adaptadores OBD mediante un protocolo específico, mientras que los dispositivos examinados tienen su propio protocolo, diferente.

Los adaptadores de este tipo suelen estar construidos a partir del chip ELM327, el microcontrolador más popular del mercado. Su principal función es procesar las señales del protocolo CAN bus y ofrecer información al consumidor mediante una interfaz RS-232, como un adaptador Bluetooth (o USB), si la conexión no es inalámbrica. La interfaz transmitirá datos al smartphone mediante una señal de radio, y el teléfono la pasa a la aplicación. ¿Cómo procesar las señales, cómo recibirlas del CAN bus o transmitirlas allí y en qué forma se transmiten al consumidor?, son decisiones que dependen del firmware y están grabadas en el ROM del microcontrolador. En el dispositivo examinado se usó un microcontrolador AT90CAN128-16MU y un firmware completamente diferentes.

Por lo tanto, la pregunta que queremos hacernos es si es posible modificar el firmware del controlador para añadir nuevas funcionalidades. Descubrimos que existe una opción para actualizar el firmware del adaptador en la aplicación. Nuestra investigación sobre el código de la aplicación reveló que:

1. La aplicación puede descargar firmware desde el sitio web del desarrollador mediante una conexión HTTP insegura.
2. El firmware viene con la aplicación.

En resumidas cuentas, podemos conseguir el firmware para luego analizarlo y modificarlo. ¿Pero logramos conseguimos? Por desgracia no, porque el firmware está cifrado. Esto no nos sorprende y es una decisión inteligente del vendedor, ya que protege la parte más delicada de la operación de su dispositivo: el protocolo de intercambio de datos entre el automóvil y el adaptador. Es por eso que sólo hay dos maneras de conseguir el firmware: pidiéndoselo al vendedor o invirtiendo mucho tiempo y esfuerzo en analizar las señales del vehículo. Aunque puede hacerse, está fuera del alcance de nuestro experimento.

En conclusión, podemos decir que a pesar que existen algunas fallas menores, no hay mucho que un usuario malicioso pueda hacer con el dispositivo, todo gracias al cifrado de firmware. Aun así, cualquiera puede acceder al dispositivo y ver los datos dinámicos del vehículo. En teoría, también es posible que un usuario malicioso muy perseverante pueda conseguir el acceso físico al firmware y reprogramarlo.

Para que el dispositivo sea más seguro, recomendaríamos equiparlo con una llave de acceso única y usarla para hacer la conexión a Bluetooth. De esta manera se evitaría que el tráfico de Bluetooth pueda ser interceptado. Y una recomendación para todos aquellos que se han convertido en orgullosos dueños de este dispositivo: úsenlo sólo en la pista y no olviden desconectarlo del puerto OBD2 después de la carrera.

Sistema de control de la presión y temperatura de los neumáticos: un huracán sobre ruedas

El otro dispositivo que analizamos era un paquete de herramientas para supervisar la presión y temperatura del vehículo. Incluye cuatro sensores instalados directamente en las llantas del automóvil, una pantalla ubicada en el interior del auto y una unidad de control. Los sensores transmiten una señal de radio a la unidad, que pasa la información a la pantalla. La pantalla muestra la siguiente información:

• la presión actual de los neumáticos;
• la temperatura de las llantas.

El usuario puede cambiar la unidad de temperatura de Celsius a Fahrenheit, elegir si prefiere ver la presión en libras de fuerza por pulgada cuadrada, Bar o Pascal y conectar un nuevo sensor cuando uno de ellos se dañe. Si la presión baja a un punto crítico, la unidad de control emite un chirrido fuerte. Lo mismo ocurre si la presión o la temperatura en las llantas llegan a un nivel muy alto. Decidimos probar si se puede simular un descenso en la temperatura o un sobrecalentamiento de las llantas para obligar al conductor a detenerse.

Como mencionamos, los sensores pasan información a la unidad de control mediante una señal de radio en una frecuencia permitida para el uso civil. Para interceptarla, basta con usar cualquier receptor RTL-SDR que se consigue por unos cuantos dólares. Pero estos dispositivos sólo son capaces de recibir señales, no pueden transmitirlas. Para ello se necesita un dispositivo SDR completo con capacidades tanto de recepción como de transmisión. Decidimos usar uno de ellos para nuestra prueba de seguridad.

Cuando encendimos el sistema, no mostró ninguna señal de actividad, excepto que indicaba que no se había establecido la conexión con los sensores.

El sistema funcionó por diez minutos de esa manera, después comenzó a mostrar una ausencia de comunicación con los sensores de presión. Decidimos orientar nuestro receptor hacia la frecuencia requerida.

Nada. Ni los sensores ni el sistema mostraron ninguna señal de actividad. Hay tres razones posibles para ello: los sensores no estaban cargados, el sistema estaba basado en un giroscopio y los sensores sólo funcionaban cuando las ruedas giraban o los sensores se activaban cuando la presión era mayor que la del ambiente. Para averiguar la razón exacta, tuvimos que experimentar con los sensores.

La tercera razón terminó siendo la verdadera: usamos una jeringa para aumentar la presión en los sensores, que empezaron a mostrar señales de actividad.

Las señales interceptadas nos dieron la frecuencia específica con la que operaba el sistema. Usando esa información, grabamos las señales con un receptor. Los sensores analizan la presión y temperatura de los neumáticos, cifran esa información en bytes y la transmiten mediante un modulador en forma de señales de radio. Analizamos esta información mediante un programa especial que normalmente muestra señales grabadas. Lo que hicimos fue, en esencia, recolectar las señales moduladas y decodificarlas de vuelta en bytes.

Aquí está. Cuando los ampliamos, los registros visuales se parecen mucho a una modulación por desplazamiento de frecuencia (una técnica de modulación en la que la frecuencia de la señal del portador varía según los cambios en las señales digitales):

Esta etapa nos permitió reconocer los bits que se transmitieron, ya que los trazos superiores e inferiores son básicamente “1” y “0”que indican la presencia o ausencia de señal. Por lo tanto, la señal visual que se registró puede presentarse en forma de bits de la siguiente manera:

Ahora necesitamos encontrar los parámetros de la transmisión de señales. El programa indica que la frecuencia de símbolos es 19400 Bd.:

Asumimos que el sistema usaba el código Manchester, que es el más común. Es básicamente un acuerdo de cómo cifrar una señal de radio de forma digital, una línea de código en la que el cifrado de cada bit de datos es bajo y después alto, o alto y después bajo.

Existen dos formas de cifrado: cuando 0 se expresa mediante una transición que va de bajo a alto y 1, que se expresa mediante una transición de alto a bajo (convención Thomas), y cuando ocurre el inverso (convención IEEE 802.3). Manipulamos la jeringa para generar mayor presión en los sensores y así dar un paso más con nuestro análisis. Para nuestra propia conveniencia, convertimos los datos registrados a un sistema posicional de numeración hexadecimal. Las señales se veían así:

Los séptimos, octavos y décimos bytes, marcados en rojo, cambiaban cuando se alteraban los sensores. Para hacer una comprobación preliminar, convertimos algunos bytes al sistema decimal, pero las cifras eran demasiado altas para suponer que representaban un nivel de presión.

El manual del sistema indicaba que la presión máxima permitida era de 6 bares. Una jeringa promedio produce alrededor de 2,2 bares de presión. Pero nuestros cálculos habían revelado que el décimo byte (62) equivalía a 2,254 en la convención de Thomas. Esto se acercaba bastante, así que llegamos a la conclusión de que el séptimo byte representaba los datos de presión. Esto también nos ayudó a identificar la convención usada en el sistema de codificación.

Después de recolectar más y más señales, develamos varias regularidades en el registro que nos ayudaron a suponer con cierto grado de certeza lo que cada byte significaba.

00	rowspan=”2″Preámbulo
01
A5	Byte de sincronización
03	rowspan=”3″Número de serie de los sensores
B4
F7
62	Presión
4E	???
04	???
79	Checksum

Notamos que el octavo byte cambió muy poco y por un valor mínimo. Como estábamos analizando el sensor dentro de una habitación con temperatura estable, era lógico pensar que ese byte representaba la temperatura. Como comprendíamos la lógica del cifrado, podíamos poner a prueba nuestra hipótesis. Según el manual del sistema, la temperatura operativa se encontraba entre los -40 y +125 grados Celsius.

Pero asumimos que el sistema usaba la escala Kelvin, por lo que cambiamos nuestro sistema métrico a Kelvins porque no usa “0”. Nuestros cálculos mostraban que el octavo byte (4E) hacía referencia a 37 grados Celsius, lo que parecía creíble. Por ende, habíamos identificado los significados de tres columnas de bytes: la presión de los neumáticos, la temperatura y el número de serie.

Con eso en mente, preparamos cuatro paquetes de datos de bytes y el transmisor:

La columna roja, por ejemplo, indica que había 2 bares de presión y la azul que la temperatura era de 24 grados Celsius. ¡Y funcionó! Ahora podíamos penetrar en el sistema. Esta vez cambiamos los valores de una de las columnas para simular la temperatura de la rueda derecha trasera.

Eso funcionó. ¡la unidad de control alertó sobre un sobrecalentamiento de cien grados Celsius!

¿Qué podría hacer un hacker con estos conocimientos?

En primer lugar, para que su ataque tenga éxito, debe conocer el número de serie único de cada uno de los neumáticos. Puede conseguir esta información tal y como lo hicimos nosotros: analizando la señal que se transmitía. Es decir, el hacker puede acercarse al vehículo con un receptor, presionarlo contra las llantas y decodificar la señal. Después de hacerlo estaría en condiciones de enviar paquetes de datos falsos. Pero sería una tarea difícil: el hacker necesitaría transmitir una señal desde el automóvil con una antena dirigida al vehículo de la víctima de forma constante mientras maneja, ya que si la señal se pierde el receptor del auto dejaría de aceptar la de los sensores originales y de alertar sobre los problemas.

Por lo tanto, aunque nuestra investigación indicó que existe una forma de alterar el sistema que compramos, el ataque que simulamos requiere demasiados recursos. Hay otras maneras más fáciles y baratas de obligar a un conductor a bajar del auto:

Pero en general, se puede decir que el dispositivo es vulnerable porque es posible interceptar y descifrar su señal de radio. Sin embargo, la funcionalidad de este dispositivo es tan limitada que sus dueños no deben preocuparse.

Otro adaptador: ¿y si no es inalámbrico?

Como ya mencionamos, existen muchos dispositivos que pueden comunicarse con los componentes inteligentes de un vehículo por medio de un conector OBD2. Las debilidades de las conexiones inalámbricas están demostradas, así que ahora decidimos examinar a sus homólogos con cables para tener diversidad en los estudios. El dispositivo que compramos resultó ser un lector de códigos de error.

También se conecta al automóvil mediante un sistema OBD que incluye varios canales físicos de comunicación con el interior del vehículo. Pero, en realidad, un lector de códigos de error sólo necesita funcionar con un canal, el bus CAN. Aunque en nuestro caso esta interfaz sólo se usó para leer códigos de error, su verdadera función depende del diseño del vehículo y puede ser mucho más amplia, incluso llegando a comunicarse con las actualizaciones de firmware de las Unidades de Control Electrónicas (ECUs).

Decidimos echarle un vistazo más profundo al lector para analizar la manera en la que se comunica con el vehículo.

La estrategia de comunicación de nuestro dispositivo es bastante simple. Además del sistema OBD, tiene sólo un interfaz USB que se usa para actualizaciones de firmware y comunicaciones con una computadora.

El vendedor se esforzó mucho por evitar que el firmware sea analizado. Para comenzar, los archivos del último firmware no pueden descargarse de Internet mediante un enlace directo. El proceso de actualización de firmware se realiza mediante una herramienta de software especial.

No encontramos nada que se asemeje a un firmware en la distribución del software, por lo que asumimos que se descargaba de Internet. Analizamos el tráfico de redes que el software enviaba durante el proceso de actualización del firmware y descubrimos que el firmware se transfería por medio de solicitudes HTTP regulares. Esto significa que se puede descargar el último firmware de un navegador web copiando la solicitud que emplea la herramienta. Una vez descargado, el firmware se envía al dispositivo mediante un protocolo propietario que se implementa mediante la conexión USB. Investigamos el protocolo y determinamos el formato de todos los comandos utilizados para escribir código o datos a una dirección específica. También escribimos un script que se comunicaba con el dispositivo mediante este protocolo.

Y aquí viene la segunda medida de protección del vendedor: el cifrado. El firmware constan de dos partes, guardadas en dos archivos separados, ambos cifrados por separado. Esta estructura se debe al diseño de hardware del dispositivo.

Los principales componentes del dispositivo son un microcontrolador, equipado con una cantidad relativamente pequeña de memoria flash interna para el almacenamiento del firmware, y un chip flash externo y separado, que almacena cantidades más grandes de datos. Ambos archivos contienen datos para el almacenamiento interno y externo, respectivamente.

Como no podíamos analizar el firmware descargado de Internet, intentamos descargarlo del dispositivo después de una actualización, con la esperanza de que se haya almacenado sin haber sido cifrado. No logramos conseguir la parte del firmware que se almacenó en el flash interno, ya que el microcontrolador tenía bloqueada su interfaz de depuración.

Pero tuvimos un éxito parcial cuando logramos volcar una imagen del flash externo. La imagen no tenía ningún código, sólo la configuración del dispositivo, pero todos los datos del chip de flash se almacenaron sin cifrado alguno. Asumimos que, como el dispositivo descifraba datos flash externos durante la actualización de firmware, también podría descifrar los datos del flash interno. Y que tanto el algoritmo de descifrado como su llave podrían servir para ambas partes del firmware. Intentamos escribir la parte interna del firmware al flash externo y resultó que estábamos en lo correcto: encontramos el código de descifrado en el flash externo.

También descubrimos que el flash interno sólo se había escrito de forma parcial durante la actualización. Algunos de los códigos se mantuvieron iguales, al menos durante una actualización de la versión del firmware que estábamos analizando. Pero todavía era posible investigar todo el código incluido en el paquete de actualizaciones.

Por lo tanto, conseguimos la parte descifrada y pudimos escribirla en el chip externo con la ayuda de un script previamente escrito que implementó el protocolo de software del fabricante. En teoría, esto nos daría un modo de alterar el dispositivo añadiendo códigos arbitrarios al chip mediante el acceso físico que nos da el protocolo USB.

Este protocolo nos permitiría reprogramar el dispositivo, obligándolo a escribir partes de su firmware en el chip externo. Al tener disponible la imagen completa, podríamos buscar varias vulnerabilidades. El problema es que el dispositivo tiene tan poca memoria que lo único que puede realizar es la lectura y registro de errores.

Por lo que la situación es clara y similar a la de los teléfonos y smartphones: una conectividad simple y la economía de funcionalidades implica menos vulnerabilidades. Pero aun así, nunca está de más que los proveedores cifren todas las partes cruciales de sus datos, como su firmware, aunque su producto no sea inalámbrico.

Sistemas de alarma inteligentes para automóviles: la inseguridad de la movilidad

Otro dispositivo que analizamos proviene de un conocido fabricante ruso que fabrica sistemas de seguridad para automóviles. Este dispositivo en particular es un sistema de seguridad para automóviles que puede abrir las puertas y encender el motor. Por supuesto, que un atacante tome el control de este dispositivo sería un gran riesgo para el futuro del automóvil. Nos llamó la atención que el fabricante garantizara que el vehículo es inmune a ataques de intrusos si el sistema está instalado. Veamos si está en lo cierto.

El sistema es en esencia una unidad de control instalada dentro del automóvil en una sección de difícil acceso. Se lo suele instalar en las tiendas de reparación de vehículos. Después debe vincularse al smartphone del dueño. Nuestros análisis preliminares mostraron que hay tres maneras de controlar el sistema:

• Una de ellas es con llaveros, y el paquete incluye dos: uno simple que permite abrir las puertas y el maletero, y otro más avanzado que muestra información del estado;
• Con discreción, mediante el smartphone vinculado;
• Mediante Bluetooth, desde un smartphone que funciona con Android.

Los llaveros interactúan con el sistema de alarmas a una frecuencia de 868 megahertz. No se puede interceptar nada porque la información está cifrada y sólo veríamos un montón de datos inútiles que podríamos tardar años en descifrar. Creemos que es poco probable que un usuario malicioso apunte en esta dirección. Nuestras búsquedas en la Darknet tampoco dieron muchos frutos: no encontramos ningún ataque que se haya desarrollado para este vector. Por lo tanto, el fabricante ha implementado un excelente producto dentro del primer vector de ataque.

La otra forma de atacar el sistema es infectando el teléfono vinculado. Decidimos poner a prueba este vector.

Al iniciarse, la aplicación no solicita ni un nombre de usuario ni una contraseña. La interacción entre el teléfono móvil y el sistema de seguridad se realiza de forma directa, sin ningún tipo de patrón de desbloqueo. Esto es algo muy malo: significa que si un hacker roba un teléfono desbloqueado también puede robar el auto que tiene vinculado sólo pidiéndole a la aplicación que abra la puerta. Pero fuimos un paso más allá.

Existen muchas formas de atacar un teléfono Android e interferir con su funcionamiento. Decidimos probar explotando el servicio de Accesibilidad de Android. Este es un servicio para personas de necesidades especiales que permite administrar todas las otras aplicaciones instaladas, como la gestión de voz, mediante el teclado del teléfono.

El servicio nos permitió encontrar el componente requerido en la aplicación de seguridad: el botón “Abrir puerta” con ACTION_CLICK. Pero no podíamos pulsar en él porque la aplicación está diseñada para ignorar los toques cortos. Para destrabar las puertas, el usuario debe mantener presionado el botón por unos cuantos segundos. La presión en el botón se procesa con un algoritmo especial y, por supuesto, no hay ninguna Interfaz de Programación de Aplicaciones que nos permita ajustar el tiempo de un toque virtual en Android. Esto nos obligó a buscar otro modo de presionar el botón.

¡Y lo encontramos! La aplicación respondió con éxito a los desplazamientos del botón hacia la izquierda y derecha. Escribimos un pequeño programa que movía un dedo virtual sobre el botón por dos segundos, lo que desbloqueó el sistema. Tuvimos que hacer muchos intentos, pero lo logramos.

Después de eso nos concentramos en la conexión Bluetooth, que también se veía prometedora. El sistema interactuaba por medio de Bluetooth Low Energy (BLE), por lo que teníamos ante nosotros una tecnología de última generación. Pero algo nos facilitaba el trabajo: la comunidad de hackers llevaba años buscando formas de interceptar los datos BLE.

Con eso en mente, preparamos una cabina usando una laptop con interfaz BLE y conseguimos otro adaptador USB BLE: necesitábamos dos interfaces para implementar un ataque de intermediario (MITM). Intentamos escanear el dispositivo al que apuntábamos, el sistema de alarmas, para conseguir los datos que necesitábamos y crear una copia de ellos en las interfaces BLE de la computadora. Como es un sistema BLE, la alarma no transmite con frecuencia. Este es un mecanismo de ahorro de batería, muy útil para el conductor. Esto nos permitiría generar señales de esta copia falsa con frecuencia, incitando al teléfono a conectarse a ellas en vez de a las originales. Si nuestro ataque tenía éxito, un interfaz BLE en nuestra estación MITM se comunicaría con el sistema de seguridad haciéndose pasar por el teléfono, mientras que la segunda interfaz en la computadora se comunicaría con el teléfono real autorizado. Por lo tanto, estaríamos interceptando el tráfico y hasta generando tráfico adicional, por ejemplo, para ordenar al sistema que abra la puerta.

Es decir, contaríamos con un sistema de alarmas funcional que emite señales mediante BLE y está vinculado al smartphone original y a una estación MITM. Ahora necesitábamos crear una copia falsa del sistema y obligar al teléfono a conectarse a él. Se suponía que nuestra cabina MITM debía detectar al sistema de seguridad cuando ingresábamos la dirección MAC correcta en la interfaz Bluetooth del teléfono original. Y es aquí donde fracasamos. El sistema se negó por completo a darnos la información requerida para crear una copia falsa. Cambiamos la dirección MAC y la interfaz, pero nada funcionó: el sistema siguió conectándose sólo al teléfono al que estaba vinculado originalmente.

Tal parece que el sistema sólo puede conectarse a un teléfono y que los canales de comunicación entre el sistema de alarmas y el teléfono estaba cifrado. También parece que para establecer una buena comunicación entre el teléfono y el sistema, el usuario debe entrar al sistema en modo de programación. Después de hacerlo, el sistema espera una solicitud de conexión del teléfono. El procedimiento de vinculación se realizó de una forma complicada: como dijimos antes, se lo hizo en una estación de servicio. La unidad de control estaba oculta adentro del auto y protegida por un PIN de activación único. El proceso de vinculación en sí mismo también está cifrado: el sistema y el teléfono intercambian llaves de cifrado, estableciendo una sesión de comunicación segura después de la cual el sistema se niega a comunicarse con cualquier otro teléfono que no sea el que se autorizó originalmente.

Por lo tanto, uno no puede agarrar y conectarse al sistema desde cualquier dispositivo, y esto es lo que llamamos “un producto fabricado con la seguridad en mente”. Por ende, el fabricante ha implementado un excelente producto también dentro del segundo vector de ataque.

Tomando en cuenta todo esto, las posibilidades de que un ataque sea exitoso serían las siguientes: en primer lugar, el cibercriminal necesitaría el número de teléfono del conductor. Existen muchas maneras de conseguirlo: por ejemplo, muchos conductores en Rusia dejan sus números de teléfono en el parabrisa para casos de emergencia. A continuación se debe infectar el teléfono. Esto podría hacerse mediante ataques dirigidos específicamente al conductor. Si son exitosos, el teléfono de la víctima se infectará con un troyano que tiene permiso para utilizar los servicios de accesibilidad. Esto le permitiría rastrear a la víctima y enviar comandos a las aplicaciones de su teléfono para que abran las puertas de su auto. Aunque el rango de Bluetooth no es grande, es posible en teoría que un hacker abra la puerta e inicie el motor del automóvil si la víctima está cerca del vehículo.

Por lo tanto, el resultado principal de esta investigación es simple: el mayor problema de seguridad es el smartphone, que puede atacarse de varias maneras. Alguien podría robarlo cuando esté desbloqueado y pedirle que abra la puerta por medio de la aplicación original que no pide ninguna contraseña. También podría programar una aplicación que ordene al sistema que abra la puerta o ataque las aplicaciones originales. Estas aplicaciones son vulnerables a casi cualquier forma de ataque existente, entre ellos los ataques mediante los servicios de Accesibilidad de Android. También se podría infectar el teléfono mediante SMS o spam malicioso, o publicando una aplicación infectada con un troyano en Google Play. En tal caso, el troyano puede esconderse y esperar el momento justo para desbloquear el teléfono de forma discreta, ejecutar la aplicación y pedirle que abra la puerta. El hacker debe estar cerca del auto y del teléfono móvil de la víctima. Aunque el rango de Bluetooth no es lo suficientemente amplio como para que se sigan todos los pasos necesarios para tomar control del automóvil, la posibilidad de abrir puertas es un peligro al que vale la pena prestarle atención. Pero este problema de seguridad no es responsabilidad del fabricante de sistemas de alarma.

¿Qué puede hacerse para corregir esto? En primer lugar, no es buena idea gestionar este tipo de sistemas de seguridad por teléfono. Pero si este es el caso, es imprescindible que los fabricantes implementen patrones de desbloqueo para las aplicaciones de alarmas de seguridad, tal como lo hacen las aplicaciones bancarias. En general, es difícil contrarrestar los ataques a smartphones Android, pero la tarea del hacker puede ser muy complicada. Por ejemplo, puede lograrse mediante los servicios de accesibilidad, ofuscando los títulos de los componentes de aplicaciones. También es razonable pedir la autorización del usuario. Ninguna de estas medidas detendrá a los atacantes, pero sí les dificultará mucho el trabajo. En cuanto a los usuarios, es necesario que todos sean muy cautelosos en temas de seguridad de teléfonos móviles. Y no pasen por alto las soluciones de seguridad.

Rastreador GPS para automóviles: ¿será que El Gran Hermano te está observando?

Otro dispositivo que revisamos fue el rastreador GPS para automóviles con protección impermeable y sujeción magnética. Tiene muchas posibilidades de uso: desde controlar los movimientos de los empleados en sus vehículos personales hasta rastrear el envío de paquetes y encomiendas y proteger los equipos alquilados.

El paquete estándar contiene una tarjeta SIM con un plan especial. Pero también puedes utilizar tu propia SIM. Lo principal es que acepte GPRS y SMS. El segundo duplica los canales GPRS en situaciones en las que no hay señal GPRS y sirve para reducir los costos de roaming.

Las coordenadas GPS, los acelerómetros y otros datos de sensores se transmiten mediante el canal GSM/GPRS al servidor del proveedor. Aunque no podemos hacer mucho con el rastreador en sí mismo, hay mucho lugar para actividades maliciosas en el servidor del sistema. Nos dedicamos a evaluar las posibilidades de ataque a los servidores web del rastreador. La motivación para los hackers es simple: al tener acceso a la cuenta corporativa, un agente malicioso de la competencia podría rastrear las logísticas del empleado, sus balances bancarios y datos personales.

El análisis preliminar mostró que el sistema utiliza una plataforma de supervisión GPS muy conocida, y una plataforma de telemática para realizar sus operaciones. Pero no encontramos ninguna vulnerabilidad en eso.

Entonces decidimos investigar el sitio web oficial del servicio. Descubrimos que estaba basado en WordPress v4.9.9. No se conoce públicamente ninguna vulnerabilidad en esta versión.

Dos directorios de sitios web llamaron nuestra atención: los formularios de inicio del administrador y los del cliente. Ambos podrían atacarse con fuerza bruta, en especial si se toma en cuenta que el segundo no está protegido por ningún sistema de autentificación de dos factores.

Si la infección se realiza mediante el segundo vector de ataque, el usuario malicioso podría, en teoría, acceder a la base del cliente que contiene una cantidad de datos privados como, entre otros, los patrones de viaje, datos financieros, contactos y nombres. Y si se lo hace de la otra manera, incluirían los datos financieros, historial de transacciones y documentos de la cuenta.

Por lo tanto, en teoría, y aún con conectividad limitada, el rastreador en cuestión podría ser explotado por una simple falta de vigilancia al asegurar los servicios web. Sin embargo, las posibilidades de que esto suceda son tan bajas que no hay verdaderas razones de preocuparse.

Cámara para automóvil inteligente controlada mediante aplicaciones: ¿le has echado un ojo a la seguridad de tu auto?

Gracias a las tecnologías modernas, podemos usar cámaras para registrar lo que está pasando alrededor del automóvil mientras viajamos, lo que nos ayuda a tener evidencias a mano en caso de accidentes. Como también sucede con otros dispositivos, cada vez hay más y más cámaras para auto, conocidas como cámaras de automóvil, en el mercado. Es por esto que decidimos analizar una de ellas para comprender cuáles son sus características útiles y sus riesgos de seguridad como parte de este mundo del Internet de las cosas.

Seleccionamos una de las cámaras para automóviles inteligentes más populares del mercado y al principio desconfiábamos de sus estándares de seguridad. Según la documentación que se nos presentó hay dos aplicaciones oficiales para Android e iOS disponibles, así como una interfaz WiFi que media la comunicación entre el dispositivo y el smartphone o tableta. Habíamos visto muchos otros casos en los que este tipo de organización generaba desastres en la seguridad de los dispositivos IoT.

Comenzaremos con los análisis preliminares. Las principales funciones del dispositivo son:

• Grabar un video gran angular (130°) en calidad 1080 HD cuando el auto está encendido y almacenarlos en una memoria flash microSD que se sobreescribe de forma cíclica. El tamaño de los datos que se almacenan depende de la tarjeta.
• Grabar videos de emergencia cuando un sensor de gravedad especial, o G-Sensor, detecta una aceleración sospechosa. Los videos se almacenan en una carpeta separada para facilitar su búsqueda y evitar que se los sobreescriba por error. Un modelo más avanzado de este dispositivo puede grabar videos de emergencia mientras el auto está estacionado y el motor apagado.
• Activar el modo de visión nocturna para ajustar la calidad de los videos grabados durante la noche;
• Conectar a un dispositivo Android o iOS que tenga instalada una aplicación especial de administración;
• Comprender varios comandos de voz del usuario.

Recibimos una grata sorpresa con los resultados de la evaluación de seguridad tanto del dispositivo como de sus aplicaciones oficiales. El punto principal es que la única opción que tiene un intruso de tomar el control del dispositivo para, por ejemplo, robar los videos grabados, es conectarse al punto de acceso WiFi de la cámara cuando el smartphone del usuario haya sido infectado. Después de conectarse, el atacante puede usar una de las aplicaciones oficiales para conseguir todos los datos o conectarse al servidor de la cámara en la red local. Esto le permite sacar ventaja de las muchas características escondidas que no están listadas en las aplicaciones para, por ejemplo, inhabilitar el dispositivo.

Los desarrolladores tienen cubierto el proceso de conexión WiFi. Si quieres conectar un nuevo dispositivo a la cámara, necesitas ingresar la contraseña y además apretar un botón especial en la misma cámara. Esto hace que al atacante le sea imposible conectarse al dispositivo sin tener acceso físico a él, lo que de todos modos no tendría sentido porque si tuviese acceso físico podría robar la tarjeta microSD con todos los datos que contiene. También se puede cambiar la contraseña del hotspot en la aplicación y se ofrece al usuario cambiar la contraseña predeterminada al establecer la primera conexión.

En resumen, podemos ver que los fabricantes del dispositivo y los desarrolladores de software están comenzando a prestar más atención a los problemas de seguridad a medida de que van produciendo cada vez más dispositivos “inteligentes” del Internet de las cosas. Si un usuario consciente utiliza esta cámara y considera cambiar la contraseña predeterminada en su primera conexión, todos los datos serían impenetrables para atacantes externos.

Conclusiones

Después de todo este recorrido sólo nos queda preguntarnos: ¿qué hemos aprendido? Tal vez aprendimos que vale la pena seguir realizando estas pequeñas pruebas. Los principales resultados de nuestros experimentos con dispositivos inteligentes relacionados a la industria automotriz demostraron que su grado de seguridad es medianamente adecuado si pasamos por alto los pequeños problemas. Esto se debe en parte a la limitada funcionalidad de los dispositivos y a que no hay consecuencias serias en caso de que el ataque sea exitoso, pero también gracias a las precauciones que tomaron los proveedores.

Aun así, aunque seamos testigos del progreso de la industria hacia un futuro cada vez más conectado e inteligentemente brillante, no debemos bajar la guardia: la regla de oro es que mientras más inteligente es un objeto, más consideraciones de seguridad deben tomarse al desarrollarlo y administrar sus parches. Después de todo, una vulnerabilidad sin parchar o la falta de cuidado en una sola de las etapas del desarrollo o uso de los productos puede hacer que un atacante logre tomar control o espiar un automóvil con éxito.

Teniendo eso y nuestras soñadas vacaciones en mente, nos gustaría compartir los siguientes consejos para elegir los dispositivos IoT para automóviles inteligentes:

1. Cuando elija la parte del vehículo que quiera volver más inteligente, considera los riesgos de seguridad. Piense dos veces si algo tiene que ver con la telemetría del automóvil o el acceso a su “cerebro”.
2. Antes de comprar un dispositivo, busque en Internet noticias de vulnerabilidades que se hayan encontrado en él. Es posible que el dispositivo que quiere a comprar ya haya sido examinado por investigadores de seguridad y se pueda saber si los problemas que se encontraron han sido parchados.
3. No siempre es buena idea comprar los productos más nuevos del mercado. Además de las fallas estándar que tienen los productos nuevos, los dispositivos que acaban de lanzarse pueden contener problemas de seguridad que aún no han sido descubiertos por los investigadores. Lo más sensato es comprar productos que ya hayan recibido varias actualizaciones.
4. Siempre considere la seguridad de la “dimensión móvil” del dispositivo, en especial si utiliza dispositivos Android: las aplicaciones suelen ser más útiles y facilitar tu vida, pero una vez que el smartphone se infecta con malware muchas cosas pueden salir mal.

Para superar los retos de la seguridad informática de los dispositivos inteligentes, Kaspersky está invirtiendo en KasperskyOS, un sistema operativo seguro muy usado en la fabricación de harware y software personalizados. El sistema puede usarse en una amplia variedad de campos: en dispositivos móviles y PCs, en dispositivos del Internet de las cosas, sistemas de energía inteligentes, sistemas industriales, telecomunicaciones y sistemas de transporte. Kaspersky puede ver las oportunidades de desarrollar aún más KasperskyOS para que satisfaga las necesidades de nuestros clientes y garantice los más altos niveles de seguridad en todos estos campos, incluyendo el automotriz. Se puede encontrar más información aquí.

En cuanto a los proveedores de dispositivos IoT, la principal recomendación es muy simple: que trabajen en colaboración con compañías de seguridad y con la comunidad cuando desarrollen nuevos dispositivos y actualicen los viejos.