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.
¿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!"
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.
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.
Por último, queremos dejaros un listado de tecnologías utilizadas para el proyecto o hack:
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
 |
| 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
Felicidades por el proyecto y por el tiempo de desarrollo utilizado.
ResponderEliminarMe gustaría saber cuales han sido las razones de utilizar ActiveMQ en lugar de otras posibles alternativas tipo RabbitMQ, ZeroMQ, Kafka, IronMQ o Redis.
Salu2
Hola y muchas gracias por el comentario.
ResponderEliminarDebido a que el tiempo del que disponíamos era bastante limitado, se escogió ActiveMQ porque cumplía holgadamente con todos los requisitos del proyecto y nos permitía utilizar una instalación previa ya configurada y algún código básico ya configurado también, de un desarrollo previo para el productor y los consumidores (Conexión, envío de mensajes, etc).
Al final, se trata un poco de ser prácticos ;-)
Saludos