Intentando evadir mecanismos y restricciones de Seguridad – Burlando reglas de detección y alarmas de Snort utilizando W3AF – Parte IX

En esta ocasión indicaré el uso de W3AF para evadir sistemas de detección de intrusos y sistemas de prevención de intrusos (IDS/IPS), en este caso concreto, se intentará indicar las pruebas que se han realizado contra Snort ejecutándose como NIDS. Para esto se utilizan técnicas de evasión en W3AF (en algunas ocasiones accediendo y modificando directamente el código del proyecto que se encuentra escrito en Python). Estas técnicas ejecutan procedimientos de evasión partiendo de la base que muchos de los IDS/IPS del mercado detectan amenazas en función a determinadas “firmas” o patrones de comportamiento que son identificados como anómalos o maliciosos. Los “tips” de evasión presentados aquí lo que realmente hacen es modificar las peticiones realizadas a un servidor web para que dichas peticiones no se ajusten a los patrones que esperan los IDS/IPS.

En W3AF, como se ha indicado en entradas anteriores existen diferentes Plugins que permiten realizar determinadas acciones dependiendo de la categoría a la que correspondan, para ejecutar peticiones maliciosas existen los plugins de descubrimiento cuyo único objetivo es el de capturar información que pueda ser utilizada por los plugins de auditoria con el fin de obtener vulnerabilidades que puedan ser explotadas posteriormente por los plugins de ataque. En este caso, los IDS/IPS tienen una mayor influencia en los plugins de descubrimiento, debido a que para su ejecución requieren realizar determinadas peticiones al servidor web objetivo que en muchos casos son fácilmente identificables.

A continuación se indica el comportamiento de Snort ante el uso de algunos Plugins de descubrimiento de W3AF y como se consigue evadir las reglas o preprocessors de Snort con el uso de los plugins de evasión incluidos en W3AF.

NOTA:

Solamente se han probado los plugins de descubrimiento contra el servidor web, no se ha probado contra ninguna aplicación web en concreto, en próximas entradas se realizará este mismo análisis contra una aplicaciones web concretas y se hará mayor énfasis en el uso del plugin Spiderman para descubrimiento de vulnerabilidades en aplicaciones web utilizándolo como proxy.

1. En primer lugar se ha iniciado Snort en una máquina perteneciente al segmento de red, activando todos los preprocessors (incluido en HTTP Inspect).

2. Posteriormente se han probado de forma individual cada uno de los plugins de descubrimiento, con el fin de determinar cuales eran descubiertos por Snort y los mensajes de error/alarmas generadas por este, aquellos que Http Inspect y Snort ha podido detectar los siguientes:
   1. fingerBind:
      Este plugin intenta buscar en internet las direcciones de email bajo el dominio @objetivo.com utilizando el motor de búsquedas Bind. Este plugin es personalizable, se puede indicar el numero de consultas que se pueden realizar, por defecto 300 registros es el limite.
      Snort puede generar alarmas relacionadas con la dirección IP del atacante y el servicio utilizado, similares a la siguiente:

      07/03-19:09:00.991132 [**] [122:3:0] (portscan) TCP Portsweep [**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 212.227.137.179 07/03-19:10:03.313822 [**] [120:3:1] (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE [**] [Priority: 3] {TCP} 82.194.75.23:80 -> 192.168.1.33:55408 07/03-19:10:11.682670 [**] [120:3:1] (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE [**] [Priority: 3] {TCP} 64.235.38.224:80 -> 192.168.1.33:60612 07/03-19:10:19.335798 [**] [120:3:1] (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE [**] [Priority: 3] {TCP} 82.194.75.23:80 -> 192.168.1.33:55483

   2. hmap
      Este plugin intenta ejecutar un comando hmap para determinar el tipo de servidor web remoto, versión y nivel de parche. Este plugin se conecta directamente al servidor web remoto, sin usar ningún tipo de configuración HTTP (como proxy o autenticación).Snort logra generar una serie de alarmas que indican la dirección IP de la máquina origen del ataque y la maáquina objetivo.

      07/03-20:19:58.466918 [**] [1:2001670:3] BLEEDING-EDGE Web Proxy HEAD Request [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 192.168.1.33:58219 -> 192.168.1.34:80 07/03-20:19:58.476359 [**] [119:14:1] (http_inspect) NON-RFC DEFINED CHAR [**] [Priority: 3] {TCP} 192.168.1.33:58227 -> 192.168.1.34:80 07/03-20:19:58.489189 [**] [119:19:1] (http_inspect) LONG HEADER [**] [Priority: 3] {TCP} 192.168.1.33:58234 -> 192.168.1.34:80 07/03-20:19:58.493244 [**] [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [**] [Priority: 3] {TCP} 192.168.1.33:58236 -> 192.168.1.34:80

   1. pykto
      Se trata de una versión de Nikto en Python, aunque es un poco mas limitada que Nikto cumple bastante bien con su cometido, desde W3AF tiene un nivel de personalización de 7 parámetros distintos donde se incluyen los directorios CGI, Admin, pruebas de mutación, etc.

      07/03-22:33:26.556759 [**] [119:14:1] (http_inspect) NON-RFC DEFINED CHAR [**] [Priority: 3] {TCP} 192.168.1.33:57535 -> 192.168.1.34:80 07/03-22:33:27.250161 [**] [122:3:0] (portscan) TCP Portsweep [**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 199.59.149.200 07/03-22:33:41.686111 [**] [119:14:1] (http_inspect) NON-RFC DEFINED CHAR [**] [Priority: 3] {TCP} 192.168.1.33:57552 -> 192.168.1.34:80 07/03-22:33:53.201633 [**] [119:14:1] (http_inspect) NON-RFC DEFINED CHAR [**] [Priority: 3] {TCP} 192.168.1.33:57561 -> 192.168.1.34:80

3. Ahora se indican algunos de los mecanismos empleados para evadir las alarmas que lanza Snort utilizando los plugins con algunas técnicas de evasión que han reflejado buenos resultados para no generar ningún tipo de alarma en el IDS.

fingerBind:

Desde la consola se han indicado los siguientes comandos:

Con esto, Snort no ha podido detectar absolutamente nada, la razón? Simplemente se ha limitado el número de resultados, de esta forma, Snort asume que se trata de una consulta legitima, el problema que se había detectado anteriormente, es que el valor por defecto de la propiedad resultLimit es de 300 lo que hace que el preprocessor HTTP Inspect de Snort genere una alarma por el volumen de paquetes que se manejan entre origen y destino, para el IDS este comportamiento es “sospechoso” y por ende generá una alarma, con menos registros, parecerá como una simple consulta realizada en un momento dado por un usuario, sin embargo, al limitar los resultado, también se limita información potencialmente interesante, por lo tanto es necesario encontrar un punto de equilibrio.

0. hmap
   Snort identifica el uso de este Plugin dadas las características de las peticiones que se realizan, el plugin Hmap no cuenta con demasiadas opciones de configuración por esta razón para personalizar las peticiones que realiza Hmap al servidor web, es necesario modificar un poco el código fuente correspondiente al plugin. (W3AF y sus Plugins se encuentran escritos en Python). Las alarmas generadas se deben a que algunas peticiones GET al servidor web contienen una longitud demasiado larga, por esta razón es necesario “cortarla” indicando un tamaño de cadena mas corto, W3AF tiene un fichero ubicado en <DIR_W3AF>/plugins/discovery/oHmap/hmap.py que contiene todas las secuencias de construcción de las peticiones utilizadas en el plugin Hmap, este será el fichero que se debe modificar. En concreto, las funciones que realizan la construcción del header de la petición y el contenido son: many_header_helper(url,size), large_header_helper(url,size), fake_content_length(url), unavailable_accept(url), el contenido de estas funciones se ha modificado por lo siguiente:

def many_header_helper(url,size):

req = request(url)

for i in range(size):

req.add_header('HEADER'+('0000000000'+str(i)[-5:]), ('0000000000'+str(i))[-5:] )

res = req.submit()

get_characteristics('MANY_HEADER_RANGES', res)

return res.response_code

def large_header_helper(url,size):
 req = request(url)
 req.add_header('LARGE_HEADER', 'b'*size )
 res = req.submit()
 get_characteristics('LARGE_HEADER_RANGES', res)
 return res.response_code

def fake_content_length(url):
 req = request(url)
 req.add_header('Content-Length', '1000')
 req.body = 'qwerasdfzxcv'
 res = req.submit()
 get_characteristics('fake_content_length', res)

def unavailable_accept(url):
 req = request(url)
 req.add_header('Accept', 'qwer/asdf')
 res = req.submit()
 get_characteristics('unavailable_accept', res)

Como puede apreciarse estas funciones solamente incluye parámetros de control que indican el tamaño de la URL, estos parámetros pueden venir de forma estática, es decir desde llamadas incluidas en el código fuente o desde ficheros de perfiles ubicados en: <DIR_W3AF>/plugins/discovery/oHmap/known.servers/ en este directorio se incluyen perfiles para diversos tipos de servidores y plataformas, dependiendo de cada uno de estos perfiles se definen distintos valores que especifican la estructura LEXICA, SINTACTICA Y SEMANTICA, esta estructura es explicada con mayor detalle en el fichero <DIR_W3AF>/plugins/discovery/oHmap/HINDING_GUIDE por defecto en cada fichero de perfil suele indicarse una longitud de 1000 caracteres, lo que desde luego es bastante largo para ser una petición HTTP, por este motivo solamente basta con disminuir este valor para que de esta forma no se generen alertas sobre longitud de petición.

Por otro lado, las reglas Bleedding-Edge que se generaron en Snort utilizando este plugin fueron fácilmente evadidas utilizando una conexión cifrada utilizando protocolo HTTPS, en lugar de utilizar HTTP, de esta forma estas y otras reglas relacionadas no conseguían determinar si se trataba de un ataque real, dado que la conexión entre atacante y víctima se realiza de forma “segura” y todo el contenido viaja cifrado entre ambas máquinas. Esta técnica no solamente aplica para este plugin, de hecho es algo que los atacantes suelen utilizar de modo muy frecuente para evadir IDS/IPS y ejecutar sus actividades de una forma más sutil y menos propensas a ser detectadas por mecanismos de seguridad.

2. pyktoLa razón por la cual Snort logra generar tantas alarmas relacionadas con este Plugin es por las opciones de configuración con las que frecuentemente se ejecuta este Plugin. Por defecto Pykto utiliza ficheros de bases de datos donde se encuentran las pruebas que Pykto realizará de forma automática, estos se encuentran ubicados en <DIR_W3AF>/plugins/discovery/pykto/scan_database.db y <DIR_W3AF>/plugins/discovery/pykto/w3af_scan_database.db Es necesario personalizar el fichero scan_database.db para ejecutar solamente las pruebas que puedan resultar de interés, por ejemplo, si se sabe que el servidor al que se ataca es un servidor Apache, no tiene sentido incluir pruebas destinadas a IIS o inclusive a servidores de aplicaciones IBMWebAS, ademas de esto, algunas de las pruebas hacen que se generen alarmas sobre caracteres que no se encuentran definidos en el estándar RFC, esto se debe a que en algunos casos, HTTP Inspect de Snort puede ser configurado de tal forma que que determinados caracteres en formato hexadecimal generen una alarma de tipo NON-RFC DEFINED CHAR.
   Desde la perspectiva de la persona que intenta defender un sistema, lo mas común es que configure HTTP Inspect utilizando caracteres RFC No estándar y que normalmente se encuentran asociados con ataques contra un servidor web, normalmente estos caracteres son 0x00,0x02,0x03,0x04,0x05,0x06. Por esta razón se recomienda que cuando se utilice Pykto se deben tener estructuras de ataque muy simples en los ficheros *.db de esta forma se logra evadir el IDS para que no genere ningún tipo de alarma.

Finalmente, estas han sido solamente algunas pruebas de penetración y reconocimiento de la plataforma de un servidor web (en este caso concreto Apache) en donde no ha sido necesario utilizar plugins de evasión incluidos en W3AF, sin embargo en próximas entradas se indicará su uso en mayor profundidad ejecutando pruebas de penetración contra una aplicación hospedada en el servidor web, de momento, los avances indicados aquí sirven para entender un poco como funcionan los IDS en materia de ataques contra plataformas web y como pueden evadirse de una forma mas o menos sencilla.