¿Cuántos de nosotros hemos utilizado la red TOR o un proxy anónimo para navegar de forma anónima? Y, ¿cuántos hemos tenido en cuenta que las peticiones DNS que realiza nuestra máquina puede que no sean enrutadas a través de la red TOR? Este simple descuido puede ser usado para identificarnos mediante algún tipo de correlación. Por ejemplo, un usuario que ha hecho consultas DNS de un dominio que posteriormente ha sido atacado a través de TOR. Aunque es complicado llegar a esta situación, puede darse el caso.

Actualmente es posible utilizar el propio cliente de TOR para enrutar las peticiones a través de esta red, u otras herramientas como dnsmasq, que actúa como un proxy capaz de redirigir las peticiones DNS a través de una red determinada. Aun así, las peticiones DNS realizadas no están cifradas, algo totalmente deseable. De esta forma, da igual si las peticiones son capturadas, ya que seguiremos manteniendo el anonimato sobre las consultas realizadas.

[Read more…]

El pasado día 16 de Enero, @breenmachine hizo público un POC para realizar una elevación de privilegios en sistemas y servidores Windows 7 y Server 2008 respectivamente en adelante. El ataque está basado en otra idea original del equipo Google Project Zero. Esta escalada de privilegios se consigue aprovechando varios errores de diseño anteriormente conocidos de los protocolos NTLM, NBNS, SMB y WPAD.

Básicamente, el ataque se divide en las siguientes fases:

[Read more…]

En el capitulo anterior analizamos la función IsDebuggerPresent() de la API de Windows, jugamos con el crackme en OllyDbg y vimos como hacer un bypass de esta función para lograr nuestro objetivo.

En esta entrega vamos a ver otra técnica que se basa en el chequeo del campo NtGlobalFlag del PEB (Process Environment Block).

El valor de NtGlobalFlag viene determinado por el valor de los siguientes flags:

• FLG_HEAP_ENABLE_TAIL_CHECK
• FLG_HEAP_ENABLE_FREE_CHECK
• FLG_HEAP_VALIDATE_PARAMETERS

[Read more…]

Cuando pasas mucho tiempo analizando muestras de malware empiezas a darte cuenta de que cada vez es más frecuente encontrarte con técnicas anti-sandboxing y anti-debugging. Estas técnicas tienen como finalidad proteger la muestra ante los análisis de malware dinámicos y evitar que su comportamiento sea estudiado.

Las técnicas anti-sandboxing se basan en encontrar alguna traza de información clave del sistema donde se está ejecutando. Esta información debería ser exclusiva de sistemas virtualizados, por ejemplo, claves concretas en el registro de una máquina virtual Windows, procesos de VMware o VirtualBox, tamaño del disco duro (en máquinas virtuales suele ser menor), etc.

Por otro lado, las técnicas anti-debugging son utilizadas por el malware para detectar si está siendo ejecutado desde un debugger. Generalmente, cuando detecta que es así, realiza acciones distintas al proceso de infección para el que ha sido programado, o bien, finaliza el proceso inmediatamente con el fin de complicar el análisis del mismo.

Muchas veces, ambas técnicas son incluidas en la misma muestra, incluso implementan varios métodos de cada técnica para protegerse mejor ante mirones.

La mayor parte de las técnicas anti-sandboxing pueden ser evadidas fácilmente por un analista de malware, por ejemplo, cerrando los procesos de las “tools” de la máquina virtual, cambiando de plataforma de virtualización, modificando algunas claves del registro, etc. En cambio, engañar al malware para que se ejecute correctamente en un debugger puede ser algo más complicado.

Vamos a detallar brevemente en que consisten algunas de estas técnicas. Además, crearemos pequeños “crackmes” con los que jugaremos a evadir las protecciones. Nosotros vamos a utilizar OllyDbg, pero podéis usar el que más os guste. Podéis echar un vistazo a la web de Ricardo Narvaja, donde podréis encontrar mucha información sobre el uso de este debugger y de cracking en general. Como la mayoría del malware está programado para plataformas Windows, nos basaremos en esta. Todos los que hayáis trabajado alguna vez con debuggers como OllyDbg, WindDbg, Radare o IDA ya sabréis que se requieren conocimientos sobre lenguaje ensamblador y estructuras internas de ficheros, así que os animo a que os documentéis al respecto.

Vamos a comenzar con una técnica anti-debugging muy fácil de implementar, pero también muy fácil de evadir, la función “IsDebuggerPresent”.

IsDebuggerPresent

Es una función de la librería kernel32.dll. Si el proceso está siendo debuggeado, la función devuelve un valor distinto de 0, en caso contrario, el valor devuelto es 0. Es muy fácil de implementar ya que basta con realizar la llamada a la función y comparar el valor devuelto. Podéis ver la documentación oficial aquí.

Esta función lo que realmente hace es consultar el valor del flag “BeingDebugged” del PEB (Process Environment Block), el cual se activa si el proceso está siendo debuggeado. Vamos a ponernos manos a la obra, podéis descargar el binario y los sources (lenguaje C) de este crackme desde mi cuenta de GitHub: https://github.com/reverc0de/saw-anti-debugging.

El código de crackme01_IsDebuggerPresent es el siguiente:

/***************************************************************** 
* File: 	crackme01_IsDebuggerPresent.c 
* Description:  Es un crackme con la proteccion IsDebuggerPresent 
* Author: 	reverc0de 
* Date: 	26/03/2015 
* Github:	https://github.com/reverc0de/saw-anti-debugging	 
*****************************************************************/ 
#include  
#include  

int main(int argc, char **argv) 
{ 
	if (IsDebuggerPresent()) 
	{ 
		MessageBox(0, "Debugger detectado!!","Crackme01 IsDebuggerPresent",MB_OK); 
		exit(0); 
	} 
	MessageBox(0, "Debugger NO detectado!!","Crackme01 IsDebuggerPresent",MB_OK); 
	return 0;		 
}

Si deseáis, podéis compilarlo vosotros mismos en cualquier IDE para Windows como Dev-C++. Si ejecutamos el crackme directamente (crackme01_IsDebuggerPresent.exe), el mensaje es el esperado:

Ahora vamos a cargarlo en OllyDbg y lo ejecutamos con F9. Esta vez, el crackme ha detectado que se esta ejecutando a través de un debugger:

¿Y ahora que? ¿Como podemos saltarnos esta protección? Se puede conseguir de varias formas pero primero, hay que echar un vistazo al código en OllyDbg cuando llama a la función en cuestión:

En el fragmento de código dentro del recuadro rojo encontramos la llamada a la función IsDebuggerPresent.

Después de la llamada tenemos una comparación con TEST del registro EAX. Con TEST comprobamos si el valor de EAX es igual a 0, en cuyo caso el flag ZF se pone a 1 y se ejecutaría el salto ‘JE SHORT‘ a la posición 00401576. Si ejecutamos el crackme paso a paso (F7), podemos ver como EAX tiene el valor 1 en la comparación y el salto no se produce (ZF = 0), continuando con la ejecución de código secuencial.

A continuación nos encontramos con la función MessageBoxA, la cual genera el mensaje que hemos visto anteriormente con el texto “Debugger detectado!!”. Si seguimos analizando unas líneas más, podemos ver como en la posición 00401576, a la cual se accedía desde la operación de salto anterior (JE), se encuentra otra llamada a MessageBoxA, pero esta vez con el texto del mensaje que deseamos, “Debugger NO detectado!!”.

Conseguir que muestre el segundo mensaje y saltarnos así esta protección es tan fácil como sustituir el tipo de salto condicional, por ejemplo, por un salto JNZ, que se produce si ZF = 0, es decir, si el resultado de la comparación anterior es distinta a 0.

Para modificar el código en el debugger, nos situamos sobre la sentencia del salto y pulsamos la barra espaciadora. Se abrirá un cuadro donde tenemos que sustituir JE por JNZ y aceptamos. Si ahora ejecutamos de nuevo el crackme con esta modificación, obtendremos el mensaje que queríamos, ya que esta vez escoge el salto, consiguiendo evadir esta técnica anti-debugging.

Otras formas de conseguir el mismo resultado es modificar el salto condicional por otro incondicional, o modificar el valor del flag Z en la ejecución del salto.

Variaciones de esta técnica anti-debugging puede ser la de consultar directamente el valor del flag “BeingDebugged” del PEB mediante la inserción de código ASM en el propio source del malware. Otra opción es utilizar la función CheckRemoteDebuggerPresent, que comprueba si el debugger se está ejecutando en otro proceso separado,utilizando además, la función IsDebuggerPresent.

Esta técnica anti-debugging es de las más obvias y fáciles de identificar por un analista de malware. En próximos artículos seguiremos jugando con otra técnicas algo más entretenidas así que… ¡empezad a practicar!

Una de las principales vías de infección de malware es a través de documentos ofimáticos. Son un vector de infección muy contundente, sobre todo en ataques dirigidos y campañas de phising.

Estos documentos son manipulados con el fin de esconder en su interior macros, objetos OLE, ejecutables, etc., los cuales, una vez abierto el documento por el usuario, realizan una serie de acciones maliciosas con el objetivo de obtener información con la que poder lucrarse o simplemente provocar daños en el sistema. Generalmente, las acciones llevadas a cabo por este tipo de malware genérico son descargar otro malware desde internet (droppers), explotar vulnerabilidades del sistema, replicarse para asegurarse la persistencia en el equipo, exfiltrar información del usuario, etc.

Una herramienta muy útil para analizar y detectar patrones anómalos en los documentos ofimáticos es la suite “OfficeMalScanner”, la cual podéis descargar desde la web de su autor, http://www.reconstructer.org/.

[Read more…]

En entradas anteriores ya se ha hablado sobre Dionaea, un honeypot de baja interacción que ofrece una gran variedad de servicios de red. El principal problema al que nos enfrentamos a la hora de desplegar un honeypot es como personalizar los servicios emulados para hacerlos indetectables ante herramientas de escaneado. Cuanto más le cueste a un atacante detectar que se encuentra ante un honeypot, más posibilidades tendremos de analizar su metodología, capturar exploits, binarios, etc.

Vamos a instalar Dionaea y modificar algunos de sus servicios para que no sean identificados por el escáner de red más utilizado, Nmap.

Podemos obtener Dionaea desde la página del proyecto. En la propia página se encuentran los pasos necesarios para su instalación. En nuestro caso hemos utilizado Ubuntu 12.04 como sistema operativo base. Los servicios activos por defecto en la instalación del honeypot son:

Una vez instalado Dionaea, lanzamos un escáner con Nmap para ver qué servicios son identificados y asociados con Dionaea gracias a su capacidad de fingerprinting:

# nmap -v -O -sV -sT -sU 192.168.100.10

En el resumen de la salida del escaneado mostrado a continuación se puede observar como algunos de los servicios los ha identificado y asociado a Dionaea. Uno de los primeros pasos en un test de intrusión es el descubrimiento de los activos de una red y sus servicios, por lo que si un atacante analiza la red con Nmap, detectará la existencia de este honeypot y probablemente cese el ataque y no conseguiremos capturar toda la información que quisiéramos.

Nota: La versión de Nmap utilizada es la 6.00. Otras versiones pueden modificar la capacidad de detección en función de las firmas o huellas que incorpore.

PORT     	STATE         	SERVICE      	VERSION 
21/tcp		open         	 ftp		Dionaea honeypot ftpd 
80/tcp   	open          	http		? 
135/tcp  	open          	msrpc		? 
443/tcp  	open          	ssl/https	? 
445/tcp  	open          	microsoft-ds 	Dionaea honeypot smbd 
1433/tcp	 open          	ms-sql-s     	Dionaea honeypot MS-SQL server 
3306/tcp 	open          	mysql        	MySQL 5.0.54 
5060/tcp 	open          	sip          	(SIP end point; Status: 200 OK)
5061/tcp 	open          	ssl/sip      	(SIP end point; Status: 200 OK) 
69/udp   	open|filtered 	tftp 
5060/udp 	open          	sip          	(SIP end point; Status: 200 OK)

Para personalizar los servicios y que no sean detectados por Nmap, primero hay que saber en qué se basa Nmap para identificarlos. Cuando Nmap intenta descubrir el producto que se encuentra tras un servicio, compara las cadenas de respuesta del servicio con los patrones incluidos en el fichero “nmap-service-probes” (localizado en /usr/share/nmap/). En la URL http://nmap.org/book/vscan-technique.html podemos ver el proceso seguido por Nmap para la detección de servicios. Por tanto, si conseguimos identificar y modificar los servicios de Dionaea en función de estos patrones, podemos conseguir que el servicio no sea identificado como Dionaea, o bien simular cualquier otro producto. Por ejemplo, podemos pasar de un servidor Apache a un IIS o un Tomcat.

Vamos a buscar en el fichero nmap-service-probes el servicio FTP de Dionaea y nos encontraremos con la siguiente línea:

match ftp m|^220 Welcome to the ftp service\r\n| p/Dionaea honeypot ftpd/

Esta línea contiene un mensaje de bienvenida característico de Dionaea, el cual es mostrado a un cliente FTP cuando se conecta al servicio y, además, el producto al que está asociado (Dionaea). Por tanto, tendremos que modificar este mensaje para que Nmap no pueda asociarlo a Dionaea. Hay que editar el fichero /usr/lib/dionaea/python/dionaea/ftp.py para cambiar este mensaje.

Este fichero escrito en Python es la implementación que realiza Dionaea de un servidor FTP. Cada servicio implementado por el honeypot se estructura en módulos, algo que va a facilitar bastante la personalización de estos servicios.

Podemos aprovecharnos de las huellas contenidas en el fichero nmap-service-probes y modificar el mensaje para que represente a un servidor ProFTPD, así que vamos a cambiar el mensaje inicial de Dionaea en ftp.py por uno de ProFTPD:

self.reply(WELCOME_MSG, "Welcome to the ftp service")
self.reply(WELCOME_MSG, "ProFTPD 1.2.8 Server")

El siguiente servicio que vamos a modificar es microsoft-ds (SMB/CIFS). En este caso, si buscamos el patrón correspondiente en nmap-service-probes, se puede ver como busca una coincidencia en la respuesta del servidor durante el establecimiento de la conexión. Esta coincidencia o patrón es:

\x00\x34\0W\0O\0R\0K\0G\0R\0O\0U\0P\0\0\0H\0O\0M\0E\0U\0S\0E\0R\0-\0.\0.\0.\0.\0.\0.

Este se corresponde con los campos que representan el nombre del dominio y del equipo, es decir, si el nombre del dominio es WORKGROUP y el nombre del equipo es HOMEUSER-XXXXXX, donde X es cualquier carácter alfanumérico, entonces el servicio es identificado como un servicio de Dionaea.

Para camuflar el servicio de compartición de ficheros e impresoras de Windows, tan solo hay que modificar los valores de los campos OemDomainName y ServerName en el fichero /usr/lib/dionaea/python/dionaea/smb/include/smbfields.py. Vamos a cambiar los siguientes valores y conseguiremos evitar que sea identificado:

OemDomainName: WORKGROUP → MIDOMINIO
ServerName: HOMEUSER-3AF6FE → EQUIPO-TEST	 

El tercer servicio identificado es el sistema de base de datos Microsoft SQL Server en el puerto 1433. Si buscamos este servicio en el fichero de patrones de Nmap, se puede ver una cadena en hexadecimal:

match ms-sql-s m|^\x04\x01\x00\x2b\x00\x00\x00\x00\x00\x00\x1a\x00\x06\x01\x00\x20\x00
   \x01\x02\x00\x21\x00\x01\x03\x00\x22\x00\x00\x04\x00\x22\x00\x01\xff\x08\x00\x02\x10
   \x00\x00\x02\x00\x00| p/Dionaea honeypot MS-SQL server/ 

Esta cadena se corresponde con la respuesta del honeypot a un paquete TDS (Tabular Data Streams) de pre-login en el proceso de conexión al servicio de base de datos. Si se realiza una captura de paquetes con un sniffer y analizamos las conexiones, podemos ver como esta cadena es la correspondiente al campo Token Type (en codificación hexadecimal) que tiene el valor 0x00.

Si cambiamos el valor 0x00 del campo Token Type, conseguiremos evitar la detección ante un escaneo de Nmap. Este campo se modifica en el fichero /usr/lib/dionaea/python/dionaea/mssql/mssql.py. Vamos a cambiar el valor establecido por 0xAA, que se corresponde con un mensaje de error, aunque podemos poner cualquier otro. Una lista de los valores aceptados para este campo los podemos encontrar en FreeTDS.

r.VersionToken.TokenType = 0x00 → 0xAA

Por ultimo, el servicio HTTPS no es identificado en el escaneo, pero basta con acceder a la URL del servidor web y echar un vistazo al certificado que presenta:

El certificado es emitido por Nephentes Development Team, los creadores del honeypot precursor de Dionaea (Nephentes), además de mostrar la URL del proyecto Dionaea. Así que debemos generar un certificado con algo más de “credibilidad” y sustituir al generado por defecto. Debido a que el certificado es generado en tiempo de compilación, hay que modificar los datos del certificado en el fichero dionaea/src/connection.c antes de compilar el honeypot.

Tras modificar los datos anteriores en los servicios, volvemos a realizar un escaneo de puertos al honeypot:

PORT     	STATE         	SERVICE       VERSION 
21/tcp		open          	ftp		ProFTPD 1.2.8 
80/tcp   	open          	http		? 
135/tcp  	open          	msrpc		? 
443/tcp  	open          	ssl/https	? 
445/tcp  	open          	microsoft-ds	? 
1433/tcp	open          	ms-sql-s	? 
3306/tcp 	open          	mysql         	MySQL 5.0.54 
5060/tcp 	open          	sip           	(SIP end point; Status: 200 OK) 
5061/tcp 	open          	sip-tls		? 
69/udp   	open|filtered	tftp 
5060/udp 	open          	sip           	(SIP end point; Status: 200 OK) 

Como se puede ver, los servicios descritos ya no son identificados como servicios de Dionaea, por lo que hemos conseguido evitar que un escaneo simple de Nmap detecte nuestro honeypot. Si realmente se quiere utilizar el honeypot para detectar ataques no automatizados y engañar a un atacante, entonces habrá que realizar una personalización más detallada de los servicios del honeypot para que generen un entorno mucho más realista y con mayores similitudes al servicio real que se intenta emular.

En esta entrada vamos a presentar un complemento para Nagios llamado Nagmap. Es una herramienta que nos va a permitir representar geográficamente los dispositivos monitorizados en Nagios. Nagmap utiliza la API de Google Maps para ubicar en el mapa los dispositivos a través de las coordenadas de cada uno de ellos. Nagmap se alimenta de los ficheros de configuración incluidos en nagios.cfg y del fichero de estado de los dispositivos status.dat. De estos ficheros obtiene los datos necesarios de cada host o dispositivo y, si tienen la información necesaria, los ubicará en el mapa.

Para que un dispositivo pueda ser representado tiene que tener, al menos, los siguientes campos completados en el fichero de definición de hosts correspondiente de Nagios:

define host{ 
	host_name         localhost 
        alias             localhost 
       	address           127.0.0.1 
        notes             latlng:+41.9031536,-1.726998500000036
	} 

Como se puede observar, el campo “notes” ha sido designado por Nagmap para indicar las coordenadas geográficas de este dispositivo. El formato en el cual hay que indicar las coordenadas para que Nagmap las reconozca tiene que ser:

latlng:latitud,longitud

A modo de ejemplo, vamos a instalar Nagmap en un servidor en el que ya se encuentra Nagios funcionando. Comenzamos descargando Nagmap desde la página de su proyecto. Una vez descargado, descomprimimos el fichero, lo renombramos y lo movemos al directorio correcto del servidor web (Apache).

$ wget https://github.com/hecko/nagmap/archive/master.zip
$ unzip master.zip 
$ mv nagmap-master /var/www/html/nagmap

En este momento ya está disponible a través de la URL que hayamos indicado en la configuración del servidor web:

Como se puede ver en el mapa, han sido dibujados los “markers” o “pinchos” coloreados de cada uno de los dispositivos con información sobre su estado. Además, dispone de un pequeño cuadro de mandos en el “sidebar” con información estadística sobre el estado y, una lista de todos los dispositivos representados.

Supongamos ahora que una empresa tiene cientos de sucursales repartidas por el territorio nacional. Si quisiera visualizar el estado de la conexión a la red de cada una de ellas en Nagmap, la cantidad de “pinchos” dibujados dificultaría una visión clara del estado de las oficinas.

Como posible solución, podemos modificar el código PHP de Nagmap para establecer un filtro de modo que solo muestre aquellas oficinas cuyo estado sea anormal (distinto de “OK”). Esto simplifica enormemente la visualización de aquellas oficinas con problemas de conexión, que realmente son las que nos interesan. Una posible modificación para conseguir este resultado sería modificar el fichero marker.php de Nagmap de la siguiente forma:

File marker.php

line 140 ===	//put markers and bubbles onto a map 
line 146 ---	$javascript .= ("window.".$h["host_name"]."_pos = new ...
line 149 ===	// if host is in state OK 
line 151 ---	$javascript .= ('window.'.$h["host_name"]."_mark = new google.maps.Marker({". 
line 152 ---	"\n  position: ".$h["host_name"]."_pos,". 
line 153 ---	"\n  icon: 'http://www.google.com/mapfiles/marker_green.png',". 
line 154 ---	"\n  map: map,". 
line 155 ---	"\n  zIndex: 2,". 
line 156 ---	"\n  title: \"".$h["nagios_host_name"]."\"". 
line 157 ---	"});"."\n\n"); 
line 159 ---	$sidebar['ok'][] = '<a href="javascript:'.$h["host_name"] ...	 
line 160 ===	// if host is in state WARNING 
line 162 +++	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 171 ===	// if host is in state CRITICAL / UNREACHABLE 
line 173 +++   	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 182 ===    	// if host is in state UNKNOWN 
line 184 +++   	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 194 ===	// if host is in any other (unknown to nagmap) state 
line 195 +++   	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 218 +++	//COMPROBAR SI STATUS != OK, PARA QUE GENERE INFO BUBBLE 
line 219 +++	if ($h['status'] != 0) { 
line 224 +++	}

Tras esta modificación, tan solo se mostrarán en el mapa las oficinas que tengan un estado de error. En el “sidebar” seguirán apareciendo las estadísticas generales pero solo se mostrará el listado de las oficinas con problemas (ha desaparecido “localhost” porque su estado es “OK”).

Como hemos visto, podemos crear vistas personalizadas del estado de los dispositivos de nuestra red, además, puede utilizarse como un cuadro de mandos meramente informativo para los ejecutivos de la empresa si lo personalizamos algo más, por ejemplo:

• Personalizar los “pinchos” con unos diseño más adecuado.
• Incluir un “header” de empresa en la interfaz web.
• Añadir información al globo: dirección postal de la oficina, población, teléfono, etc. (para esto habría que modificar el código para que Nagmap procese los campos correspondientes, al igual que se realiza con “notes”).
• Personalizar las opciones disponibles en config.php de Nagmap : zoom en el mapa, centrado, estilo del mapa (roadmap, satellite, hybrid, terrain).

¡Os animo a que juguéis con la API de Google Maps y con Nagmap, ya que el código es bastante amigable y se pueden hacer cosas muy interesantes!