Técnicas de evasión de IDS 1.

En este capitulo únicamente nos enfocaremos a NIDS y a servidores web (evasión mediante paquetes HTTP especiales).

HTTP Request Smuggling.

Esta técnica ya esta bastante documentada en internet (busquen en google y encontraran muchas webs hablando al respecto) pero vamos a explicarlo un poco y vamos a agregar algunas otras cosas no documentadas, básicamente consiste (tal y como dice su nombre) en enviar una consulta escondida dentro de otra, eso se logra gracias a "HTTP Pipelining" integrado en la versión 1.1 del protocolo HTTP.

¿En que consiste?

Tenemos el encabezado Content-Length, que le especifica al servidor hasta donde tomar como contenido, es decir:

GET / HTTP/1.1Host: localhostContent-Length: 22GET / HTTP/1.1Head: GET /phpinfo.php HTTP/1.1Host: localhost

De este modo tenemos a simple vista 2 consultas HTTP de metodo GET y apuntando a la raiz ("/"), pero si tomamos en cuenta al Content-Length (22 caracteres) entonces contamos esos 22 caracteres y tenemos que:

GET / HTTP/1.1Head: 

Es el contenido, de modo que lo siguiente es otra consulta, entonces tenemos 2 consultas con método GET una apuntando a la raiz y la otro a /phpinfo.php, según los estándares del HTTP esto no debería de ser correcto, pues Content-Length no se supone que sea valido sobre GET, aun así muchos servidores web (apache, IIS, etc...) validan el Conten-Length, en otros casos podemos utilizar POST en lugar de GET, pero de esta forma pasa un tanto mas desapercibido si se siguen fielmente los estándares :P (aparte de que por ejemplo cherokee algunas veces da problemas).

Explicando un poco mas esto, los IDS (especialmente los NIDS), reconocen como que hay 2 consultas GET apuntando a la raiz (como tal no validan el Content-Length), y que el encabezado Head, tiene de valor: GET /phpinfo.php HTTP/1.1 (es decir una simple cadena).

Esta es una técnica de evasión bastante eficiente, incluso las versiones mas recientes de Snort no detectan eso, pero únicamente nos sirve para evadir las reglas que analizan mediante "uri content", pues lo demás se sigue tratando como contenido.

Ahora vamos con los siguiente, en una publicación anterior explique que muchos servidores web soportan otros caracteres aparte de los espacios como separadores, esto se puede utilizar para hacer que las reglas no correspondan, por ejemplo si nosotros remplazamos todos los espacios de la consulta a enviar por tabulaciones o algún otro carácter extraño (pero soportado por el servidor web en cuestion), los IDS's no podrán parsear correctamente las consultas HTTP y por tanto tendremos una forma eficiente de evadirlos nuevamente (por lo menos uricontent y algunas reglas que analizan encabezados) :P...

Ejemplo:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"COMMUNITY WEB-PHP piranha default passwd attempt"; flow:to_server,established; uricontent:"/piranha/secure/control.php3"; content:"Authorization|3A| Basic cGlyYW5oYTp"; reference:bugtraq,1148; reference:cve,2000-0248; reference:nessus,10381; classtype:attempted-recon; sid:100000151; rev:2;)

Esta es una de las reglas que tiene el NIDS Snort por default, analizándola un poco tenemos que busca el uricontent y con la técnica que acabamos de ver arriba se puede evadir, pero suponiendo que el servidor web no soportara conexiones persistentes (y por tanto HTTP Pipelining), aun tenemos una alternativa, podemos ver que busca en el contenido:

Authorization|3A| Basic cGlyYW5oYTp

lo cual se entiende:
Authorization: Basic cGlyYW5oYTp

es decir una cadena exacta, ya que podemos usar otros separadores, no necesariamente espacios, esta regla ya no corresponde, pues busca exactamente:
Authorization dos puntos, espacio y la cadena: Basic cGlyYW5oYTp (la cual tambien tiene espacio...) cambiemos ese espacio por una tabulación o cualquier otro carácter soportado como separador en el servidor web a atacar y listo, la regla ya no corresponde :P, les vuelvo a colocar la "tabla de separadores soportados":

Apache/2.x: 9,11,12,13,32
IIS/x.x: 9,32
GWS: 10,32
Cherokee Web Server: 32

de ahí pueden sacar muchas ideas para evadir las reglas de los IDS :P

Y ya que estamos en esto, va otra técnica mas (una bastante simplona):

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"COMMUNITY WEB-PHP Particle Gallery Viewimage PHP Variable Injection Attempt"; flow:to_server,established; uricontent:"viewimage.php?imageid="; nocase; pcre:"/viewimage\.php\?imageid=(![\d]+[\sa-zA-Z_]+)|([\d]+[\sa-zA-Z_]+)/Ui"; reference:bugtraq,18270; classtype:web-application-attack; sid:100000445; rev:1;)

bueno esto es simple, busca la cadena exacta: viewimage.php?imageid=, dentro del uri content, si no corresponde no continua, bueno esto es simple de evadir, agregemos otro parametro antes del imageid y evadido:

viewimage.php?xianur0=1&imageid=

o bien:

viewimage.php?&imageid=

por lo menos PHP no tiene problemas con el orden de los parámetros así que es valido para el servidor web, y no corresponde a la regla.

Este es el capitulo uno de la saga de evasión de IDS, pronto la siguiente :P