Servicios Digitales Financieros: Una mirada a la seguridad de los Mobile Financial Services.

Nos encontramos ante un nuevo paradigma o nicho de mercado, donde los tradicionales servicios financieros, están migrando hacia servicios dependientes cien por ciento de las comunicaciones. Las autoridades y grandes holdings financieros están empujando fuertemente a la sociedad y empresas a hacer uso de ellos, pues les conviene en todo sentido.

Figura 1: Servicios Digitales Financieros: Una mirada a la

seguridad de los Mobile Financial Services.

El crecimiento de estos DFS, del inglés “Digital Financial Services”, es vertiginoso y por tanto necesitamos construir esto sobre sistemas seguros para dar confianza a los usuarios, protección a los bancos y medios de pago, y estabilidad al nuevo mercado.

El mundo Fintech

Cuando se utiliza el término “Fintech” se hace de una manera amplia abarcando al uso de aplicaciones digitales, servicios, software y tecnología por parte de empresas y startups centradas en la innovación en el mundo de la banca y las entidades financieras, y pueden ir desde servicios de pagos, como Bizum o Twyp, hasta sistemas de crédito al consumo como Movistar Money.

Esta disrupción ha hecho que la industria de los servicios financieros, especialmente la industria bancaria, se esté convirtiendo cada vez más en un negocio de tecnología. Más que nunca, la competitividad de varios productos centrados en las finanzas se diferencia por las soluciones tecnológicas que los habilitan.

Figura 2: Adopción de FinTech en 20 mercados diferentes

En los mercados emergentes, donde más carencia de ciudadanos bancarizados existían, los teléfonos inteligentes se han convertido en el medio principal por el cual las personas acceden a Internet y utilizan diferentes servicios financieros.

Debido a este crecimiento, se ha comenzado a trabajar en dar forma al futuro de los servicios financieros en la economía digital. Según las actas de la Cuarta Cumbre de Políticas y Conocimiento entre América Latina y el Caribe y China , el crecimiento exponencial de la digitalización y la conectividad a Internet es la columna vertebral de la Cuarta Revolución Industrial, que ha afectado a todos los sectores, incluidos los servicios financieros.

La economía digital ha impactado profundamente el sector de servicios financieros en China al permitir nuevos modelos de negocios de banca e inversión basados en Internet con un menor costo de operación que han ampliado significativamente el alcance entre los consumidores, como es por ejemplo el uso de pagos con la plataforma de mensajería de WeChat.

Los Servicios Financieros Digitales

Los DFS incluyen una amplia gama de servicios a los que se accede y se prestan a través de canales digitales, incluidos pagos, crédito, ahorros, remesas y seguros. Y como hemos visto, en ellos el concepto DFS incluye servicios financieros móviles basados en los smartphones – pero también los Feature Phones que son el principal medio usado en algunos países de Africa e Índia -, llamados Mobile Financial Services (MFS), como elementos fundamentales del mundo Fintech. Dentro de los MFS, que utilizan el teléfono móvil para acceder a servicios financieros y ejecutar transacciones financieras, se encuentran los denominados:

- M-Money: es un servicio móvil que facilita las transferencias electrónicas y otros servicios transaccionales y no transaccionales que utilizan redes móviles. Es decir, centrados en la transferencia de dinero entre cuentas bancarias. Existen algunos como Instant Money, que permiten enviar dinero a cualquier teléfono móvil (SmartPhone o Feature Phone), con solo enviar un SMS.

Figura 3: Instant Money de Banco Sabadell

- M-payments: es el servicio concreto de pagos por móvil, como por ejemplo Mobile Pay, WePay de WeChat, Twyp de Bankinter con el que puedes pagar en comercios y gasolineras - por ejemplo -, o el popular Bizum. 

- M-Banking: es el uso de un teléfono móvil para acceder a servicios bancarios y ejecutar transacciones financieras, donde empresas como BBVA o Banco Sabadell han hecho auténticos esfuerzos por construir una banca móvil puntera. A menudo se utiliza este termino, lógicamente, para referirse solo a clientes con cuentas bancarias.

En los servicios Fintech, hay tres tipos de compañías que están realizando estos negocios, como son los servicios virtuales construidos sobre los servicios de la banca, que funcionan de forma similar a los operados móviles virtuales de las redes de comunicaciones, pero en el entorno bancario, y que son conocidos como MVNO como es el caso de Twyp y Bizum que se basan en entidades bancarias y clientes bancarizados asociando números de cuenta bancaria o tarjetas de crédito, los que han construido algunas empresas del mundo de las telecomunicaciones aprovechando que tienen suscripciones mensuales con sus clientes y, por tanto, tienen historial crediticio solvente y domiciliación de pagos actualizada, lo que les permite crear nuevos DFS, y que son llamados MNO por ser precisamente basados en eso, en un Mobile Network Operator.

A estos, hay que unir servicios independientes creados por nuevas empresas que se meten en el mundo de los DFS, como es el caso de WePay de WeChat o WhatsApp Payments que se basan en pagos y wallets gestionados por su red de servicios de chat, por ejemplo. Por supuesto, nos vamos a encontrar situaciones mixtas, porque hay bancos que se convertirán también en MVNO de sus propios servicios, como es el caso de SberBank o, alianzas entre varios bancos como es el caso de Bizum, conformada por la unión de 27 bancos españoles.

Riesgos de seguridad en los DFS

Por supuesto, donde hay dinero, hay gente buscando la oportunidad de robarlo, así que hay que evaluar bien los riesgos de seguridad y qué debemos hacer para mejorar su seguridad. En concreto, hay que mejorar algunos aspectos de la confirmación de las operaciones con los códigos de firma de operación basados en Segundos Factores de Autenticación utilizando códigos OTP (One-Time Password).

Teniendo en cuenta que los usuarios de estas plataformas pueden sufrir en cualquier momento un robo de las credenciales de acceso, los servicios DFS cuentan con ese Segundo Factor de Autenticación que se envía por un canal paralelo, ya sea una aplicación instalada en el móvil, un SMS recibido en el terminal móvil, un token criptográfico externo o una llamada de teléfono. Y es aquí donde los atacantes focalizan sus esfuerzos.

En un informe reciente de ITU, ENISA y todos los organismos financieros relevantes, donde se analiza el posible fraude en los sistemas DFS, se ven que las superficies de ataque de estos códigos de confirmación de operaciones pueden ser las siguientes :

- SS7 (principalmente por medio de captura de mensajes SMS y USSD – ambos son mensajes SS7): En estos casos el atacante tiene que conseguir acceso a la red SS7 - porque es un empleado interno malicioso de la empresa de telecomunicaciones o vulnerando servidores de esta red -,  que aunque no es algo al alcance de todos los atacantes, sí que existen esos escenarios donde es posible acceder al medio físico o la red para generar el tráfico malicioso. Sería necesario acceder al tráfico de la operadora de comunicaciones, y por tanto las empresas de telecomunicaciones que tienen los servicios FinTech en su negocio, han tomado medidas de fortificación de estas redes SS7, aunque no todas.

- Conexiones móviles (2G/3G/4G/5G): Desde hace tiempo, los ataques a las conexiones entre los terminales móviles y las antenas de comunicación han sido un punto de riesgo. Los ataques RTL-SDR para romper el tráfico GSM, o las vulnerabilidades que se han ido descubriendo en 2G/3G/4G han hecho que se pudieran capturar – si se está cerca de la víctima -, los mensajes SMS. 

Figura 4: Libro de Hacking comunicaciones móviles

(GSM/GPRS/UMTS/LTE) en 0xWord

Estos ataques a las conexiones móviles se explican en el libro de Hacking de Comunicaciones Móviles (2G/3G/4G) se explica muy bien, y en este artículo de 2014 de Pedro Cabrera se puede ver un ejemplo. Los nuevos estándares 5G han tenido en cuenta la protección y el cifrado estas conexiones para dificultar la posibilidad de crackear este tráfico y acceder al contenido del SMS en texto plano.

Figura 5: Ataque RTL-SDR para captura un SMS. El atacante debe estar en las proximidades del tráfico GSM por el que se entregará el SMS. 

- Clonado de SIM: Otra de las técnicas utilizadas por los atacantes consiste en tener el control de la tarjeta SIM de la víctima, para lo que se utilizan diferentes técnicas, como son el clonado de las tarjetas SIM, que se basa en vulnerabilidades criptografícas o debilidades en la cadena de seguridad de los proveedores de SIM – empresas de telecomunicaciones – a la hora de dar una copia de una tarjeta a una persona. 

- SIM Swapping: En este caso, con el objeto de tener el control de la SIM que pertenece al número de teléfono de la víctima, el atacante pide la portabilidad de un número de teléfono de una operadora a otra sin haber validado correctamente la identidad del que solicita la portabilidad. 

- Robo de 2FA en Apps TOTPs y SMS por Troyanos bancarios: Otra forma habitual de robar estos segundos factores de autenticación ha sido por medio de apps maliciosas, o troyanos instalados en el terminal. Solicitando acceso de lectura a los mensajes SMS en sistemas Android ha sido muy común, o directamente troyanizando el terminal llevándose las semillas de las apps TOTP. 

- Robo de Tokens en buzones de voz: Por último, como opción de accesibilidad, muchas plataformas permiten utilizar llamadas de voz para entregar los códigos de los Segundos Factores de Autenticación, lo que permite a algunos atacantes, aprovechar momentos en que el usuario tiene el terminal apagado – por ejemplo, en horario nocturno – y solicitar la entrega de los 2FA por voz. Esto lleva a que acabe el código en el buzón de voz grabado. Si no se ha fortificado el acceso al buzón de voz cambiando la contraseña por defecto – muy común en algunas operadoras de comunicaciones – entonces el atacante puede acceder al 2FA accediendo al mensaje del buzón de voz.

Como se puede ver, para fortificar el sistema de verificación de los DFS, es necesario hacer mejoras de seguridad a varios niveles. Desde la gestión de la seguridad en los terminales móviles, hasta en los protocolos de las redes de comunicaciones, y por supuesto en las apps de los propios MFS. Y por supuesto, en el Primer Factor de Autenticación, las credenciales de acceso al sistema.

Según encuestas realizadas por el grupo de trabajo ITU y la Agencia de la Unión Europea para la Seguridad de las Redes y la Información (ENISA), menos del 30% de las empresas de telecomunicaciones de la Unión Europea (UE) y menos del 0,5% de las empresas de telecomunicaciones de los países en desarrollo habían implementado algunas medidas de mitigación para los riesgos de SMS, los protocolos inseguros de las SIM o los buzones de voz. Hay que tener presente que, un fallo criptográfico en la SIM Card obliga al cambio y distribución de millones de nuevas tarjetas, lo que no hace fácil una operativa automática y de costes eficiente.

La encuesta, y el informe es del año 2017, y es verdad que las empresas de telecomunicaciones han evolucionado sus sistemas, e incluso implantado soluciones RCS, pero la existencia del enorme mercado aún de Feature Phones,  la no apuesta por RCS de iOS que apuesta por su iMessages, y la base enorme de apps que aún utilizan SMS, hace que haya que seguir poniendo medidas de seguridad al sistema SMS, que seguirá un tiempo en esta industria.

El uso del SMS en texto claro

El sistema de mensajes SMS, que se pueden enviar tanto por las redes de conmutación de paquetes, como encapsulados en la red de datos, y que se utiliza como Segundo Factor de Autenticación en muchos de los MFS, no va cifrado. Así, como se ha dicho anteriormente, si alguien accede al tráfico de las tramas SS7 que aún se utilizan en la red de conmutación de circuitos y paquetes, podrá visualizar el contenido del mensaje, en este caso el código OTP de una operación Paypal. Como se ha dicho antes, para acceder y manipular las tramas SS7 es necesario estar dentro de la red SS7 o vulnerar la seguridad de un servidor de la red - como ha hecho el mundo del cibercrimen en ocasiones pasadas - pero si lo puede hacer podrá acceder al contenido del mensaje. 

Figura 6: Captura de un SMS de Paypal en un paquete SS7 desde la red telco

En la imagen anterior vemos la parte correspondiente a la pila TCP/IP, debajo de ella la parte de SS7 y en este caso concreto, un mensaje SS7 cuyo “Operation Code” es: “forwardSM” y se corresponde con un factor de doble autenticación enviado por PayPal. El detalle que deseo que observéis (independientemente de las debilidades y ataques de la red SS7), es que estáis observando todo el contenido en texto plano, como hemos dicho, algo que no se puede cambiar porque SMS no va cifrado, así que hay que fortificar la capa de red, sí o sí. Si analizamos únicamente el campo “TP-User-Data” en otras capturas de tráfico, vemos que estos mensajes SS7 en texto plano, son empleados por un sinnúmero de aplicaciones y empresas:

Figura 7: Mensajes SMS capturados desde la red SS7.

En el caso de los SMS, la protección es que para acceder a ellos hay que tener acceso al tráfico de red, así que si alguien desde el otro lado del mundo intenta acceder a estos mensajes no podrá, ya que solo se envían en una ruta de encaminamiento hacia donde se encuentra el número destinatario en la red, por eso los ataques se deben de hacer desde posiciones muy estratégicas, salvo que, como se ha dicho antes, alguien pueda vulnerar la red SS7 y colarse dentro de ella. 

Es decir, que si alguien consigue acceder a la red SS7, o conseguir una conexión GSM insegura entre la antena y el destinatario del SMS con un ataque RTL-SDR, podrán conseguir ver el Segundo Factor de Autenticación. Es verdad que para que les sea útil deben tener antes el Primer Factor de Autenticación del MFS.

En el caso de apps para gestión de tokens de verificación enviados desde el servidor, como es el caso de Latch y sus OTPs (que aunque sean TOTP no hay que confundir con los Latch Cloud TOTP que se generan en el dispositivo), o Authy, los datos se cifran usando la red datos, como podemos ver en el ejemplo en la imagen siguiente.

Figura 8: Captura cifrada de un paquete de Authy

En la imagen anterior, podemos ver el triple handshake TCP, una vez finalizado ya pasa al nivel aplicación con el protocolo SSLv2 empleando el algoritmo SHA2, en la ventana inferior de Wireshark, se ve perfectamente que el contenido es “ilegible”.

Aún así, el uso de las apps en el dispositivo para la generación de códigos TOTP o la recepción de tokens TOTP desde el servidor, siguen teniendo sus riesgos. Las apps maliciosas en el dispositivo pueden acceder a las semillas TOTP en apps con permisos inseguros, el uso de plataformas de canales de mensajería tipo WhatsApp o Telegram siguen relegando su seguridad en el SMS (que utilizan para verificar el inicio de sesión de las cuentas), y, lo aún más preocupante, los atacantes han descubierto que cuando se hace un ataque de phishing a una víctima, lo mejor es pedirle primero el usuario y la contraseña y después el 2FA, con lo que en esos entornos no les importa si el TOTP se ha enviado por un canal sin cifrar, cifrado o se ha generado en el dispositivo. Engañan al usuario para que se lo entregue.

Reflexión final

Por supuesto, el esfuerzo en seguridad el mundo de los DFS y los MFS implica hacer ejercicios conjuntos a nivel de redes de comunicación,  continuar el proceso de fortificación de las redes de conmutación de paquetes con mensajes SS7, proteger al máximo los puntos de defensa del tráfico por el que circulan los SMS, ya que mientras no haya un standard como SMS que funcione asociado a un dispositivo en iOS, Android y Feature Phones seguirá con nosotros, por supuesto, se pueden utilizar otros canales alternativos como apps, sistemas de mensajería OTT como WhatsApp, Telegram, RCS o iMessage para los 2FA, y también debemos fortificar las apps, añadir mecanismos de detección del fraude y concienciación de los usuarios con la protección de su Primer Factor de Autenticación, ya que si el atacante no consigue éste, nunca le servirá el 2FA para nada.

Figura 9: Security Aspects of DFS

Como guía de mejores prácticas, se presenta a continuación exactamente lo que recomienda realizar DFS/ITU-T en su documento: “Security Aspects of Digital Financial Services (DFS)” Este documento presenta 21 recomendaciones que invito a que las leáis pues son la base de las medidas de seguridad en estas redes.

Autor: Alejandro Corletti

Figura 10: Contactar con Alejandro Corletti

Cómo evitar que Google utilice tu red WiFi en sus servicios de localización

Este no es un tema nuevo, pero he de reconocer que a mí, personalmente, me pasó desapercibido y quería compartirlo con vosotros. Se trata de "cómo evitar que Google utilice tu red WiFi en sus servicios de localización". Algo que no es nuevo, pero que en su momento tuvo su impacto en los medios de comunicación y que hoy en día, tras la aprobación del GDPR en Europa se ha quedado en una zona gris.

Figura 1: Cómo evitar que Google utilice tu red WiFi en sus servicios de localización

Para los que no conozcáis la historia, hay que volver atrás en el tiempo a cuando Google quería mejorar los servicios de localización de sus plataformas móviles. Es decir, cómo saber dónde se encuentra un teléfono Android con mucha más exactitud. Para ello, se decidió utilizar un sistema basado en las bases de datos de Wardriving.

Wardriving y el Google Street Car

Hace ya tiempo, el Wardriving se convirtió en una diversión de los hackers muy extendida. La idea era meter en un mapa todas las redes WiFi de la ciudad para que cualquiera que quisiera, pudiera conectarse a Internet.  Es decir, el concepto era geoposicionar redes WiFi por toda la ciudad. Eso se podía hacer andando, en coche o en bicicleta.

Figura 3: Iconografía para redes WiFi descubiertas

Se creó una iconografía completa que se ponía en forma de pegatinas, dibujos pintados en las paredes o apps que te decían en qué lugares de la ciudad podrías encontrar redes WiFi con las que te pudieras conectar a Intenet, ya fuera porque eran redes abiertas, o inseguras con WEP, o con contraseñas fáciles de WPA o WPA2. 

Figura 4: Iconografía de Wardriving por las ciudades

De hecho, la competición en muchos de los congresos y conferencias de hackers era conseguir el máximo posible de redes WiFi con la información de conexión a la red para la base de datos de Wardriving. Congresos tan importantes como DefCON o EkoParty, tenían sus secciones específicas dedicadas solo al Wardriving.  Debido a esto, yo os recomendaba hacer esto antes de ir a hacer un Ethical Hcking a una empresa porque los empleados suelen conectarse a muchas redes WiFi cercanas a sus oficinas.

Figura 5: Memes con el asunto de Google Steet Vier Car y el sniffig de redes WiFi

Siguiendo esta misma idea, Google comenzó en el año 2010 a hacer Wardriving geoposicionando todas las redes WiFi que veía con sus coches de Google Street View. Es decir, al mismo tiempo que pasaba el coche de Google Street View tomando fotos de las calles de la ciudad, iba capturando las redes WiFi que veía - e incluso datos en abierto -. Esto generó un gran escándalo, con denuncias en muchos países y un arduo debate.

Figura 6: Noticias del escándalo del escaneo de Google Street Car

Aquello se cerró, no sin que hubiera un lío en muchos países, e incluso Google tuvo que compartir los datos que había ido escaneando en cada uno de los países con los cuerpos de seguridad que tuvieron que revisar la información que había capturado de esas redes abiertas para ver, si en algún caso, habían capturado conexiones a Internet de los usuarios de la red sin cifrar que llevara información sensible y que, Google, hubiera almacenado sin conocimiento de los usuarios. Google borró los datos, y dijo que había sido culpa de una librería estándar mal usada.

Lo mismo, pero en Android

Por supuesto, la idea de copiar el concepto del Wardriving de la comunidad hacker para ir escaneando desde el Google Street Car todas las redes WiFi de la ciudad estaba bien, pero no era comparabale para nada si utilizaban los terminales smartphone con Android, que cada vez empezaban a tener más cuota de mercado frente a los líderes en el mundo móvil, donde iPhone, Motorola, Nokia o BlackBerry comenzaban a dejar paso a Android cada día más. En el libro de Hacking y Seguridad de Comunicaciones Móviles (2ª Edición) se hablan de estas técnicas para todo tipo de conexiones.

Figura 7: Libro de Hacking y Seguridad en comunicaciones móviles
GSM/GPRS/UMTS/LTE (2G,3G y 4) 2ª Edición

Así, los terminales Android (y también los terminales iPhone) utilizan un sistema de mantenimiento de los servicios de localización construido de la siguiente forma. Por un lado, aprovechándose los cada vez mejores servicios de GPS de los terminales reportan las potencias de señales capturadas  por cada terminal móvil de todos los elementos que emiten señales, ya sean BlueTooth, conexiones a redes de telefonía 2G, 3G y 4G, o redes WiFi. La idea es guardar de cada uno de ellos:

- El identificador físico que lo define de forma unívoca: BSSID, SSID, MACs, etc... 

- La potencia de la señal con que llega al terminal móvil. 

- La posición GPS que se puede obtener del servicio puro GPS. 

- Timestamp de cuándo se hace la captura de datos. 

- Información del terminal smartphone que hace la captura de datos.

Todos estos datos llegan a una base de datos donde se almacenan en Google. Con esos datos, utilizando algoritmos de triangulación y calibración,  permiten a Google saber:

- Dónde se encuentra realmente cada terminal móvil más allá de lo que marque el servicio GPS. 

- Saber dónde se encuentra cada terminal incluso si el sistema GPS falla. 

- Saber dónde se encuentra cada terminal con un servicio de menor latencia que el GPS. 

- Alimentar la base de datos con dónde se encuentra cada antena de telefonía exactamente. 

- Saber exactamente donde se encuentra cada red WiFi - incluida la tuya - del mundo.

Sin esta base de datos que da soporte a los servicios de localización de Google, aplicaciones tan populares como Waze o Google Maps funcionan regular. Puedes hacer la prueba tú mismo de forma sencilla. Basta con que pongas una ruta de tu casa a al trabajo en cualquiera de estas dos aplicaciones y quites la WiFi - la apagas en tu terminal iPhone o Android - y verás como, usando solo el GPS, los servicios de localización  funcionan regular y tienen márgenes de error muy altos.

Pero a muchas personas esto no les gusta, ya que también se guarda información de horarios de encendido y apagado del Access Point, de la seguridad de la red, de los fabricantes detrás de los dispositivos, y un buen número de insights que se podrían sacar.

Cómo sacar tu red WiFi de la bae de datos de Google Location Services

Esos datos también se utilizan para alimentar la ubicación en caso de anuncios mostrados por ubicaciones geográficas, o para otro tipo de servicios basados en ubicación. Es decir, gracias a la información que mantiene de las redes WiFi que captura usando los terminales Android como sensores, las conexiones a Internet de estos para enviarlos a sus servidores, y que tú tienes una red WiFi en tu casa, disfrutan de unos servicios de localización mejores que los que tuvo la industria de navegadores GPS para coches en su momento.

Figura 8: Gracias las bases de datos WiFi, Google Maps tiene
una precisión y velocidad mucho mayor que un GPS "tradicional"

Pero claro, Google (y Apple) no han pedido permiso a nadie para capturar esos datos tuyos. Supongamos que tú no quieres tener nada que ver con Google y no quieres que usen tu infraestructura tecnológica para hacer sus negocios. Pues entonces, tal y como está el panorama hoy en día, tienes que ser tú el que haga Opt-Out de su base de datos haciendo algo que no es muy sencillo para todos lo usuarios:

- Debes cambiar el nombre de tu red WiFi para que se den por enterados

Es decir, debes llamar a tu red WiFi de una forma especial, ya que Google se compromete a eliminar de sus bases de datos todos los datos asociados a redes WiFi cuyo nombre SSID acabe en _nomap. Es decir, debes entrar y cambiar tú el nombre de tu red WiFi si no quieres que Google lo utilice para sus servicio de localización con los que desarrolla su negocio en el mundo Android.

Figura 9: Página de ayuda en Google para explicar _nomap

No sé si este es el mecanismo más correcto o no. Y lo cierto es que si fuera un Opt-in, es decir, que Google indexara solo la información de las redes WiFi acabadas en _map, probablemente no tendría suficiente densidad de redes WiFi para construir unos servicios de localización potentes, pero lo cierto es que a día de hoy, Google y Apple se han construido la red de localización más potente del mundo gracias a que utilizan todos sus dispositivos, y cuando digo todos me refiero a todos - smartphone, SmartTVs, smartWatches, etc... -, en sensores para capturar información del espectro de señales a su alrededor y almacenan esa información para explotarla en su beneficio.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

AntiDDoS para todos los dispositivos IoT usando un GSM Shield hecho con Stack SMS

Este año, hemos vuelto a tener el honor de participar en los seminarios de la GSMA en el Mobile World Congress. El año pasado ya fuimos a mostrar nuestro querido DirtyTooth y parece ser que les gustó la idea de presentar alguna demo relacionada con la seguridad dentro sus seminarios sobre IoT. Así que este año hemos vuelto con una demo de nuestro Stack SMS.

Figura 1: AntiDDoS para todos los dispositivos IoT usando un GSM Shield hecho con Stack SMS 

Stack SMS es un SDK (disponible para Python, Android y Node.js) desarrollado por Ideas Locas CDO que nos permite abrir un nuevo canal de comunicaciones hacia nuestra infraestructura utilizando la red GSM y más concretamente utilizando los SMS o mensajes de texto. Esta posibilidad es lo que nos habilitó poder crear el servicio SafePost (antes Pigram) para tener servicios de Internet aún no teniendo de datos. Y también lo utilizamos en el chat para maximizar la comunicación en carrera dentro del equipo ciclista Movistar Team.



Figura 2: Chat con SMS Stack en Movistar Team

En el mundo de IoT, contar con este canal GSM significa la posibilidad de tener una línea de backup. Esto quiere decir que podríamos, por ejemplo, tener control sobre cualquiera de nuestros dispositivos utilizando Stack SMS simplemente con tener cobertura GSM, es decir, sin datos.

Figura 3: Formato básico de trama de comunicaciones Stack SMS

Dicho control se realiza empaquetando las órdenes dentro de cadenas de mensajes SMS. Stack SMS hace la parte más complicada, encapsular y gestionar la recepción, integridad y seguridad de la información enviada. Puedes consultar el paper sobre Stack SMS en el enlace GitHub de la aplicación.

Figura 4: Paper de Stack SMS 

Pero si quieres aprender cómo utilizarlo en una aplicación móvil, lo mejor es que te veas este vídeo de nuestra serie de Code Talks For Developers, donde mis compañeros del departamento Pablo González Pérez y Lucas Fernández Aragón nos hablan en profundidad de Stack SMS:


Figura 5: CodeTalk  for Developers sobre Stack SMS

Volviendo a la charla de la GSMA en el MWC de este año, buscamos una aplicación práctica de Stack SMS relacionada con la seguridad de los dispositivos IoT. Finalmente nos decidimos a implementar una posible forma de recuperar el control sobre dichos dispositivos de la infraestructura mientras estamos siendo afectados por un ataque tipo DDoS. Es decir, que, a pesar de no poder acceder desde Internet a nuestra infraestructura, con Stack SMS podemos abrir otro canal a través del GSM para al menos, poder enviar órdenes concretas a cualquier dispositivo que tuviera dicha conexión.

Figura 6: Estado de nuestra red después de un ataque DDoS.
Perdemos el control de los dispositivos ubicados dentro de nuestra infraestructura.

¿Cómo sería todo el proceso? 

Para implementar Stack SMS el primer paso será desarrollar nuestra capa de aplicación utilizando el SDK donde podemos definir de la forma que mejor encaje en nuestro proyecto, todos los detalles de funcionamiento. De hecho, en el paper hay disponibles varios ejemplos que van desde juegos, pasando por una aplicación de chat hasta el control de dispositivos IoT utilizando una Raspberry Pi (ejemplo que precisamente fue el que usamos para la demo y que veremos más adelante).

Figura 7: Implementación de Stack SMS sobre una Raspberry Pi y un módulo GSM

El siguiente paso será enviar las ordenes utilizando el encapsulamiento de Stack SMS. Este se encargará de aplicarle la seguridad necesaria a la transmisión (PSK y cifrado AES-CTR) así como de fragmentar la orden u ordenes enviadas. El dispositivo receptor recibirá los SMS codificados con Stack SMS y procederá a ejecutar los comandos recibidos que previamente hemos programado sobre el mismo.

Finalmente, este enviará igualmente de vuelta información sobre el estado final del dispositivo y el resultado de las órdenes ejecutadas. Por ejemplo, la orden podría ser cambiar una contraseña, apagar un dispositivo, reiniciarlo, etcétera.

Figura 8: Funcionamiento de Stack SMS.

Esta teoría aplicada a la demo propuesta con DDoS funcionaría de la siguiente manera. El primer paso será conectar los dispositivos que queramos controlar con Stack SMS a la red GSM (con una SIM). En nuestro caso, utilizamos una Raspberry Pi con un shield GSM haciendo las funciones de router y los dispositivos los conectamos directamente desde los puertos GPIO representados por leds.

En caso de ataque DDoS, desde Internet no podremos acceder a los dispositivos pero sí podremos enviar el comando que queramos directamente desde otro canal seguro, totalmente independiente al otro (Internet) que nos permitirá retomar el control o al menos realizar operaciones dentro de nuestra infraestructura como ya hemos comentado anteriormente.

Figura 9: Retomando el control de un ataque DDoS con Stack SMS.

Resumiendo, y centrándonos en este ataque DDoS, ¿qué acciones podríamos realizar con Stack SMS?:

• Alcanzar dispositivos detrás de nuestra infraestructura.
• Mandar y ejecutar ordenes.
• Cambiar contraseñas.
• Apagar o encender dispositivos, relés, motores, etcétera.
• Enviar datos a través de la LAN.
• Reiniciar dispositivos críticos.
• Etcétera.

En el siguiente vídeo se puede apreciar una demo similar a la que realizamos en el MWC. Para ello utilizamos una pequeña aplicación en Android que se encargaba de enviar la orden de apagado o encendido a uno de los tres leds de colores conectados a los puertos GPIO de una Raspberry Pi con un shield GSM conectado tal y como podemos ver en el siguiente vídeo:

Figura 10: PoC IoT with GSM Shield

Stack SMS está disponible para su estación directamente con "pip install SMS-Stack" o descargándolo desde la siguiente dirección:

Figura 11: SDK de SMS Stack en GitHub

Seguiremos hablando de Stack SMS más adelante mostrando nuevos proyectos, imágenes de la charla, así como nuevas implementaciones que vayamos desarrollando. Os animamos también a probarlo y a contarnos vuestras ideas e impresiones.

Happy Hacking Hackers!!!

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.

Introspection: (@Snowden) Edward Snowden diseña un dispositivo de seguridad para saber si te espían el móvil

Así se llama el dispositivo que Andrew ‘bunnie’ Huang y Edward Snowden han presentado al mundo. Introspection. Un dispositivo de seguridad que se acopla a tu terminal móvil para monitorizar si en cualquier momento está emitiendo señales de comunicación a bajo nivel que no deberían estar realizándose. Es decir, para ver si tu terminal móvil está enviando información en contra de tu voluntad, y para evitar capas de software que pudieran estar controladas, y software corriendo en los chips que pudiera estar controlado - recordad el escándalo con los chips Intel que está bajo estudio ahora mismo - directamente monitoriza las señales en los buses a nivel físico.

Figura 1: Introspection. Edward Snowden diseña un dispositivo
de seguridad para saber si te espían el terminal móvil.

Como digo, el dispositivo se acopla a nivel físico para poder medir las señales de los buses de comunicación del hardware que son utilizados por los elementos de comunicación de un terminal, como son las conexiones WiFi, BlueTooth, las comunicaciones GSM, 2G, 3G, 4G, las conexiones RF o el mismo GPS. En esta imagen se ve cómo se conecta físicamente a la circuitería del terminal iPhone para monitorizar los buses con unos cables que salen debajo de la zona de la SIM.

Figura 2: Conexión cableada de Introspection en un iPhone

En cada terminal hay que hacer una serie de conexiones y debería hacerse por gente especializada. Monitorizar los buses es la única forma que es 100% de fiar, según explican, para poderse fiar de un terminal que ha sido puesto en modo avión y del que no se espera ninguna conexión. Para ello, miran los buses utilizados de todos los elementos de comunicación. La siguiente tabla recoge la lista de sistemas de comunicación y buses monitorizados por su sistema. Como curiosidad, la tabla publicada tiene las típicas marcas del corrector ortográfico de Microsoft Word (una de "metadata leakage" en el post).

Figura 3: Lista de señales monitorizadas

A partir de ese momento, Introspection auditará todas las señales para detectar tráfico en los buses de estas señales que se produzcan cuando no deberían producirse porque el terminal está en modo avión. Esto garantizaría que durante los instantes que el usuario quiera, el terminal no emite ninguna señal lo que evitaría que se pudiera localizar por medio de los múltiples caminos que existen: GPS, trilateración de antenas de comunicación, trilateración de redes WiFi, etcétera.

Figura 4: Señales de bus FE1 en modo avión y en modo comunicación.

En la figura superior se puede ver cómo los buses de comunicación dejan de emitir señales cuando están en modo avión, así que si están emitiendo significaría que no está en modo avión de verdad y alguien podría estar recibiendo la información del terminal, y por tanto la ubicación del mismo en el mundo.

Figura 5: Diseño de cómo sería el funcionamiento de Introspection

El objetivo es que fabricantes, operadores, o personal cualificado pueda inspeccionar el software que corre en Introspection, que puedan analizar el hardware con que se construye y que puedan instalarlo ellos sin necesidad de contar con los fabricantes que proveen los teléfonos. Para ello, el diseño se presenta como un recargador de batería extra, tal y como se ve en la fotografía.

Figura 6: Conexión externa e interna en un iPhone

La conexión se podrá hacer a través de un nexo entre las conexiones físicas que se hacen internamente en el dispositivo y los circuitos de Introspection. Aquí la conexión que es necesaria en un iPhone, que es uno de los dispositivos de los que Edward Snowden no se fía por haber aparecido también en el programa PRISM. Al final la propuesta que hace Introspection es meterse en las capas más bajas posibles para saber si te están monitorizando e ir a por las señales físicas parece que es lo más fiable a día de hoy, porque lo demás todo se puede troyanizar por una capa inferior.  Eso sí, esto no protegerá de todo el hacking de comunicaciones móviles que se produzca desde fuera.

Saludos Malignos!

WebCasts, Cursos y Charlas en la 2ª Quincena de Marzo

Con el mes ya entrado, hay bastantes actualizaciones en la agenda de actividades que te pueden interesar, así que he hecho este resumen con lo que tienes durante las dos próximas semanas y media  - donde además pilla de por medio la Semana Santa - que nos quedan de Marzo.  Como verás hay cursos online, webcasts gratuitos y algún evento al que puedes acudir.

Figura 1: Webcasts, Cursos Online & Conferencias de Seguridad en la 2ª Quincena de Marzo

Entre otras cosas, hemos añadido Eleven Paths Talks un ciclo hecho por los CSA (Chief Security Ambassadors) de Eleven Paths para que puedas conocer de primera mano mejor nuestras tecnologías. Este es el calendario con la leyenda [G] -> Gratuito y [*] -> Yo participo.

14 de Marzo: Madrid - Jornada de CiberSeguridad [G]

Este lunes hay un ciclo de conferencias que dura todo un día en el que participarán varios ponentes hablando de ciberseguridad. Entre ellos estará Pablo González o Fernando Acero, por poner citar alguno de los ponentes. Se hacen en el IES Virgen de la Paloma de Madrid y es gratuito. Tienes la información y la agenda en este enlace. Jornada de CiberSeguridad IES Virgen de la Paloma.

16 de Marzo: Madrid - El País Retina: Ciberdelincuencia [G] [*]

El miércoles de esta semana, dentro de los actos de celebración del aniversario de El País, se celebrará en Madrid una conferencia dedicada a la Ciberdelincuencia y el Cibercrimen, en la que participaré dentro de una mesa de debate. Son varias mesas de debate y hay un buen número de ponentes invitados. Si quieres asistir debes apuntarte en la web que El País ha abierto para ello.

17 de Marzo: Online - Firma Biométrica en el ámbito Sanitario [G]

Comenzamos este día una iniciativa en Eleven Paths orientada a explicar detalles de nuestras tecnologías y cómo pueden ser aplicadas en diferentes problemáticas. Son sesiones vía WebEx en las que puedes interactuar con el ponente, hacer preguntas y ver la sesión en vídeo. En esta ocasión comenzaremos por una sesión dedicada a la Firma Biométrica en entornos sanitarios que impartirá mi compañero Rames Sarwat. Para asistir debes registrarte en el siguiente formulario que hemos habilitado. Registro Eleven Paths Talks. Hora de comienzo 15:30 (GMT+1)

17 de Marzo: Madrid - Jugando con SDR [G]

También el día 17, en este caso de forma presencial en Madrid, tendrá lugar una nueva conferencia dentro del ciclo TASSI de la Universidad Politécnica de Madrid. La sesión está orientada a Software Defined Radio y podéis ver cuáles son las herramientas necesarias para sacar partido al SDR y analizar espectros GSM, etcétera. Tienes más información en el Ciclo de Conferencias TASSI.

21 de Marzo: Online - Curso de Hacking Ético

El lunes 21 de Marzo da comienzo un nuevo curso de The Security Sentinel orientado a enseñar, durante varias semanas a los asistentes, cuáles son las herramientas y los procedimientos que se usan durante un proyecto de Hacking Ético. Todos los asistentes recibirán además el libro de 0xWord de Pentesting con PowerShell, que se centra en la explotación de estas técnicas en las redes empresariales Windows. Tienes más información en la web: Curso Online Hacking Ético.

24 de Marzo: Online - Equipo de Respuesta ante Incidencias [G]

La segunda jornada de Eleven Paths Talks la impartirá nuestro compañero Leonardo Huertas desde Colombia, y estará centrada en la gestión de Equipos de Respuesta ante Incidencias. Será online, a través de WebEx y puedes registrarte de forma gratuita a través del formulario de registro de Eleven Paths Talks. Hora de comienzo 15:30 (GMT+1)

28 de Marzo: Online - Curso de Análisis Forense Informático

Este día comenzará un Curso Online de 12 semanas de duración orientado a explicar en qué consiste el trabajo de un analista forense, así como a capacitar a los alumnos para la realización de este tipo de trabajos tan demandados hoy en día. Los asistentes recibirán como parte del curso el libro de 0xWord "Máxima Seguridad en Windows" donde se explican conceptos fundamentales de la arquitectura de seguridad de Windows que todo analista debe conocer. Tienes más información en la web: Curso Online de Análisis Forense Informático.

31 de Marzo: Online - Comprendiendo la Seguridad en Entornos Industriales [G]

Tercer y último WebEx de Marzo dentro de las sesiones de Eleven Paths Talks. En esta ocasión el ponente es nuestro CSA Claudio Caracciolo que compartirá su experiencia en el mundo de la seguridad industrial para explicar y dar algunos detalles que ayuden a mejorar la gestión de la misma a las personas que tengan que lidiar con estos entornos. Puedes registrarte de forma gratuita a través del formulario de registro de Eleven Paths Talks. Hora de comienzo 15:30 (GMT+1)

Saludos Malignos!

Robar datos de servidores aislados usando GSM, RF o Calor

En los entornos de alta seguridad, como por ejemplo los sistemas informáticos centrales de infraestructuras críticas, existen algunos equipos que son aislados de cualquier red para así evitar cualquier contagio, manipulación o robo de datos. En estos entornos los equipos críticos se desconectan de cualquier red de datos para evitar cualquier fuga de información. Aún, así como vimos en el caso Stuxnet, si alguien es capaz de conectar un dispositivo USB realmente se tiene una conexión de red oculta, o intermitente, como os contaba en el artículo dedicado a las Hidden Links.

Figura 1: Robar datos de servidores aislados usando emisiones GSM, RF o Calor

Suponiendo que uno de esos equipos críticos pudiera llegar a ser infectado con un troyano (vía USB, vía manipulación física, vía inclusión de un hardware troyanizado directamente en el fabricante), existe el problema de controlar las acciones del malware, es decir, enviar comandos, y recibir datos. Si el equipo tuviera tarjeta de red WiFi, hace poco vimos como se podrían utilizar los SSID, pero lo habitual es que estos equipos no tengan físicamente ni tarjetas WiFi, ni BlueTooth, ni Ethernet, ni InfraRed ni modem para evitar cualquier tipo de conexión externa. Pero aún así, esto no tiene porque ser suficiente.

GSMem: Generando señales GSM con equipos infectados

Estos días de Agosto está teniendo lugar el 24th USENIX Security Symposium en Whashington D.C. donde se presenta una buena cantidad de estudios académicos relativos al mundo de la seguridad informática. Entre ellos se presenta el trabajo de un grupo de investigadores de la Universidad Ben Gurion del Negev, en el que muestran como es posible enviar datos de un equipo infectado y desconectado de cualquier tipo de red a un terminal "Feature-Phone", es decir, no a ningún smartphone que venga provisto con tecnologías Wi-Fi o BlueTooth.

La técnica utilizada por GSMem para hacer la "exfiltración" de datos de un equipo infectado a un terminal Featured-Phone sin utilizar ninguna conexión consiste en manipular la señal GSM que le llega a la antena GSM del teléfono, usando un firmware que se instala en el equipo infectado para utilizar el hardware del PC infectado como si fuera una antena GSM, por supuesto de muy mala calidad, pero aún así con capacidad suficiente como para que su señal pueda ser captada por un programa especial que mire las variaciones de la señal GSM hasta a 30 metros de distancia. 

Figura 2: Funcionamiento de GSMem para exfiltrar datos a Featured-Phones

En el vídeo se puede ver cómo el software instalado en el PC es capaz de grabar las pulsaciones del teclado y enviarlo por señal GSM que es captada por un teléfono "Featured-Phone" a través de la antena GSM que lleva incorporado. El paper ha sido publicado aquí: GSMEm

AirHooper: Sacando datos vía RF

Este no es el primer trabajo de este equipo de investigación sobre este tema de los "equipos aislados". El año pasado hicieron lo mismo pero a través de Radio Frecuencia, utilizando el mismo concepto de convertir el hardware de un equipo normal en una antena RF para transmitir los datos. El paper está disponible en SlideShare.

Figura 3: Paper sobre AirHooper

Este trabajo, al que le llamaron AirHooper, utilizaba la tarjeta gráfica para emitir determinadas radio frecuencias que pudieran ser captadas por un receptor, como se hace en las técnicas Tempest para saber qué operación se está ejecutando en el microprocesador.

Figura 4: Algoritmo para pintar píxeles y generar RF adecuadas

El uso de las Radio Frecuencias es algo muy común en las técnicas Tempest, ya que no solo las tarjetas gráficas, sino las operaciones de un microprocesador pueden ser leídas remotamente por las ondas que emite el hardware de los equipos. Estas son las técnicas de criptoanális acústico y en esta conferencia dedicada a Tempest lo tenéis explicado.


Figura 5: Técnicas Tempest
A día de hoy, las técnicas Tempest avanzan día a día - hemos visto trabajos en los que las mediciones se hacen a través de las ondas que se transmiten cuando una persona toca el equipo - y es un problema que preocupa en los entornos de seguridad más críticos. Debido a esto hay ya muchos trabajos orientados justo a a protegerse frente a estas técnicas, buscando tener Hardware más "silencioso" e intentar introducir vía software ondas de RF que distorsionen las mediciones.

BitWhisper: Temperatura como Side-Channel

Pero no solo esas técnicas de mediciones vía RF o GSM, tiempo atrás los mismos investigadores habían demostrado en el proyecto BitWisher, como un equipo podría enviarle ordenes a otro a través del aire utilizando incrementos y decrementos en la temperatura que pudieran ser medidos. De esta forma, se podría enviar y recibir información sin utilizar ninguna conexión de red entre dos equipos aislados de la red. En el siguiente vídeo se puede ver la demostración para controlar una lanzadera de misiles de juguete.


Figura 6: Demostración de BitWisher

Al final, cualquier variación que pueda medirse puede convertirse en un side-chanel, como ya vimos en el trabajo de Pulse, dedicado a transmitir datos entre un dispositivo móvil y un lector magnético que es capaz de medir las variaciones en el campo magnético producidas por un smartphone.

Con este tipo de sistemas de transferencia de datos desde equipos aislados hay que repensar el número de medidas que se debe imponer a cualquier equipo que de verdad se quiera que esté en un entorno desconectado totalmente, ya que como vemos, utilizando hardware sin medidas de protección extras existen técnicas que hacen posible tanto sacar datos como controlar la ejecución de un software enviando comandos a través de variaciones GSM, señales de RF o variaciones de calor y más que veremos.

Saludos Malignos!

Las escuchas telefónicas de la NSA a Angela Merkel, Helmut Kohl y Gerhard Schröder

Hace poco Wikileaks realizó la clasificación y publicación de documentos filtrados por Edward Snowden relativos al espionaje de la NSA a los presidentes de la República de Francia. Ahora ha realizado ese mismo trabajo relativo a los Primeros Ministros del gobierno de Alemania, clasificando y ordenando los documentos que detallan las escuchas a Angela Merkel, Helmut Kohl y Gerhard Schröder, además de todo los miembros de su oficina.

Figura 1: Las escuchas teléfonicas de la NSA a Angela Merkel, Helmut Kohl y Gerhard Schröder

Los documentos están filtrados desde el departamento de Global SIGINT de la NSA, que es el área dedicada a la Inteligencia de Señales del gobierno de los Estados Unidos de América, o lo que es lo mismo, a generar inteligencia a partir de escuchas de señales de comunicaciones.

Figura 2: NSA Signals Intelligence

En la filtración, se recogen datos como los selectores que utilizan para rastrear las llamadas de teléfono a través de Internet de todos y cada uno de los miembros del gobierno para poder capturar las llamadas telefónicas.

Figura 3: Números de teléfono usados como selectores de búsqueda

Esto ya se había filtrado con anterioridad y probablemente utilizaban el trabajo de interceptación de tráfico que habían implantado con el GCHQ británico y que se detallaba en el proyecto TEMPORA. o directamente con captura de señales móviles y hacking de estaciones base como se detallaba en el proyecto de AURARAGOLD. En la filtración, lo que aparece es una recolección de las transcripciones hechas por "agentes de inteligencia" que explican el contenido de la captura de teléfono hecha por la NSA.

Figura 4: Detalles de la filtración publicada por Wikileaks

Las llamadas que se han descrito tienen que ver con conversaciones privadas entre los presidentes alemanes con otros presidentes o dirigentes europeos hablando sobre diversos temas. Algunos tan actuales hoy en día como la Crisis de Grecia en el año 2011, donde Angela Merkel mostraba sus dudas sobre la solución.

Figura 5: Un documento filtrado por Wikileaks sobre el espionaje a Angela Merkel relativo a la crisis de Grecia

Esta clasificación de Wikileaks es un trabajo de ordenación y clarificación de informaciones que ya se sabían, y alargan ya las filtraciones de Edward Snowden por tres años. Todo el mundo ya sabe lo que ha estado haciendo la NSA durante la última década, todo el mundo se ha escandalizado, pero en los Estados Unidos, aprovechando la aparición de cualqueir Joker, y gestionando una campaña de comunicación adecuada a la población - declarando hasta el Estado de Emergencia -, consiguieron que el Patriot Act se les fuera aprobado otra vez durante este mes de Junio, así que todo sigue igual.

Saludos Malignos!