Search Results for: CTF

Como sin duda todos nuestros lectores saben, la semana pasada se celebró en Madrid la segunda edición del Congreso de Seguridad Informática Rooted CON. Tras el éxito del año pasado, esta vez se localizó en el salón de actos del edificio de la Mutua Madrileña, buscando así un mayor aforo. Aun así, las entradas se agotaron antes incluso que se confirmaran las ponencias, una muestra más del prestigio que ha conseguido el evento a nivel nacional e internacional. Todo ello gracias al nivel de las charlas que impartieron los ponentes y a la organización, que han hecho un trabajo estupendo junto a los patrocinadores de la talla como Telefónica, Alienvault o S21sec entre otros. Desde Security Art Work les mandamos nuestra enhorabuena por el gran trabajo realizado :)

Las charlas trataron sobre temas variados, tocando tanto reversing, bases de datos, malware, descifrado de contraseñas, y temas actuales como cloud computing, SCADA o dispositivos móviles. Las diapositivas de las charlas están disponibles públicamente, y les invito a estudiarlas porque sin duda encontrarán más de una sorpresa. La organización ha prometido además publicar en breve los vídeos de las ponencias. ¡Estaremos atentos!

Paralelamente a las ponencias, la organización, con la ayuda de los patrocinadores, publicó un concurso de tipo CTF. Están preparando para abrirlo a cualquiera que quiera apuntarse, aunque las plazas serán limitadas. A pesar de la dificultad de las pruebas, recomendamos participar puesto que es una forma muy divertida de aprender con este tipo de retos. Además, el grupo ganador Painsec tiene previsto publicar el whitepaper con las soluciones del concurso.

Como siempre, estos eventos siempre dejan con ganas de más. Esperaremos con impaciencia la tercera RootedCON.

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:

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:

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:

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):

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

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:

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: