Evasión en IDS (II)

Después de unas largas vacaciones, vamos a continuar con el apartado de evasión de IDS que comenzamos hace un par de meses. Tal como vimos, existen distintos vectores de ataques para intentar evadir o denegar el servicio en los entornos de detección de intrusos a nivel de red. El principal objetivo del atacante es evadir el motor de reglas del IDS, de tal forma que el ataque es modificado para que el patrón de búsqueda del motor de reglas no reconozca el ataque como tal, pero sí que sea ejecutado por el servidor víctima.

Para que resulte más sencillo de explicar, vamos a introducirnos en el papel de un atacante en un ejemplo típico de evasión de IDS. Imaginemos que auditando un entorno web hemos detectado que hay un recurso vulnerable (index.php) que permite obtener ficheros de la máquina, y en este caso querremos obtener el fichero “passwd” del directorio “etc”. La consulta web que realizaríamos seria de este estilo:

http://servidorVictima/index.php?=/etc/passwd

Al realizar la consulta, vemos que el paquete es rechazado por un IDS (IPS) puesto que éste busca la cadena “/etc/passwd” y si la detecta rechaza el paquete. Nuestra intención como atacantes es pues explotar los distintos posibles vectores de ataques que evadan el IDS y nos permitan obtener el fichero “/etc/passwd”.

El primer tipo de vector de ataque será modificar la cadena “/etc/passwd” para que no sea interpretada por el IDS pero si por el servidor. Este tipo de vector de ataque se dividen principalmente en tres grupos:

1) Interpretación incorrecta del protocolo

Este vector de ataque es muy común en metadatos y servidor Web. Consiste en inyectar en el paquete cabeceras repetidas donde solo una de ellas, normalmente la última, contiene realmente la cabecera que quiere ser explotada por el atacante. Siguiendo el ejemplo anterior, un posible vector de ataque para intentar explotar la vulnerabilidad del servidor web sería enviando una solicitud con el siguiente contenido:

GET / HTTP/1.0
Host: www.servidorVictima
GET /index.php?=/etc/passwd
Host: www.servidorVictima

2) Modificación del direccionamiento

Existen métodos para introducir otros caracteres en la cadena que se quiere explotar, sin que esto altere el dato solicitado al servidor, de tal forma que el servidor al ejecutarlo nos permita acceder al recurso solicitado y a su vez, engañar al IDS al no coincidir con el patrón buscado:

/index.php?=/./etc/./passwd
/index.php?=/cadenamuylargaparaengañaralIDSynosigaleyendo/../etc/passwd
<tab>/index.php?=/etc/passwd </tab> (Empleado para otro tipo de evasión)
/index.php?=/etc\passwd

Codificación de los caracteres

Otro vector de ataque muy conocido consiste en emplear codificaciones que son interpretadas por distintos servicios pero no así por el IDS. Esto es debido a que algunos servicios soportan codificaciones no estipuladas en el estándar RFC. Por tanto, un IDS debe tener soportes para tantas codificaciones como soporten los distintos servicios, ya que de lo contrario, nosotros como atacantes podríamos evadir el IDS empleando una codificarción no soportada por el IDS pero sí por el servidor, tal como se describe en el paper de Daniel J. Roelker: HTTP IDS Evasion Revisited.

Por ello, dependiendo del servidor existen distintas codificaciones para representar caracteres y de esta forma, poder representar el vector de ataque que queremos realizar. En la siguiente tabla se representa un ejemplo sencillo de como se podría representaría el carácter A (no todos los servicios soportan las mismas codificaciones):

ASCII A
Hex Encoding %41 (41 es el carácter A en hexadecimal)
Percent Hex %2541 (%25 es el carácter % por lo que se nos queda %41)
Double Nibble %%34%31 (%34 es 4, %31 es 1 quedando %41)
First Nibble %%341 (dec %34 como 4 y queda %41)
Second Nibble %4%31 (dec %31 como 1 y queda %41)

En el caso del ejemplo, si quisiéramos representar el “/etc/passwd” en cualquiera de las codificaciones anteriores sería de la siguiente forma:

ASCII /etc/passwd

Hex Encoding %2f%65%74%63%2f%70%61%73%73%77%64
Percent Hex %252f%2565%2574%2563%252f%2570%2561…
Double Nibble %%32%66%%36%35%%37%34%%36%33%%32%66…
First Nibble %%32f%%365%%374%%363%%32f…
Second Nibble %2%%66%6%%35%7%%34%6%%33%2%%66…

Otra forma típica de evadir IDS es aprovechar las primeras características del UTF-8 (Unicode) que permitía representar un mismo carácter de distintas formas, ya que un mismo carácter podía representado con distinto número de bytes. Este fallo fue solventado en el actual estándar UTF8, pero algunos servicios siguen soportando el antiguo estándar. Al respecto, una de las principales ventajas que supone la codificación UTF8 frente a las vistas con anterioridad es la capacidad de emplear el “Bare Byte Unicode Encoding” que permite representar la codificación UTF8 sin necesidad de usar el carácter “%”, lo que le permite saltarse muchos filtros de seguridad.

Debido a lo descrito con anterioridad, los IDS están obligados a emplear normalizadores o preprocesadores, que permitan una representación normalizada del paquete enviado por el usuario, evitando tener que crear firmas para cualquiera de las posibles formas que pudiera adoptar un patrón de ataque. En el caso de Snort y de servidores Web, éste dispone del preprocesador http_inspect, encargado de normalizar las URL solicitadas por los usuarios para intentar eliminar cualquier posibilidad de evasión del IDS. Pero para ello, hay que configurar adecuadamente el preprocesador, indicando las direcciones IP de aquellos servidores que funcionan siguiendo el “estándar” (nótense las comillas, me río yo del estándar) del IIS o de Apache, tal como se describe a continuación:

preprocessor http_inspect_server: server { IP1 IP2 … IPX } profile apache ports { PUERTO1 PUERTO2 … PUERTOX }

preprocessor http_inspect_server: server { IP1 IP2 … IPX } profile iis ports { PUERTO1 PUERTO2 … PUERTOX }

Espero que les haya parecido interesante. En la siguiente entrada trataremos otro vector de ataque consistente en aprovecharse de las cabeceras TCP/IP para evadir IDS. Cualquier comentario es bienvenido.


(N.d.E.) En otro orden de cosas, Román Soft nos hace llegar la siguiente nota de prensa, relacionada con un concurso de seguridad que seguro que les parecerá interesante:

Buenas tardes,

El viernes próximo (17/Sep, 20h CEST) dará comienzo un concurso de seguridad web (para que nos entendamos: a lo “Boinas Negras”) que he organizado aprovechando algunas pruebas web que diseñamos Dreyer y yo con motivo del pasado CTF de la RootedCON’2010, y que tiene como premio el nuevo iPod touch de Apple (esto es, el 4G), cortesía de Hispasec Sistemas.

Podéis encontrar más info aquí (el periodo de inscripción ya está abierto): http://www.rs-labs.com/noticias/#38

Aclarar que se trata de una iniciativa propia ya que yo ya NO tengo nada que ver con RootedCON desde hace aproximadamente 6 meses (dejé el proyecto tras concluir la primera edición del congreso).

Por último, aprovecho para comentar que el pasado fin de semana publiqué además los resultados del *pasado* CTF, junto a otros detalles.

En fin, que os animo a participar en el concurso y a luchar por el precioso iPod… ¡que además vendrá con dedicatoria incluida (a láser)!

Mucha suerte a todos.

Trackbacks

  1. […] Evasión en IDS (II) (…) Para que resulte más sencillo de explicar, vamos a introducirnos en el papel de un atacante en un ejemplo típico de evasión de IDS. Imaginemos que auditando un entorno web hemos detectado que hay un recurso vulnerable (index.php) que permite obtener ficheros de la máquina, y en este caso querremos obtener el fichero “passwd” del directorio “etc”… […]

  2. […] Tal como vimos en la anterior entrada, una forma sencilla de evadir el motor de reglas es emplear distintas codificaciones para intentar que el ataque no coincida con el patrón buscado por el IDS. Junto a lo visto con anterioridad, existen otros métodos sobre el protocolo TCP/IP para intentar evadir el motor de reglas. Veremos cuatro de los principales métodos de evasión a nivel de TDP/IP: […]