Whisper Leak: Cómo espiar conversaciones cifradas que se tienen con un LLM y cómo mitigar este ataque con ofuscación

El delicado equilibrio entre seguridad y privacidad siempre está en riesgo de balancearse de un lado a otro. Algunos, sufren cuando la privacidad evita que un malo sea detectado o le dota al atacante de herramientas que puede explotar, mientras que la seguridad puede estar tentada a hacer un uso excesivo de sus capacidades de vigilancia y tornarse en un déspota que aproveche esa posición de poder para degenerar en algo más allá que proteger a las personas. Este debate, en el mundo tecnológico, lo hemos tenido siempre.

Figura 1: Whisper Leak: Cómo espiar conversaciones cifradas

que se tienen con un LLM y cómo mitigar este ataque con ofuscación

En el caso de las conversaciones vía Prompt que se tienen con un LLM, la industria está investigando cuáles son esas medidas de privacidad y vigilancia, y cuál es el equilibrio que existe entre ellas. En el caso de los Prompts y las respuestas enviadas a un modelo LLM, utilizamos criptografía donde ciframos con TLS los datos enviados y recibidos, y asumimos que si un atacante es capaz de acceder a esa información, no podrá descifrarla.

Figura 2: Hay que asumir que el atacante puede acceder al tráfico cifrado

Dejando al margen que el atacante pueda esperar a la llegada de los ordenadores cuánticos y esté utilizando una estrategia de Harvest-Today-Decrypt-Tomorrow, - ,motivo por el que habría que cifrar toda esa comunicación con algoritmos de Post-Quantum Cryptography, la pregunta que se hacen los investigadores es, ¿es posible sabe de qué están hablando un LLM y un usuario - o un Agentic AI - solo con las cadenas de datos cifrados intercambiados entre ellos?

Figura 3: Quatum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica. 

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

La respuesta a esta pregunta ya la vimos en el trabajo del año pasado de "What Was Your Prompt? A Remote Keylogging Attack on AI Assistants" del que os hablé en el artículo de "Ataque de Side-Channel a conversaciones con ChatGPT, CoPilot y otros LLMs" donde los investigadores aprovechaban los datos de cifrados de las conversaciones que se tenían con diferentes LLMs para pasarlos por un Clasificador de Machine Learning que, mirando los tamaños y las conversaciones, el número de conversaciones, y los tiempos entre ellas, era capaz de clasificar los tipos de conversaciones con una muy precision.

Figura 4: Un clasificador de Machine Learning detecta los temas por

los tamaños y tiempos de conversaciones de datos cifrados

Investigadores de Microsoft, este mismo mes, han publicado un trabajo titulado: "Whisper Leak: A side-channel attack on Large Language Models" que ahonda en esa idea, añadiendo nuevos puntos de información para hacer el clasificador de Machine Learning mucho más poderoso. En este caso han añadido las secuencias de tiempos de las conversaciones, que al final son un proxy al Thinking Time. 

Figura 5: Whisper Leak: A side-channel attack on Large Language Models

Con estos datos añadidos al clasificador, lo que sucede es que detectar que se está hablando de un topic vigilado, por ejemplo "Money Laundary" es mucho más efectivo, incluso si las conversaciones tienen entre medias intercambios ruidosos de temas no relaciones.

Figura 6: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Esto abre un nueva de vigilancia a escala. Imaginemos que una organización quiere vigilar a todos los empleados de una organización quién está hablando de un tema, o aún más locura, imaginemos que un gobierno déspota quiera controlar todas las conversaciones a nivel de un país y saber quién está hablando de un determinado tema. Incluso con sistemas de cifrado, con un clasificador de Machine Learning analizando los datos encriptados de la comunicación TLS entre los ciudadanos y los modelos LLM transferidos podría llegar a saberse quién está hablando de qué. En el trabajo utilizan, para aumentar la efectividad del clasificador lo siguientes datos:

• Token Lenght Side Channel: En el trabajo de "What Was Your Prompt? A Remote Keylogging Attack on AI Assistants" demostraron como se podía inferir la longitud del token a partir de la longitud de los datos cifrados.

• Timing Sequences: En este caso, se basan en el trabajo de "Remote Timing Attacks on Efficient Inference" que demuestra que dependiendo de los tiempos de respuesta se puede inferir los temas de los que está tratando una conversación. Al final, el tiempo de respuesta es un proxy al tiempo de componer la repuestas (Thinking Time) y puede ser utilizado para clasificar los temas con un modelo de Machine Learning.

• Timing Sequences para contar Tokens: Las secuencias de tiempo no solo se pueden utilizar para inferir los temas, sino que también se pueden utilizar para inferir el número de los tokens que se están intercambiando, que por ende - el número de tokens - son también una inferencia del tema que se está tratando, como explica el trabajo de "Time Will Tell: Timing Side Channels via Output Token Count in Large Language Models"

• Timing Side-Channel via Cache Sharing: El último de los trabajos que exploró el uso del tiempo como Side-Channel para filtrar información es el de "InputSnatch: Stealing Input in LLM Services via Timing Side-Channel Attacks" que se aprovecha de las optimizaciones de caché que muchos LLM utilizan para optimizar los resultados. Al final, se puede hacer un Cache Snooping basado en el tiempo de respuesta. Es decir, el usuario hace peticiones que llevan tiempo responder, y el modelo almacena esos tokens en la caché que luego reutilizará si alguien pide esa misma información. Midiendo los tiempos de respuesta de temas que deberían ser largos se puede saber si ese tema ha sido preguntado cuando el tiempo de respuesta sea corto.

Utilizando todos estos estudios, los investigadores han construido un clasificador de Machine Learning que consigue unos resultados de acierto altísimo para saber cuándo una conversación ha tenido que ver con un determinado tema para el que ha sido entrenado. En el experimento han utilizado tres diferentes arquitecturas para entrenar el modelo de inferencia, basadas en LightGBM, en LSTM y BERT, y los resultados de detección de un determinado tema entre conversaciones que no tienen nada que ver con ese tema son altísimos.

Figura 7: Ratio de detección de un tema concreto en conversaciones con ratio 10.000-1

noise-tema objetivo tras cinco intentos frente a diferentes modelos LLMS

Claro, llegado a este punto, estamos en la dicotomía de elegir entre Privacidad y Seguridad. Se podría utilizar esta capacidad también para atrapara a los malos, pero el balance es que tendríamos que poner en riesgo la privacidad de todas las personas para algo que, al final, dejaría de ser efectivo, porque... ¿utilizaría el malo este sistema de comunicaciones si supiera que le pueden detectar? La respuesta es no, y por el camino todos los ciudadanos quedarían expuestos. Por eso, los investigadores proponen añadir medidas de protección contra este tipo de inspección basadas en tres formas de ofuscación.

Medidas de mitigación

La primera de las opciones que proponen es hacer un Random Padding para evitar que la longitud de los tokens que se envían sea constante y repetible, esto es algo que mis compañeros Celso Martinho y Michelle Chen explicaban cómo los habían añadido a las capacidades de Cloudflare para despliegue de Servicios con nuestra AI Security Suite. Lo tenéis explicado en el artículo de "Mitigating a token-length side-channel attack in our AI products".

Figura 8: En el despliegue de Cloudflare se añade el padding en la propiedad "p" como se

explica en el artículo de "Mitigating a token-length side-channel attack in our AI products".

La segunda de las propuestas es hacer Token Batching, o lo que es lo mismo, agrupar aleatoriamente grupos de tokens, lo que reduce drásticamente la observabiliadad del número de tokens y el tamaño de las conversaciones. Esto dificulta la efectividad del clasificador de Machine Learning, y por lo tanto ayuda a la privacidad.

Figura 9: Tokens de ofuscación en respustas de microsoft-gpt-4o

La tercera es hacer Packet Injection y meter aleatoriamente tokens sintéticos en el medio de las conversaciones para ofuscar la conversación. De nuevo, el objetivo es cambiar el número de tokens para hacer más difícil la labor de la clasificación.

Figura 10: Eficacia de las medidas de mitigación propuestas

Con estas protecciones, se puede ver cómo los ratios de mitigación permiten tener sistemas que reducen la efectividad del ataque en más de un 90%, por lo que deberían ser desplegadas cuanto antes en cualquier servicio que se despliegue utilizando LLMs.

Figura 11: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

On-the-fly: Una nueva herramienta para auditar redes TI, IoT & ICS

En el equipo de Ideas Locas tenemos algunas sorpresas para estas semanas. Una de ellas es la publicación de una nueva herramienta denominada on-the-fly, la cual ya está disponible en su Github. Pronto anunciaremos algo más sobre un par de herramientas y algunos sitios donde se podrán ver y donde realmente se darán a conocer. 

Figura 1: On-the-fly. Una nueva herramienta para auditar redes TI, IoT & ICS

Hoy queremos hablar del trabajo que ha sido sacar esta herramienta. La idea es proporciona una herramienta modular que permita al usuario ir configurando módulos que permitan realizar ataques de redes tanto en el mundo TI, IoT o ICS.

Figura 2: GitHub de OnTheFly

Algo que se debe tener claro es que la utilización de diferentes tecnologías entre estos dispositivos que nos rodean hace que la seguridad sea heterogénea. Cuando se afronta un Ethical Hacking en cualquier entorno, uno de los factores importantes es la red. La red conecta el mundo del Internet de las cosas, el mundo de los sistemas de control industrial y el mundo de las tecnologías de la información.

Figura 3: Libro de Ethical Hacking 2ª Edición

La irrupción del paradigma IoT, la conectividad del mundo OT / ICS y el crecimiento exponencial del mundo TI hacen que el pentester requiera conocer todos estos espacios para poder trabajar acorde a lo necesario. Una herramienta que centraliza diferentes técnicas de evaluación de vulnerabilidades o debilidades en una red es un concepto interesante. Dándole el concepto de modular se consigue lograr varias cosas:

1. Que cualquier usuario de la comunidad (hay que recordar que la herramienta es Open Source) puede colaborar y ampliar las posibilidades de ésta, gracias a la implementación de un módulo. 

 

2. Disponer de diferentes técnicas modernas para llevar a cabo este tipo de evaluación y que fácilmente sea ampliable. 

 

3. Lectura y entendimiento sencilla para poder implementar módulos y compartirlos con la comunidad.

Según podemos encontrar en el artículo de presentación de la herramienta: 

“La herramienta ‘on-the-fly’ es un framework que proporciona funcionalidades para llevar a cabo tareas de pentesting en redes de datos en entornos IoT, ICS y TI. La herramienta permite ejecutar diferentes acciones de forma simultánea y de forma modular, simplificando el encadenamiento de acciones y otorgando la posibilidad de realizar diferentes ataques simultáneos.”

Figura 4: Artículo de "on-the-fly"

‘on-the-fly’ tiene una arquitectura modular y dispone de más de 40 módulos con funcionalidades para el pentesting en entornos IoT, ICS & TI. Esto es algo interesante, ya que cualquier usuario podría ampliar la base de conocimiento de la herramienta. La arquitectura de la herramienta es la siguiente:

Figura 5: Arquitectura de "on the fly"

A continuación se enumeran los tipos de módulos principales:

Figura 6: Módulos de 'on-the-fly'

- Discovery: En este tipo de módulos se pueden encontrar funcionalidades para descubrir diferentes tipos de servicios y máquinas. Se utilizan diferentes protocolos: Modbus para descubrimiento ICS, TCP para descubrimiento de servicios y máquinas, MDNS y SSDP, etcétera.

- Manipulation: Este tipo de módulos permiten manipular ‘al vuelo’ (on-the-fly) el tráfico que pasa a través de la máquina. Son módulos especializados en cambiar valores que pueden observarse y manipularse. Permiten obtener ventaja, por ejemplo, manipulando las consultas a una base de datos y consiguiendo acceso.

 

- Server: Este tipo de módulos proporcionan al pentester la posibilidad de levanar un servicio o servidor y disponer de un servicio fake sobre SSDP, MQTT o DNS, por ejemplo.

- Spoof: Este tipo de módulo permite llevar a cabo ataques de spoofing entre diferentes máquinas. Por ejemplo, se puede hacer los clásicos ARP Spoofing, DNS Spoofing o NTP Spoofing, pero también ataques de spoofing en COAP y MQTT (IoT) y en Modbus (ICS).

- Pivot: Este tipo de módulo permite utilizar ‘on-the-fly’ como herramienta para pivotar en un pentest. Permite utilizar SOCKS4 y un port-forwarding sobre TCP para redirigir el tráfico. Una funcionalidad necesaria para el pentester.

- Sniffer: Este tipo de módulo permite llevar a cabo un ‘sniffing’ de paquetes. Hay módulos que vienen preparados para ‘sniffar’ tráfico concreto, y otros módulos permiten configurar qué se quiere sniffar, cómo y dónde almacenarlo.

- Examples: Este tipo de módulo muestra ejemplos de implementación de un módulo. Esto sirve para que un usuario pueda crear de manera sencilla su propio módulo con la funcionalidad que quiera.

Los comandos disponibles en la herramienta ‘on-the-fly’ son los siguientes que puedes ver en la siguiente captura. De ellos, el comando jobs muestra los módulos que generan ‘hilos’ y están en ejecución. Desde este comando podemos ‘terminar’ un módulo cuando se quiera. ‘on-the-fly’ tiene un sistema de gestión de hilos interno para poder ejecutar en background cualquier trabajo y poder finalizarlo cuando el usuario lo requiera.

Figura 7: Comandos de 'on-the-fly'

Esta funcionalidad es la que permite poder cargar diferentes módulos para un ataque de red y poder juntar funcionalidades a través del uso de hilos. La gestión se lleva a cabo a través del comando Jobs.

Figura 8: Descripción de los comandos de 'on-the-fly'

Próximamente hablaremos de cómo hacer un módulo en on-the-fly o ver algunas de las funcionalidades interesantes que podemos encontrar. Es un proyecto en fabricación y que ha visto la luz recientemente. Todos los comentarios de mejora serán bienvenidos. Hay mucho más detalle en su repositorio de Github. Para finalizar, os dejamos con los siguientes vídeos donde se puede ver un ataque de SSDP fake, engañando a los dispositivos de la red tal como se puede ver en el artículo sobre EvilSSDP.

 

Figura 9: Ataque SSDP Fake

Por otro lado, os dejamos un ejemplo de spoofing en Modbus.

Figura 10: Demo de Spoofing de Modbus con 'on-the-fly'

Han sido meses de ir haciendo poco a poco la herramienta, pensar los módulos e ir añadiendo funcionalidades. Todavía queda camino, ya que el proyecto puede acabar con un gran número de implementaciones. Gracias a todos los miembros del equipo que han ido participando en el proyecto. Casi todos hemos pasado por la herramienta para aportar nuestro granito de arena. Pronto más noticias :)

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 11: Contactar con Pablo González

BTLEJack & MicroBit: Tu navaja suiza para los ataques BLE (Bluetooth Low-Energy )

Hace poco mi compañero Álvaro Nuñez me hablaba de este proyecto, llamado BTLEJack, el cual a mí me sonaba de haberlo visto en Defcon. Cuando Álvaro me lo volvió a comentar, le eché un ojo y, en efecto, era el mismo proyecto. El proyecto necesita del uso de una placa MicroBit de esas que la BBC, en colaboración con Microsoft, había llevado a los colegios de UK para que los niños empezaran a programar con Scratch y hacer sus propios juegos en este hardware. Un proyecto interesante.

Figura 1: BTLEJack & MicroBit: Tu navaja suiza para los ataques BLE
(Bluetooth Low-Energy )

Hoy vamos a ver qué es, cuáles son las opciones que nos ofrece y cómo podemos sacarle partido en los proyectos profesionales de Ethical Hacking.

¿Qué es BTLEJack? 

Es un proyecto que permite montar una navaja suiza y utilizar la placa Microbit para poder capturar el tráfico Bluetooth Low-Energy (BLE), hacer hijacking de conexiones, hacer jamming, obtener capturas en PCAP y en otros formatos. Es una navaja suiza para el tema BLE en toda regla. También se puede utilizar un sistema Raspberry PI y otros entornos, en vez de una placa Microbit, pero a mí me gustó el entorno Microbit, debido al contexto del hardware, siempre interesante.

Figura 2: Libro de Haking Ético de Pablo González en 0xWord

Hace un tiempo, estuve jugando con temas de BLE, desde patinetes eléctricos, cepillos eléctricos y los famosos Tags “encuentra-todo”, como se puede ver en este artículo Hacking in your life: jugando con los “encuentra-cosas”.


Figura 3: Enviar comandos BLE a un Tile
Esta herramienta, como ya he comentado anteriormente, es una navaja suiza para realizar diferentes acciones sobre dispositivos que utilicen como mecanismo de comunicación el protocolo BLE (BlueTooh Low Energy). Y si quieres probarla, BTLEJack se puede descargar desde su repositorio en Github.

Figura 4: BTLEJack en GitHub

Proporciona todo lo que se necesita para poder realizar sniffing del tráfico a cualquier conexión o paquetes de “advertisement” que se pueda “escuchar” en el aire. Sería un símil con el modo monitor de una tarjeta WiFi, es decir, podemos escuchar los paquetes que circulan por el aire, orientado a BLE. También se puede hacer “atacar” o hacer DoS sobre conexiones BLE existentes. Por otro lado, también se puede hacer hijacking sobre las conexiones e intentar secuestrarlas. Es un proyecto bastante completo en cuanto a funcionalidades e intenciones.

Nos llamó bastante la atención y tuvimos que probarlo. Hay que indicar que nosotros utilizamos la placa BBC MicroBit con un firmware dedicado, es decir, modificado. Como dije anteriormente, puedes utilizar Bluefruir LE de Adafruit o un kit de evaluación nRF51822. En este enlace se puede ver el firmware compatible y los dispositivos, dentro del propio repositorio de BTLEJack.

Figura 5: Btlejack firmware

BTLEJack soporta BLE 4.x y 5.x. En ésta última versión el soporte es limitado, soportando solo 1 Mbps uncoded y no soporta actualizaciones de los mapas de canales. Los requisitos para poder “jugar” con esta aplicación es una placa MicroBit, aunque se recomienda hasta 3 dispositivos, para obtener una menor pérdida de paquetes. Nosotros hemos probado con 2 placas MicroBit y el resultado es bueno. Es más, con un concentrador USB se pueden poner todas las placas MicroBit bajo el mismo USB, ya que el consumo de éste es muy bajo.

¿Por qué 3 placas? 

Si se conectan tres dispositivos, la herramienta puede sniffar en todos los canales de “publicidad”, es decir, en todos los canales de advertisement. Hay que recordar que los canales de advertisement son el 37, 38 y 39. De esta forma, se tiene más posibilidades de poder capturar la solicitud CONNECT_REQ, necesaria para saber que hay un dispositivo que está iniciando una conexión y poder saltar a los canales de datos.

La instalación de la herramienta es sencilla, simplemente, al descargarla de su Github, se debe ejecutar "python 3.x setup.py install" Esto hará que todo lo necesario se ejecute y se instalen las dependencias necesarias.

¿Cómo se preparan las MicroBit?

BTLEJack dispone de una opción que es la –i, con la que se prepararán todas las placas MicroBit conectadas al equipo. Para ello, utilizará la última versión de firmware disponible. Para capturar el tráfico BLE que hay alrededor nuestro, se puede utilizar el parámetro –c. Este parámetro puede ser configurado para sniffar tráfico de cualquier dispositivo a nuestro alcance, o indicarle qué dirección física queremos escuchar.

Figura 6: Ejecución de btlejack

En la imagen se puede observar la captura del paquete CONNECT_REQ, el cual proporciona información sobre una conexión solicitada y un cambio a canales de datos. Se puede ver también la dirección física del origen y del destino. Esto es útil si luego se quiere filtrar las conexiones y el tráfico.

Para un ejemplo cualquiera, podemos ver cómo en el momento que se obtiene el CONNECT_REQ se obtienen los datos que se están intercambiando. Las preguntas que nos podemos hacer son similares a estas:

- ¿Qué ocurre si uno de esos paquetes de datos provoca que una luz se encienda? 

- ¿Y si hace pitar un dispositivo? 

- ¿Si solicita datos de frecuencia cardíaca? 

Este tipo de sniffing proporciona datos que pueden ser utilizados en ataques de replay, tal y como se vio en el ejemplo de los “encuentra-todo”.

Figura 7: Información del paquete capturado

Para la enumeración de conexiones existentes se puede utilizar la opción –s. Con esta opción se puede ver conexiones existentes y el número de paquetes que se están enviando. Esto es útil para capturar el address access.

Con la opción –f se especifica exactamente la conexión que se quiera sniffar. Paralelizando este proceso con varios MicroBit se obtienen beneficios en lo que a pérdida de paquetes y de posibilidades se refiere. La opción –s y –f se utiliza para conexiones que ya están en uso, mientras que la opción –c es para nuevas conexiones que somos capaces de detectar.

Figura 8: Realizando un ataque de Hijacking de sesiones BLE

Con la opción –t se puede lograr un hijacking de la sesión o conexión en curso. Este proceso puede tardar un poco ya que, si no se indica, se debe calcular el channel map, el hop interval y el hop increment. Otra opción es hacer jamming con el parámetro –j, el cual requiere de una conexión abierta.

A la caja de herramientas

Como se puede ver, es una herramienta interesante para la auditoría de dispositivos IoT que hagan uso del protocolo Bluetooth Low-Energy en los entornos empresariales y personales, que tan de moda se encuentra hoy día. Otra herramienta para meter en la mochila del pentester y del usuario curioso que quiere conocer más sobre BLE y sus posibilidades.

Saludos,

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

LiLaS: Little Latch Snitch o cómo bloquear protocolos de red a través de Latch e IoC’s

La semana pasada tuvimos una nueva edición de nuestro ya famoso hackathon en el que muchos competimos. Nuestro Equinox. Durante esa semana muchos estuvimos pensando que proyecto llevar a cabo. Hay que recordar que hace unos meses os contamos algún hack que hicimos como el Latch’sApp para exfiltrar datos a través del uso de la tecnología Latch. Tras darle alguna que otra vuelta llegamos a una idea interesante y era la posibilidad de bloquear el uso de ciertos protocolos en una red también usando Latch, nuestro pestillo universal.

Figura 1: LiLaS: Little Latch Snitch o cómo bloquear protocolos de red a través de Latch e IoC’s

¿Cómo los podíamos bloquear? Tras darle una pequeña vuelta, lo vimos claro, Latch nos ayudaría a poder bloquear y poder gestionar de forma sencilla el uso de estos protocolos en la red. Por otro lado, otros compañeros comentaron la posibilidad de meter una serie de reglas con las que pudiéramos activar ciertos bloqueos en función de los IoC's (Indicadores de compromiso) que íbamos a definir. Eso hacía que el proyecto fuera bastante interesante y el reto lo teníamos en la mente y era hora de llevarlo a cabo. Así nació el germen del proyecto LiLaS: Little Latch Snitch.

Por desgracia, y por motivos laborales, tuve que dejar a mis compañeros pronto, ya que solo llegué a la cena, completando las primeras 10 horas de Equinox. El resto del equipo formado por Álvaro Nuñez-Romero, Santiago Hernández, Carmen Torrano, José Torres y Félix Brezo se pegaron la gran paliza para completar el proyecto, así que solo les digo: ¡Olé!.

Montando la base

Durante la tarde estuvimos montando la base del proyecto y lo que utilizaríamos para detectar el tráfico y los tipos de protocolos que pasaban por nuestro sniffer o detector de tráfico. El elemento elegido para hacer de detector era una Raspberry Pi 3. Esta RPi3 la configuramos para hacer de punto de acceso WiFi y mediante unas reglas básicas de iptables hacíamos que el tráfico que nos llegaba por la wlan0, gracias a hostapd, pasaran a la cola de NFQUEUE - algo que ya habíamos integrado tiempo atrás con Latch -.

Santiago trabajó duro con Scapy y Tshark para detectar protocolos y diseccionar el tráfico. ¡Qué grande esa modificación de Scapy que se tuvo que hacer durante esa misma tarde! Quizás algún día publiques esa modificación a.k.a "Scapy on the fly, only the RAM!"

Figura 2: Los IoCs definidos para la PoC de LiLaS

Una vez detectábamos un nuevo protocolo de red que circulaba entre la interfaz de red wlan0, es decir, la del punto de acceso y la de eth0, es decir, en el cable, lo añadíamos al servicio de Latch usando Operaciones dinámicas. En ese instante el administrador podría decidir si quiere dejar pasar el tráfico de dicho protocolo o no por el punto de acceso, pudiendo bloquear el tráfico de cualquier usuario de la red por el protocolo. Esto es algo potente, pero queríamos aprovechar esta potencia para mejorarla con los indicadores de compromiso.

Objetivo: Potenciar con IoC’s

Nos preguntamos, ¿y si con los indicadores de compromiso pudiéramos activar automáticamente el bloqueo de un protocolo usando la API de Latch? Esto mejoraría la experiencia de uso del administrador y le dotaría de un “mini-sistema” de monitorización y alerta temprana en el instante que se detecta el posible compromiso.

Para ejemplificar esto, podríamos pensar en un malware que se comunican mediante dominios conocidos como sospechosos o una herramienta que utiliza dominios con subdominios con formatos largos y extraños, por ejemplo, [hash largo].dominio.com, dónde el [hash largo] identifica datos que se están exfiltrando hacia el exterior. En el momento que esto es detectado, somos capaces de identificarlo y bloquear el protocolo que se está utilizando para la actividad sospechosa.

Figura 3: Las operaciones que se crean automáticamente en el Latch de LiLaS

Todo esto, además, se presentó en una intuitiva interfaz web dónde podíamos manejar los diferentes pestillos que identificaban a cada protocolo conocido y ver el estado. Además, podíamos ver si se había activado algún indicador de compromiso y veíamos los diferentes mensajes que nos llegaban y cómo se estaba actuando en consecuencia.

Conclusiones sobre el hack y el proyecto

Este proyecto proporciona una herramienta para que el administrador tenga el control sobre el tráfico que circula a través de la red a nivel de protocolo. Esto hace posible que los protocolos de una red puedan ser bloqueados, en este caso, a través del uso de una herramienta sencilla como es Latch. Para implementar la solución, se analizaron todos los paquetes de red que nos llegaban, ya que, como punto de acceso a la red, podíamos analizarlos todos.

El administrador puede ver toda esta información a través de un panel web o a través de la aplicación móvil de Latch. El usuario puede decidir si desea bloquear el tráfico correspondiente a cada protocolo. Esto podría ser útil en casos de ataques de malware en la red, dónde éste se propaga a través de un protocolo concreto, ya que se puede bloquear fácilmente. LiLaS incorpora también la funcionalidad que permite desviar el tráfico a un sistema experto basado en reglas para inspeccionar, a través del uso de una cola ActiveMQ, la captura de red. Esta cola ofrece una gran posibilidad para encolar millones de flujos de datos sin que el rendimiento disminuya.

El sistema experto está basado en reglas de IoC para evaluar cuando se da una situación o ésta se repite de manera alarmante y poder activar los pestillos de los diferentes protocolos que cumplan la regla o lanzar alertas a un administrador. LiLaS demostró gran velocidad y flexibilidad.

Figura 4: Latch WebHooks

Por último, queremos dejaros un listado de tecnologías utilizadas para el proyecto o hack:

• Scapy, para la administración de red. 

• Webhooks de Latch. 

• Flask, para la interfaz web. 

• Cola de ActiveMQ, dónde los paquetes de protocolo son puestos en cola por un proceso productor y luego son consumidos por el script que analiza ese tráfico encolado. Admite millones de flujos de datos sin disminuir el rendimiento. 

• Nodo TOR, para obtener una dirección IP pública. 

• Hostapd e iptables para hacer de punto de acceso WiFi.

Figura 5: PoC del proyecto LiLaS presentado en Equinox

Quiero dar la enhorabuena a mis compañeros por el triunfo en la categoría “ElevenPaths – Security” y dar mi parte del premio a ellos. Ellos estuvieron las 24 horas al pie del cañón. Como siempre ha sido divertido participar en otro Equinox, aunque solo fuera un rato en comparación con vosotros. Así somos en ElevenPaths, Luca, 4ª Plataforma y Aura, nos divertimos creando y llevando a cabo. ¡Grandes!

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Hacking Windows, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

Bettercap: Una katana para realizar ataques de red

En alguna ocasión os he hablado de MITMf, un framework que implementa diversos ataques basados en interceptar una comunicación y colocarse en medio de ésta. Últimamente están saliendo herramientas que nos ayudan a automatizar y simplificar las pruebas de auditoria de red. Hoy hablaré sobre Bettercap, una evolución de la famosa navaja suiza de red Ettercap que ayuda a implementar los Ataques en redes de datos IPv4& IPv6. Vamos a verlo.

Figura 1: Bettercap, una katana para realizar ataques de red

Bettercap está escrito en código Ruby y se aprovecha de la flexibilidad y potencial de dicho lenguaje. En la propia página de Bettercap se preguntan, ¿Por qué otra herramienta de MiTM? y los propios desarrolladores explican este hecho porque Bettercap es completo, actualizado, modular, portable y fácil de extender por cualquier usuario. Si alguien argumenta que Bettercap es un Ettercap le contestan lo siguiente:

Figura 2: Explicación de por qué utilizar Bettercap

La instalación de Bettercap es realmente sencilla. Tiene dependencias, pero ejecutando gem install bettercap el proceso se lleva a cabo completamente. En caso de necesitar alguna librería se puede utilizar apt-get para completar el proceso. Una vez instalado, dispondremos de un binario, el cual podremos ejecutar.

Figura 3: Instalacion de Bettercap en un Kali Linux 2.0

Una vez instalado, lo mejor es comprobar todas las opciones que la herramienta proporciona. A continuación se pueden ver las opciones por módulos:

• Spoofing.
• Discovery.
• Sniffer.
• TCP-Proxy.
• HTTP-Proxy.
• HTTPS-Proxy.
• SSLStrip.
• HTTP-Server.
• DNS-Server.

Cada módulo dispone de diversas opciones parametrizables, lo cual hace que la herramienta sea flexible y muy potente. Como primer ejemplo, vamos a ver cómo realizar un sniffing básico, almacenando lo que pasa por la interfaz de red en un fichero PCAP. Además, vamos a aplicar un filtro al sniffer mediante el uso del parámetro –P.

Figura 4: Protocolos que pueden analizarse con Bettercap

Los protocolos “filtrables” se pueden consultar en la documentación del sitio web de Bettercap. A continuación se muestran los protocolos que serán tratados por la herramienta:

PoC: Sniffando con Bettercap y aplicando filtros

En esta prueba de concepto se configura Bettercap como sniffer. Se debe indicar al framework que no se quiere realizar spoofing mediante el parámetro –no-spoofing, tal y como se puede ver en la imagen. Si analizamos el tráfico que genera Bettercap, el módulo de Discovery está habilitado por defecto, por lo que veremos cómo se está realizando un ARP Scan de forma constante. Es decir, enviando ARP Request a todas las direcciones IP de la red. En la imagen se puede ver como la herramienta nos indica rápidamente las máquinas con las que tenemos conectividad, esto es debido al módulo de Discovery.

Con el parámetro –L indicamos a Bettercap que “parsée” los paquetes que llegan al equipo, e implícitamente habilita el modo sniffer, el cual se activa con el parámetro –X. Por otro lado, el parámetro –sniffer-output hace que todo lo que llega a la interfaz se almacene en el fichero, en este caso better.pcap.

Figura 5: Bettercap en modo sniffer

En la propia pantalla se puede visualizar las peticiones que se han realizado, aunque todo queda almacenado en el fichero PCAP. El código de colores ayuda a visualizar la información de manera sencilla y útil.

PoC: ARP Spoofing by default

En esta prueba de concepto configuraremos a Bettercap con el módulo de ARP Spoofing y aplicaremos un filtro para poder visualizar el tráfico que sea solo HTTP o al puerto 80 TCP. El escenario propuesto para esta prueba de concepto es el siguiente:

• Una máquina Windows será la víctima.
• Un router con el que la máquina Windows se comunica para enviar peticiones y tráfico hacia a Internet.
• Una máquina con Kali Linux con Bettercap instalado.

Desde Bettercap ejecutamos la instrucción bettercap –sniffer-filter “tcp port 80”. Esto por defecto activa los módulos de Spoofing, Discovery y Sniffer. Hay que recordar que para no habilitar el módulo de Spoofing habría que indicarlo con el parámetro –no-spoofing. El filtro nos permite filtrar la información no deseada y centrarnos en lo deseado, en este caso, tráfico HTTP. Si quisiéramos realizar un ARP Spoofing contra dos máquinas concretas, podríamos utilizar con el parámetro –T la dirección IP a suplantar, por ejemplo –T 192.168.1.35 y con –G 192.168.1.1 indicamos la dirección IP del router.

Figura 6: Ataque de ARP Spoofing con Bettercap

El ataque de suplantación se puede realizar a través de ARP Spoofing o con ICMP Redirect. Con el parámetro –spoofer se puede indicar ARP, ICMP o NONE. Por defecto, si no se indica se lanzará ARP Spoofing. Además, si no se indican direcciones IP a las que spoofear, el ataque se llevará a cabo contra toda la red de ámbito local y todos los equipos que se encuentren disponibles en la red.

PoC: SSL Strip 2 con Bettercap

En esta prueba de concepto vamos a configurar un SSLStrip+ o SSLStrip2 de Leonardo Nve, el cual viene implementado con Bettercap y se puede utilizar de forma muy sencilla, como ya se vio con MITMf en el artículo de “Ataques man in the middle a HSTS: SSLStrip 2 & Delorean”. Bettercap es compatible con el SSLStrip de Moxie Marlinspike, por lo que también se puede utilizar. Configuramos el módulo de Proxy para reenviar todo el tráfico dirigido al puerto 80 a Bettercap, le indicamos el target con el parámetro –T y con el parámetro –P le indicamos que “parsée” las peticiones POST.

Figura 7: Ejecución de bettercap en modo proxy

El parámetro –proxy-module permite inyectar código HTML, CSS o Javascript. Esto es interesante si se quiere modificar el contenido de un recurso, e intentar ejecutar código del lado del navegador tal y como se hacía con el trabajo de "Owning bad guys {and mafia} using Javascript botnets". Un posible objetivo podría ser la inyección de código HTML con intención de lograr un Phishing en la página o conseguir que el navegador realizara peticiones a un recurso externo el cual devolviera un exploit.

En la documentación de Bettercap viene un ejemplo de lo que se verá cuando el Bypass de HSTS funcione. Sabemos que el bypass de HSTS es parcial y que depende de una serie de condiciones, pero si las cumplimos, la eliminación de la cabecera HSTS por parte de Bettercap es fundamental para que nos funcione el ataque. Recordando las condiciones nos encontramos con:

• El navegador Firefox o Chrome no debe tener cacheado el dominio en su caché HSTS, es decir, el Max-Age no debe estar insertado en el navegador. En caso de que esté cacheado durante N segundos, lo que se indique en Max-Age, las peticiones a ese dominio no se realizarán nunca por HTTP, y serán siempre por HTTPS. 

• En el caso de tener cacheado dicho dominio o esté en una lista precargada, podríamos realizar un ataque de tipo Delorean, creado por José Selvi. Con este ataque se busca provocar la caducidad de dichas entradas en la caché del navegador. Este ataque se logra interceptando peticiones NTP de las máquinas y llevándolas hacia el futuro.

Figura 8: Ataque de HSTS bypass cambiando el dominio de la víctima

En la imagen se puede ver cómo Bettercap muestra “Found stripped HTTPS link”. El módulo de SSLStrip está funcionando y podemos ver cómo todo pasa por nuestro Proxy, el cual hemos arrancado con el parámetro –proxy. Es fundamental el cambio de las “www” a las “wwww”. Estamos apoyándonos en un servidor DNS que está devolviendo la dirección IP del mismo Facebook en este caso.

Figura 9: Ataque ejecutado con éxito saltándose el sistema HSTS

Si analizamos las peticiones POST nos encontramos con información jugosa. Por ejemplo, SSLStrip+ nos ha funcionado y vemos como el usuario introdujo su dirección de e-mail y su contraseña “dadada”. Las peticiones pueden verse en texto plano, cuando en un uso normal estarían protegidas bajo HTTPS, pero de esta forma tenemos acceso al contenido.

Figura 10: Captura de credenciales en texto plano

Conclusión final

Bettercap es una herramienta llena de posibilidades con la que podemos realizar gran parte de los ataques de red modernos y que permite ser ampliada de forma sencilla gracias al lenguaje sobre el que está programada. Sin duda, Bettercap es una de las herramientas que debemos llevar en la mochila en una auditoria interna y/o de red.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”

Hackear un Moodle con Network Packet Manipulation

El siguiente ejercicio trata de explicar cómo se puede hackear un servidor Moodle mediante la utilización de la técnica de ataque de Network Packet Manipulation, tal y como ya se ha visto con WordPress, con la que se pueden modificar las consultas a MySQL al vuelo cuando las conexiones a la base de datos no están cifradas. Es bastante común que la aplicación web y la base de datos que utiliza dicha aplicación web estén instaladas en la misma máquina, sí, pero en muchos caso - sobre todo en entornos corporativos - estas dos capas están separadas.

Figura 1: Hackear Moodle con ataques de Network Packet Manipulation

Lo primero que se debe hacer es analizar las consultas de Moodle y conocer un poco como gestiona éste su base de datos. En este caso el proverbio “ten cerca a tus amigos para cerca aún a tus enemigos” recobra un poco valor a la inversa, es decir, tenemos que estar lo mas cerca posible de nuestra víctima en el sentido de que debemos conocerla a la perfección para poder llevar a cabo el ataque de forma sencilla y con éxito. En el escenario para las pruebas de concepto están como sigue el esquema siguiente:

Figura 2: El servidor Moodle y la motor SGBDR de MySQL se conectan vía red

Para ello se ha estudiado qué tablas hay en la base de datos que utiliza una aplicación Moodle y cuáles nos podrían interesar. Como en este caso queremos hacernos con el control del Moodle, lo que necesitaremos es saber dónde se aloja la información de los usuarios registrados en el sistema y de qué manera. Investigando un poco nos encontramos con que los usuarios se guardan en la tabla siguiente:

Figura 3: Tabla de usuarios en Moodle

Una vez que se sabe qué tabla queremos adulterar debemos saber qué tipo de datos se guardan en ella, es decir, debemos conocer su esquema y qué columnas son las que nos interesan y cuáles no.  Se hacen resaltar los datos que quizás nos puedan interesar más, aunque podemos ver la cantidad de columnas que tienen la tabla que gestiona los usuarios en Moodle.

Figura 4: Columnas de la tabla mdl_user

La tabla sigue a continuación con el resto de columnas menos relevantes a la hora de llevar a cabo el objetivo fijado. Se observa la cantidad de datos que puede llegar a guardar Moodle sobre los usuarios de su sistema, hasta 53 columnas que, en un ataque similar podrían modificar cualquier situación, dato personal o privilegio de un usuario.

Figura 5: Hasta 53  columnas en la tabla mdl_user

Ahora que ya sabemos todo lo necesario sobre la tabla que queremos atacar, debemos analizar las consultas que realiza Moodle sobre su base de datos MySQL. Como podemos observar con el analizador de tramas de red Wireshark, el tráfico va en texto plano porque no estamos utilizando una conexión cifrada, por lo si utilizamos la técnica Network Packet Manipulation podremos modificar las consultas y tomar el control de la máquina.

Figura 6: Consultas de Moodle a MySQL en texto plano

El siguiente paso a realizar sería acceder al panel de control de Moodle y ver qué tipo de peticiones realiza cuando accedemos a la gestión de usuarios. Es decir, debemos entender el conjunto de consultas que realiza Moodle al SGBDR MySQL cuando creamos un nuevo usuario o modificamos el valor de alguno ya existente.

Figura 7: Gestión de usuarios en Moodle

Se debe de analizar las peticiones minuciosamente para encontrar la consulta en la que se realiza la inserción del nuevo usuario ya que hay multitud de ellas en el intervalo de tiempo entre la conexión al servidor MySQL y la desconexión. La instrucción elegida para esta demo en cuestión es una query SQL del tipo INSERT INTO en la tabla mdl_user y se le pasan los parámetros correspondientes recogidos del formulario web rellenado. Podríamos haber utilizado cualquier otra y modificarla completamente, pero para este ejemplo vamos a usar directamente la de inserción de nuevos usuarios. Después de analizar bien las consultas damos con ella, y es la siguiente:

Figura 8: Captura del INSERT INTO de un nuevo usuario

No cabe entera en la pantalla por lo que aquí se muestra en un editor de texto cualquiera para poder analizarla. Hay que recordar que son 53 columnas las que tiene la tabla y muchas de ellas están definidas como Not Null:

Figura 9: Consulta completa para dar de alta un nuevo usuario en Moodle

La idea principal es capturar un paquete, el cual sepamos que va a existir y modificar la consulta que lleva por la que nosotros queramos, por ejemplo una consulta UPDATE que permita modificar la contraseña o algún dato de un usuario existente con el fin de robar una cuenta.

Procedemos a ver como se podría cambiar cualquier dato de un usuario registrado en el sistema. Para realizarlo podemos crear filtros con Etterfilter. El primer filtro que se creará será el que nos posibilite cambiar la ciudad de un usuario registrado en Moodle - de forma análoga se podrá hacer para cambiarle la contraseña -. Para ello la sentencia que debemos tener en mente será:

“UPDATE mdl_user set city = 'hack3d' where username = 'zweig'”

Antes de crear el filtro debemos hacer hincapié en que los paquetes enviados a MySQL tienen el campo llamado Packet_Length, que le indica al motor de MySQL cuántos bytes debe leer y ejecutar en la base de datos. Por lo tanto, debemos localizar la consulta que sepamos que va a realizar Moodle, la cual será nuestro objetivo a adulterar, y deberemos modificar también su Packet_Length con el tamaño de nuestra consulta.

La consulta que se ha elegido como objetivo para inyectar nuestra propia consulta es la siguiente, aunque después de un análisis de las consultas podríamos haber usado un montón más que se repiten cada vez que Moodle interactúa con su base de datos:

Figura 10: Consulta elegida con Packet Length de 43 bytes

Se puede ver que su Packet_Length es de 43, el cual en hexadecimal es 2b. La consulta que queremos inyectar en el paquete es la siguiente:

UPDATE mdl_user set city = 'hack3d' where username = 'zweig'

Esta consulta tiene un tamaño de 61, que en hexadecimal es 3d. Con toda esta información ya podemos pasar a elaborar el siguiente filtro:

Figura 11: Filtro creado para modificar la consulta original a Moodle

El filtro detecta si el paquete esta destinado al puerto 3306, que es el que esta utilizando MySQL por defecto, luego decodifica el mensaje filtrando por la palabra SET SESSION. Una vez se cumplan estas dos condiciones, lo primero que hace es reemplazar el Packet_length, en el caso del paquete seleccionado es \x2b\x00\x00, por el tamaño de la que queremos inyectar, es decir \x3d\x00\x00. Después pasamos a modificar la ciudad de un usuario en concreto, al cual le pondremos como ciudad “hack3d”. De la misma forma que se puede hacer sobre ciudad lo podríamos hacer sobre cualquiera de las columnas de la tabla mdl_user. Una vez que ya tenemos el filtro llega el momento de compilarlo mediante la instrucción:

etterfilter -o md.ef2 mdl.filter2

Antes de lanzarlo, podemos echar un ojo a la tabla en cuestión de la base de datos, para comprobar el valor que tiene la columna y poder verificar si el filtro ha tenido éxito o no en nuestra prueba:

Figura 12: Ciudad antes de ejecutar el ataque

Una vez que el filtro esta compilado llega el momento de usarlo con Ettercap para realizar el ataque de MiTM entre el servidor web donde corre Moodle y el servidor donde corre el SGBDR MySQL mediante la instrucción:

ettercap -T -q -i -F mdl.ef2 -M ARP

Ahora lo lanzamos el ataque y esperamos a que Moodle interactúe con su base de datos MySQL y listo.

Figura 13: Ataque realizado

Vemos como Ettercap ha detectado un paquete que cumple con condición que le pusimos en el filtro y ejecuta los dos reemplazos programados. Volvemos a mostrar la base de datos y observamos como la columna ciudad del usuario víctima ha sido cambiada.

Figura 14: Dato cambiado en la base de datos de MySQL

Creación de un usuario en Moodle con Network Packet Manipulatrion

Una vez que ya hemos entendido los ataques podemos acabar por hackear el servidor. Para finalizar la prueba de concepto completamente nos crearemos un usuario de Moodle administrador a nuestros gusto. Para ello utilizaremos el siguiente filtro:

Figura 15: Creación de un nuevo usuario en Moodle con Network Packet Manipulation

Se ha hecho de forma análoga al anterior, esta vez el tamaño de nuestra consulta es de 230, por lo tanto remplazaremos el tamaño del original por \x6e\x00\x00. Siguiendo todos los pasos anteriores (compilación del filtro y uso del mismo con Ettercap) podremos ver el resultado en la siguiente imagen, donde hemos obtenido un nuevo usuario llamado deadp00l con la contraseña hasheada. En este momento el pentester tendrá acceso al panel de Moodle con este usuario recién creado.

Figura 16: Usuario creado correctamente en Moodle

Defensa en Profundidad en Moodle

La conclusión final es que no solo es importante que el Moodle este debidamente fortificado en cuanto a los permisos de los usuarios dentro de la plataforma, sino que para casos en los que el escenario sea como el mostrado en esta prueba de concepto se deberán cifrar las consultas SQL que se realicen contra el SGBD, en este caso MySQL, de forma análoga a como se explicó en este artículo con WordPress, ya que si una persona con intenciones poco benévolas se cuela en medio de la comunicación todo el servidor Moodle podría quedar a su merced.


Figura 17: Proteger cuentas de Moodle con Latch
Al final, mantener un escenario seguro de Moodle implica muchas cosas, no solo estas tareas explicadas en este artículo, sino realizar una fortificación completa del servidor GNU/Linux donde corra Moodle y aplicar fortificación de las cuentas de usuario, usando contraseñas robustas y segundos factores de autenticación como Latch para Moodle. La seguridad de un sistema exige aplicar protecciones a todos los niveles y que la cadena no se rompa por el menos seguro de ellos.

Autor: Jesús Largo Antón
Alumno del Master de Seguridad de la UEM