Exprimir el Secure Edge: Webinars de Cloudflare en Directo durante Septiembre

El calendario de actividades de divulgación tecnológica es alto en Cloudflare, y una de estas actividades son los Webinars en directo. Cada mes puedes participar en nuevos seminarios que además incluyen las novedades de todo lo que se va publicando en el modelo de Innovación Continua que defiende y practica la compañía.

Figura 1: Exprimir el Secure Edge - Webinars de Cloudflare

en Directo durante Septiembre

Hoy os traigo la lista de los que están planificados para este mes de Septiembre, para que si tienes tiempo, puedas participar en alguno de ellos que si te interesa el mundo de las tecnologías de seguridad en el Edge y los sistemas de Zero Trust en arquitecturas de Secure Access Service Edge (SASE), seguro que lo vas a disfrutar.

Todos los Webinars en Septiembre

09: From Robotics to Remote Access: Implementing Zero Trust in an Era of Evolving Threats

"Retailers are juggling managing vast amounts of customer data, payment information, and supply chain networks across multiple locations and platforms, traditional perimeter-based security models are proving inadequate against sophisticated cyber threats.Join us for our webinar featuring Ocado Group's Technical Architect as he shares their real-world Zero Trust Network Access (ZTNA) deployment journey. 

Figura 2: From Robotics to Remote Access: Implementing

Zero Trust in an Era of Evolving Threats

From securing robotic warehouse systems and customer fulfilment platforms to protecting proprietary technology solutions and sophisticated automation, discover how Ocado Group implemented Zero Trust principles across their entire technology ecosystem."

10: 3 phases, 10 steps: Implementing a SASE architecture

"Cloudflare experts will walk you through a proven 10-step roadmap to successfully implement SASE across your organization. Drawing from real-world customer examples, we’ll explore how leading enterprises are scoping their Zero Trust projects, overcoming common roadblocks, and unlocking measurable improvements in agility and security."

Figura 3:  3 phases, 10 steps: Implementing a SASE architecture

10: Securing and scaling your cloud environment to support AI transformation

"Even the most innovative and well-built AI application won’t succeed if it lacks the right underlying cloud infrastructure. The right foundation enables strong data security, efficient connectivity between AI components, and cost-effective scale. The wrong one turns those same benefits into obstacles. This is doubly true for agentic AI, whose complexity introduces a whole new realm of security and scalability issues.

Figura 4: Securing and scaling your cloud environment to support AI transformation

How should organizations adapt their cloud environments to support AI scale and security — whether they have already made cloud investments, or are turning to the cloud for the first time? Forrester guest speaker Lee Sustar has extensive experience advising enterprises on exactly that question. Join our webinar to learn about: Common trends and challenges in how organizations make AI-focused cloud investments Lee’s advice for organizations tackling these challenges Cloudflare’s perspective on how a commodity cloud vs a connectivity cloud delivers competitive advantage with AI scaling."

17: Modernizing Security: Real World Stories of Zero Trust in Action

"Employees, applications, and infrastructure exist everywhere today – across regions, cloud environments, and hybrid work settings. To manage this sprawling attack surface, many organizations are modernizing security with Zero Trust best practices to reduce risk, simplify their architectures, and enable business agility.

Figura 5: Modernizing Security: Real World Stories of Zero Trust in Action

In this webinar series, Cloudflare spotlights customers making progress on that journey. Register now to join a conversation exploring successful real-world deployments, including:Priority use cases to get started and scale with Zero TrustCommon challenges and best practices to overcome themArchitectural strategies and technical capabilities, including roadmap previews."

18: Temporada alta de fin de año 2025: Maximiza ingresos y minimiza riesgos.

"¿Está tu infraestructura digital lista para afrontar la temporada alta de ventas de fin de año 2025 y el aumento de ciber-amenazas?Únete a nuestros expertos de Cloudflare para conocer cómo fortalecer la resiliencia digital de tu negocio durante la época más exigente del comercio minorista.Compartiremos estrategias prácticas para retailers que se están preparando para los picos de tráfico del Buen Fin, Black Friday, Cyber Monday y la temporada navideña, en un contexto donde las amenazas evolucionan constantemente: desde ransomware que impacta operaciones e inventarios, hasta ataques dirigidos a APIs o páginas de pago.En esta sesión de alto impacto te mostraremos cómo proteger tus ingresos, reducir riesgos y asegurar una experiencia de compra fluida durante tus días más críticos.

Figura 6: Temporada alta de fin de año 2025: Maximiza ingresos y minimiza riesgos

Aprenderás cómo:Escalar sin fricción durante aumentos repentinos de visitas, donde cada segundo cuenta para convertirDefenderte de bots avanzados, ransomware y ataques DDoS que apuntan a los días de mayores ventasEvitar fraude digital, robo de datos de pago y abuso de APIs en plataformas de checkout, inventario y logísticaImplementar estrategias tecnológicas que prioricen al comprador real y aseguren la información del cliente."

30: How Cloudflare can coexist alongside Zscaler to fast-track your remote access project

"Are you worried about doubling down with the wrong security vendor? Maybe you are using one vendor (like Zscaler) for web inspections, but the thought of a full-scale SASE rollout seems overwhelming, complex, and disruptive. The good news is you can start modernizing remote access immediately, without those concerns.Join this webinar to discover how Cloudflare can strengthen and simplify security, while coexisting seamlessly alongside your web proxy from vendors like Zscaler.

Figura 7:  How Cloudflare can coexist alongside Zscaler

to fast-track your remote access project

In particular, our experts will show how to take advantage of clientless deployments of ZTNA, DNS filtering, and email security to improve your posture — all without installing additional software on devices.With demos, architectural walkthroughs, and real-world customer examples, you will learn:Use cases that deliver quick time-to-value with minimal disruptionStep-by-step technical guidance to run Cloudflare in parallel with Zscaler Recommendations on when a best-of-breed approach makes sense."

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Serverless & Bullet-Proof Web Sites (1 de 2)

En este artículo me gustaría contaros una pequeña PoC que hicimos en el equipo de Ideas Locas que teníamos guardada para algún evento de Web3, pero que como tengo ganas de contárosla, he decidido hacerlo desde hoy. No es un estudio completo, ni mucho menos, porque el escenario es enorme, pero se basa en un idea muy sencilla, que es hacer Serverless & Bullet-Proof WebSites, capaces de soportar el intento de bloqueo o censura de cualquier entidad.

Figura 1: Serverless & Bullet-Proof Web Sites (1 de 2)

Esto no es algo nuevo, y la Serverless Web lleva tiempo estudiándose, y trabajándose con diferentes arquitecturas, todas ellas totalmente distribuidas.

Dust-RSS

Uno de esos ejemplos fue un proyecto personal del equipo de Ideas Locas, en aquel entonces en Informática 64, en aquel entonces del año 2010, y que presentamos en la RootedCON de 2011 y se llamó Dust-RSS.

Figura 2: Dust-RSS en su presentación en RootedCON 2011

La idea era muy sencilla, evitar la censura de los servidores RSS de los blogs para permitir que cualquiera que tuviera algo que comunicar lo pudiera hacer siempre, y para eso diseñamos una arquitectura muy sencilla, basado en claves PGP y una red P2P para hacer la distribución. Esto hacía que no hubiera un único punto de fallo en el servidor web, ni en el DNS, y que con tener la clave pública PGP del publicador se pudiera buscar por redes P2P las publicaciones. 

Figura 3: Demo de Dust RSS funcionando

De esta forma, el publicador lo único que debía conservar era su clave PGP privada para poder poner en la red P2P una nueva publicación. La arquitectura funcionaba, pero se quedó en una PoC que presentamos en DefCON 2012, y que se quedó como un bonito experimento.

OSIRIS SPS

Uno de las arquitecturas que buscaba solucionar estos problemas de censura de servidores Web se trataba de OSIRIS SPS (Serverless Portal System) y su Gateway ISIS, para poder publicar servidores Web que no dependieran de un único punto de fallo. Para ello, la solución era similar a tener a páginas web cacheadas y compartidas por una red P2P.

Figura 4: Foro de Anime publicado en Osiris SPS visible vía Isis Gateway

Las páginas web de los portales que se ven a través de esas URLs realmente no están en ningún servidor web concreto, sino distribuidos por toda la red P2P de Osiris SPS, lo que impediría un bloqueo o censura del sistema. Es perfecto para crear foros y portales de denuncia social que no puedan ser quitados de Internet si no quieren sus usuarios.

DeepWeb: TOR, I2P, FeeNet, Hyperboria, CJDNS

Todas estas soluciones no accesibles a través de los navegadores de "superficie", son consideradas redes de la DeepWeb, no solo porque no son accesibles con las herramientas más comunes de Internet, sino porque además cuentan con herramientas y protecciones contra el control, ya sea cifrados especiales o como hemos visto, para evitar el bloqueo de sus contenidos, como en el caso de OSIRIS SPS o el sistema DUST RSS que utiliza mecanismos P2P para ello.  q

Figura 5: Libro de Deep Web: TOR, FeeNEt & I2P.  Privacidad y Anonimato 
de Daniel Echevarry a.k.a. "adastra" en 0xWord.

Por supuesto, muchas de las funciones de seguridad que se buscan en estas redes, están en las más conocidas de la DeepWeb como son  TOR, FreeNET e I2P, donde el cifrado de las comunicaciones es una de las claves en todas ellas.

Figura 6: Arquitectura de conexión CJDNS para la red Hyperboria

Pero la búsqueda de arquitecturas distribuidas y seguras ea algo que se ha estudiado mucho, como el caso de CJDNS y su red Hyperboria con conexiones cifradas y certificadas sobre IPv6, GNUNet, Lantern, YaCy para conseguir que no puedan ser accesibles los contenidos por nadie.

Malware en BlockChain

Por supuesto, pensar en arquitecturas Serverless y Distribuidas, es hablar del core de las cadenas de bloques de BlockChain, y utilizar las capacidades que tiene para poder almacenar datos de forma permanente y protegida con la distribución por diseño que tiene esta tecnología.

Figura 7: PoC de C&C con OP_Code en cadena de BitCoin

propuesta por Yaiza Rubio y Felix Brezo en EuskalHack 2017

En la EuskalHack del 2017, Felix Brezo y Yaiza Rubio hacían una demostración de cómo se podrían almacenar comandos de un C&C de una Botnet de malware en el campo OP_CODE la cadena de bloques de BitCoin.

Figura 8: Libro de "Bitcoin: La tecnología Blockchain y su investigación"
de Yaiza Rubio y Félix Brezo en 0xWord

Esto, al precio que está hoy el BitCoin parece un poco caro, pero esta idea de usar la cadena de OP_CODE para hacer servicios no es nueva, y algunos proyectos lo han utilizado en el pasado, aunque co la proliferación de cadenas de bloques a precios mucho más más económicos, hace que ya no sea necesario centrarse en ese campo.

Figura 9: Análisis del malware de Etherhiding

Y como muestra de esto lo hemos tenido con el caso del malware de Etherhiding, donde el binario del malware se han escondido dentro de la cadena de Binance Smart Chain, y ha utilizado SmartContracts para actualizarse.

Redes Sociales Descentralizadas

Por supuesto, la explosión de las cadenas de Blockchain, y otras arquitecturas distribuidas, hayan ido apareciendo en todos los verticales tecnológicos nuevos servicios que pretenden ser más resistentes contra los ataques a servicios descentralizados, como son las Redes Sociales.

Figura 10: Yo tengo mi curenta en Mastodon

Ahí, propuestas como Mastodom, Diaspora, Matrix, Block Square, que son sólo una pequeña muestra, han ido apareciendo por todos los rincones de Internet, y se han convertido en parte de la transformación y disrupción que se está viviendo en este mundo de las redes sociales.

Figura 11: Red social Diaspora 

Pero la descentralización de todos los servicios digitales que se están construyendo hoy en día. Algunos que se han hecho piezas fundamentales en las arquitecturas Web3, como el almacenamiento IPFS (Inter Planetary File System) del que ya hablamos.

Y esto nos lleva a nuestra PoC, que es cómo aplicar todas las arquitecturas al servicio fundamental de la web, y que como veremos es rápido y sencillo, pero será en la segunda parte de este artículo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo funcionan los ataques de DDoS usando "Amplificación DNS" con consultas tipo Root sobre UDP y cómo fortificar el servicio

El uso del protocolo UDP (User Datagram Protocol) para el envío de consultas DNS posibilita el utilizar este servicio para realizar ataques distribuidos de denegación de servicio (DDoS) hacia otros servidores en Internet. Uno de los ataques principales, basado en DNS, es el ataque de Amplificación de DNS o DNS Amplification utilizando consultas de tipo root falsificando la dirección IP de origen, es decir, haciendo un IP Spoofing en el paquete de DNS Request.  

Figura 1: Cómo funcionan los ataques de DDoS usando "Amplificación DNS" con consultas tipo Root sobre UDP y cómo fortificar el servicio

Este tipo de ataques se conocen hace tiempo, y los hemos visto migrados a otras plataformas como LDAP, donde se pueden dar los Ataques DOS con CLDAP (Connectioless LDAP) Amplification, que funciona de forma muy similar. Esto hace que tanto los pentesters y auditores que buscan vulnerabilidades, como los administradores que buscan fortificar los servicios, deban tener en cuenta este tipo de ataques. En FOCA, una de las cosas que miramos es la seguridad de los servidores DNS, ya implementamos hace tiempo otras técnicas como DNS Cache Snooping son también muy útiles en ataques contra infraestructuras empresariales.

Figura 2: Pentesting con FOCA Silver Edition

La principal debilidad en el servicio DNS frente a este tipo de ataques de amplificación tiene su causa en el uso principal del protocolo UDP (User Datagram Protocol) para realizar las consultas DNS. UDP es un protocolo a nivel de transporte donde prima la velocidad de la transmisión y sobre el cual se envía y recibe la información sin que se haya establecido previamente una conexión y sin confirmación ni control de entrega/recepción. 

Figura 3: Ejemplo simple de ataque de DNS Amplification

Esto posibilita la suplantación de direcciones IP (IP spoofing) y la suplantación de mensajes de consulta/respuesta. Aunque DNS soporta el uso de TCP para el envío de mensajes, en las especificaciones de implementación se recomienda, por motivos de rendimiento, usar UDP en las consultas. Se sugiere limitar el uso de TCP para realizar transferencias de zona o para aquellas consultas que superan el tamaño máximo, establecido en 512 bytes en mensajes sobre UDP.

Búsqueda de servidores DNS vulnerables: Primera aproximación

Buscar un servidor de nombres vulnerable a ataques de amplificación de DNS es sencillo: sólo hay que comprobar si la cantidad de bytes de la respuesta del servidor de nombres es mayor al tamaño de la consulta y obligar a que el protocolo para el intercambio de datos sea UDP.

Figura 4: Petición de transferencia de zona utilizando DIG

Una primera aproximación sería utilizar servidores de nombres vulnerables a transferencia de zona para realizar Ataques de Amplificación de DNS que pudieran desembocar en un DDoS: el tamaño en bytes devuelto por el servidor de nombres al conceder la transferencia de zona (1994 bytes en este ejemplo) es superior al tamaño en bytes de la petición de transferencia de zona (112 bytes en este ejemplo).

Figura 5: Transferencia de zona concedida por el servidor DNS vulnerable

Como contrapartida, el protocolo que se utiliza durante la petición y envío de la transferencia de zona es TCP (Protocolo de Control de Transmisión), lo que dificulta en gran media spoofear la dirección IP de origen al ser un protocolo orientado a la conexión y con ello poder amplificar el tamaño de la respuesta del servidor de nombres sobre una víctima.

Figura 6: Protocolo TCP utilizado en el proceso de transferencia de zona

Además, el número de servidores de nombres vulnerables a transferencia de zona seguramente sea menor que el número de servidores vulnerables a la técnica que veremos en la segunda aproximación: consultas de tipo root sobre UDP y los registros de recursos NS (Name Server).

Búsqueda de servidores DNS vulnerables: Segunda aproximación

Parece evidente la necesidad de utilizar el protocolo UDP (no hay un establecimiento previo de la conexión) para poder spoofear las direcciones IP de origen de las peticiones DNS por la dirección de la víctima, y a la par, utilizar un servidor de nombres con capacidad de amplificar el tamaño de las respuestas frente al tamaño de las consultas DNS. Si se dan todas las condicionantes, entonces se podrían utilizar estos servidores para realizar ataques DDoS amplificando el ancho de banda del atacante para tumbar un servidor de red.

Figura 7: Ataques de redes IPv4&IPv6

La idea es sencilla: ¿cómo responderá un servidor DNS cuando se realice una consulta de la raíz (“.”) sobre los registros de recursos NS utilizando el protocolo UDP? Si el servidor de nombres no está bien configurado y es vulnerable a consultas de tipo root sobre los registros de recursos NS utilizando el protocolo UDP responderá con el FQDN (nombre de dominio totalmente cualificado) de los 13 servidores DNS de nombres globales.

Figura 8: Respuesta de un servidor DNS vulnerable a técnicas de amplificación

Se puede observar que el tamaño de la consulta de tipo root son 59 bytes frente al tamaño de la respuesta, 270 bytes, lo que demuestra que el servidor de nombres es vulnerable a técnicas de Amplificación de DNS y podría ser utilizado en un ataque coordinado de DDoS.

Figura 9: Características de la respuesta a la consulta de tipo root

Por el contrario, si el servidor DNS no es vulnerable a esta técnica, la respuesta que devolverá al intentar resolver la consulta “.” sobre los registros de recursos name servers será la siguiente:

Figura 10: Tiempo de espera agotado para la petición de resolución
de la consulta de tipo root sobre los registros NS

Cómo proteger el servidor de nombres

El problema de denegación de servicio (DoS) utilizando Amplificación DNS se debe a la enorme cantidad de servidores DNS presentes en Internet y configurados como Open Resolvers para ofrecer su servicio sin ningún tipo de restricción a cualquier solicitante de Internet. Por eso, es necesario que cada vez que se instale un servidor DNS expuesto a Internet, ya sea sobre plataformas GNU/Linux o Windows Server, deben ser fortificados.

 
Figura 11: Hardening GNU/Linux y Windows Server 2016

Si nuestra organización cuenta con servidores de nombres propios con información de las máquinas que tiene desplegadas en Internet, como primera aproximación basta deshabilitar las peticiones recursivas de los reenviadores a los 13 servidores globales que se encuentran en Internet.

Figura 12: Configuración en Windows Server para no utilizar reenviadores
ni los 13 servidores DNS globales de Internet.
(También hay que hacerlo con los ataques de CLDAP Amplification )

Si un cliente envía una consulta DNS a los servidores de la organización con un FQDN que no se encuentre en su base de datos, el servidor no utilizará los reenviadores para tratar de resolver la petición y la respuesta del servidor será “Se agotó el tiempo de espera de la solicitud a ns.lacomarca.local”. Esta es una comprobación que tanto los equipos Blue Team como Red Team de una empresa deben controlar, y en las distribuciones Kali vienen todas las herramientas necesarias para auditar los servidores DNS de la organización.

Figura 13: Pentesting con Kali Silver Edition

En el caso de que el servidor fuera bind9, dado que las resoluciones recursivas requieren el uso de las sugerencias de los servidores raíz, bastaría con añadir la primitiva “recursion no;” en el fichero “named.conf” e impedir las peticiones de transferencias para cada una de las zonas del fichero de nombres.

Figura 14: Limitación de recursión y zonas

Un administrador podría pensar en eliminar el contenido del fichero db.root en bind9 que contiene los registros de recursos A y AAAA de los servidores DNS raíz y eliminar la referencia a la zona “.” en el fichero global named.conf.

Figura 15: contenido del fichero db.root

Si la zona “.” no estuviera, BIND sigue funcionando al ser compilado con una lista de servidores raíz, por lo que como último recurso siempre dispondrá de una lista interna de servidores raíz, el único inconveniente es que la lista es fija, pero los servidores raíz no suelen cambiar. 

Figura 16: Referencia a la zona db.root que contiene los nombres
y direcciones IP de los 13 servidores de nombres globales

Esta comprobación vista hoy es algo que los pentesters, los clientes zombies de las botnets, y los administradores de open resolvers DNS deben buscar y cuidar.  Se deben administrar los servidores para que no sean utilizados en ataques de denegación de servicio. Entre las tareas que deben contemplarse, están las medidas anti-spoofing, filtrado de tráfico y, técnicas como Rate Response Limit y proporcionar una configuración correcta de consultas recursivas.

Saludos,  

Autor: Amador Aparicio (@amadapa), escritor de los libros “Raspberry Pi para Hackers & Makers: PoCs & Hacks Just for Fun!” y "Hacking Web Technologies 2ª Edición" , CSE (Chief Security Envoy) de ElevenPaths. 

Figura 17: Contactar con Amador Aparicio en MyPublicInbox

2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"

Tengo la suerte de ser un "papaete" que tiene dos niñas que me vuelven loco. Son totalmente distintas, la mayor es "Mi Hacker" y la pequeña "Mi Survivor". Cada una es como es ella. No es fácil encontrar puntos en común en su forma de ver la vida, pero si hay algo que tienen las dos es que les encanta la tecnología.

Figura 1: 2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"

Supongo que su "papaete" habrá tenido algo que culpa, y es que desde muy pequeñas las he expuesto a la tecnología, para que la vivan conmigo. Han estado en robótica y en tecnología desde que eran muy pequeñas. Scratch, Arduino, Lego Mindstorms, o lo que sea. Yo las apunto a cursos, seminarios, les compro libros de programación o simplemente les cuento cosas. Pero no solo eso, también las incito a hacer cosas conmigo en mi trabajo. Y les encanta.

Niñas y Tecnología

No intento que esta forma mía de vivir con mis salvajes deba ser la que se aplique con los niños y niñas. Esta es la forma en la que yo vivo la tecnología con Mi Hacker y Mi Survivor. Con Mi Hacker, en el año 2017, cuando aún no estaba lanzada AURA en ninguno de los países subimos juntos en el "Encuentro de Telefónica". Un acto privado con unas 1.000 personas donde ella hizo una demo completa guiada conmigo de cómo iba a funcionar AURA en la app móvil de Movistar+ en España.

Figura 2: Presentando Aura en Movistar+ en Noviembre de 2017 con Mi Survivor

Y con Mi Survivor, pues ya sabéis que rodé un pequeño anuncio el verano pasado con Movistar Home, dando rienda a su afición al Atlético de Madrid y jugando un rato con ella. Nos lo pasamos genial ese día, y se pasó dos días antes aprendiéndose las frases y repitiéndolas durante horas y horas a todo el que se acercaba.

Figura 3: Movistar Home y SuperCopa de Europa 2018

Y como os podéis imaginar, he estimulado mucho su interés por la tecnología, así que las preguntas que todo padre sufre, yo las tengo que debatir durante días y semanas con ellas. Preguntas que seguro que os suenan a la mayoría.

• Papaete, ¿me dejas el móvil?
• Papaete, quiero un iPhone.
• Papaete, ¿puedo tener Musicali? Los grabo en privado. No, en borradores. Porfi, porfi.
• Papaete, ¿por qué tu tienes Instagram y yo no puedo?
• Papaete, no quiero Youtube Kids, quiero Youtube normal.
• Papaete, ¿qué es esto de TikTok? ¿Y Crush?
• Papaete, ¿puedo buscar en Internet una cosa del colegio?
• Papaete, puedo bajar un jueguecito en el ordenador. Es gratis.
• Papaete, ¿has visto a Momo? En el cole lo han visto todas las niñas…

Y claro, el verano pasado me tenían la cabeza llena de sus peticiones, así que decidí que tenía que hacer algo. Como todo buen investigador de seguridad me he pegado mucho con los ataques de red, y cuando estamos de viaje y hay que usar un ordenador, las redes WiFi me dan mucho miedo. Es lo que tiene haber estado criando y construyendo a nuestra querida Evil FOCA, o de jugar con los servidores Proxy. Ya sean por IPv4 o por IPv6, en cualquier red a la que te conectes puede aparecer un atacante.

Figura 4: Ataques en rede de datos IPv4&IPv6 con Evil FOCA en este libro.

Y como me tenía muy preocupado, empecé a pensar cómo podía vigilar sus conexiones mirando por encima del hombro todo lo que hacían pero sin estar. Y así fue como se me ocurrió esta idea del Second Factor Web Browsing (2FWB) que os voy a contar en esta serie, pero dejadme que lo haga uniendo los puntos de atrás adelante después de haberos explicado el punto de partida. La gracia es poder unir los puntos de cosas que vas dejando en el pasado para poder crear cosas nuevas en el futuro. Como lo que os cuento hoy.

Second Channels que no Side Channel

Recuerdo cuando llegó la primera vez que se me ocurrió empezar a utilizar un Second Channel en un producto. Era el año 2013 y acabamos de terminar nuestra primera patente de un producto que se llamaba en CodeName Path2. Era nuestra primera patente y estábamos construyendo el producto y todos los detalles del servicio que iba a proveer.

Ese Path2 se convirtió a la postre en Latch, y la pregunta que teníamos que resolver era... ¿cómo abrimos y cerramos el pestillo si estamos en una situación en la que no hay Internet? Las soluciones a estos problemas se suelen resolver con algoritmos TOTP generados en el end-point o generados en el bank-end y enviados por SMS, pero yo quería hacer algo distinto. Quería utilizar el canal SMS como si fuera un canal de comunicaciones y permitir que la app siguiere funcionando normalmente enviando "tramas" SMS.

En aquel entonces, haciendo lo que tiene que hacer un equipo de producto, decidimos quitar esa característica del roadmap principal y aceptar que no la teníamos para enfocar los recursos en partes del producto y servicio que consideramos más prioritarias en aquel en entonces.

Pero ni mucho menos se me olvidó.

Tiempo después empezamos a trabajar en la idea de ver cómo podrían funcionar las apps maliciosas en los Identity Providers de Internet para robar los Tokens OAuth y hacer ataques como el de RansomCloud lo que nos llevó a que hiciéramos nuestro querido y famoso SAPPO del que hablamos en la RootedCON 2016 y con el que nuestro amigo Kevin Mitnick asusta a los ejecutivos de todo el mundo en sus charlas.


Figura 5: Kevin Mitnick explicando Ransomcloud
Y fue con esa idea de hacer cosas con los Tokens OAuth la que volvió a tocar en mi cabeza la idea de los Second Channels. Lo que sucedió es que preparando la presentación del MWC de Febrero de 2017 fui a ver UNICEF en New York tras pasar a dar una pequeña charla en la Universidad de Columbia.

Allí nos estuvieron contando cómo el canal SMS era aún una poderosa herramienta para ellos porque en muchos de los países en los que trabajaban, o en muchas situaciones de emergencia, era el único canal de comunicaciones que existía. Inundaciones, corrimientos de tierra, situaciones de emergencia humanitaria por hambre o enfermedad, etcétera.

View this post on Instagram

Explicación de Pigram en uno de mis dibus }:) Mola ver como mis compañeros me ayudan a llevar mis ideas de la concepción al delivery }:)

A post shared by Chema Alonso (@chemaalonso) on Dec 27, 2017 at 9:16am PST

Y a la vuelta, junté a mi equipo de Ideas Locas y les dibujé un pequeño esquema de lo que íbamos a construir. Íbamos a hacer Pigram, nuestro sistema para comunicarse en redes sociales y correo electrónico por medio de un canal SMS y el uso de tokens OAuth.


Figura 7: SafePost, publica en Internet con canal SMS
Con el tiempo tuvimos que cambiar el nombre de Pigram a SafePost, por presiones ajenas que algún día os contaré, pero a día de hoy el servicio sigue estando activo y lanzado en varios países. Y lo más importante, decidimos estandarizarlo y crear un SDK para que cualquier app móvil pudiera utilizar el canal SMS para comunicarse. Hoy en día se llama Stack SMS y tenéis el paper, las herramientas y los vídeos explicativos públicos en la red.

Figura 8: Paper de Stack SMS

Hicimos un juego de prueba con el ahorcado para explicar cómo podía utilizarse, pero durante la última Vuelta Ciclista a España, tras hacer una etapa con el Movistar Team, me di cuenta de que podíamos hacer un sistema de mensajería en grupo basado en Internet+Stack SMS que diera más velocidad y cobertura a las comunicaciones durante carrera por las zonas más inhóspitas de los países, y nació el juguete que enseñamos en Diciembre de 2018.


Figura 9: Movistar Team Chat Room con Stack SMS
Pero aún lo podíamos utilizar para muchas más cosas. El poder contar siempre con un Second Channel tan cómodo, accesible y común como el SMS nos abría muchas posibilidades, y cuando en este Mobile World Congress 2019 nos pidieron alguna charla de seguridad, mis compañeros del equipo de Ideas Locas crearon el IoT AntiDDOS SMS Shield, es decir, una solución de control remoto de dispositivos IoT que estuvieran siendo inhabilitados por un ataque de denegación de servicios.


Figura 10: IoT AntiDDOS SMS(GSM) Shield
Como podéis ver, la idea de utilizar Second Channels ha sido una constante durante los últimos años en nuestro equipo, así que no es raro que apareciera la idea de Second Factor Web Browsing (2FWB) que os voy a contar a continuación. Pero como ha quedado muy largo, dejadme que esto sea en la siguiente parte del artículo.

Saludos Malignos!

*****************************************************************************************
- 2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"
- 2FWB: Second Factor Web Browsing [Parte 2 de 4] "Network Attacks"
- 2FWB: Second Factor Web Browsing [Parte 3 de 4] "2FWB Mobile App"
- 2FWB: Second Factor Web Browsing [Parte 4 de 4] "Modo Centinela"
*****************************************************************************************

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.