Confusing Acunetix Kiddies & No-Limit Crawlers (1 de 2)

No es nada nuevo para el mundo de la seguridad que programas como Acunetix, Shadow Security Scanner y otros de la misma índole sean lanzados de forma indiscriminada por personajes de mente inquieta que se aburren en demasía los fines de semana o a quienes un wargame no les resulta suficiente alimento intelectual. Y hay que admitir que a estos seres perceptiblemente desorientados en ciertas ocasiones la suerte les acompaña y hacen acopio de algún sucinto conocimiento sobre SQLi y XSS para dar otro quebradero de cabeza al webmaster de turno.

He aquí algunos apuntes para evitar estos asaltos indiscriminados. Me gustaría recalcar lo siguiente: los tips que aquí se ofrecen tal vez ayuden a mitigar el escaneo masivo de kiddies (en ciertas configuraciones por defecto), pero de ninguna manera entorpecerá el trabajo de profesionales de la seguridad que saben lo que hacen y que confían más en sus manos sobre el teclado e intuición propia que en alguna otra herramienta distinta a las que ellos mismos hayan diseñado, y que pueden utilizar múltiples técnicas para descubrir los ficheros de un sitio web. Este trabajo es algo similar a cómo las inverted queries engañaban a los scanners de vulnerabilidades.

Un web spider o crawler, no es más que aquella pieza de software que, rara vez utilizando técnicas genuinamente heurísticas, se encarga de recorrer un sitio web indexando todo hiperenlace que se encuentra en el camino para diseñar un árbol prácticamente completo de las páginas y directorios alojados en el servidor. La tarea puede finalizar en este punto, o bien se pueden anexar un sinnúmero de scripts diseñados para automatizar el escaneo de vulnerabilidades previamente conocidas en las páginas encontradas. En esta fase, las extensiones de los ficheros listados ayudan a definir la clase de chequeo a realizar.

Estos spiders son capaces de encontrar ficheros de los cuales muchos webmasters descuidados admitirían que ni siquiera tenían noticia de su existencia. Archivos jugosos y de productos de desarrollo rápido que se quedan “como por ahí”.

Al tema: la idea es encontrar un modo sencillo de evitar que un site sea recorrido de forma automática. Para ello he consultado las cabeceras HTTP que emiten este tipo de programas para intentar discriminar en el propio código de la página web principal si la petición proviene de un usuario corriente o del software de turno.

Primero con Acunetix

Nos bajamos el Acunetix y bien con Whireshark o desde el mismo lector de cabeceras del programa, ponemos el primero en funcionamiento y rápidamente observamos que la cabecera emitida pinta como lo siguiente:

GET /index.php HTTP/1.1
Pragma: no-cache
Cache-Control: no-cache
Referer: http://www.site-web.org/
Acunetix-Aspect: enabled
Acunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66c
Acunetix-Aspect-Queries: filelist;aspectalerts
Host: www.site-web.org
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Acunetix-Product: WVS/8.0 (Acunetix Web Vulnerability Scanner - Free Edition)
Acunetix-Scanning-agreement: Third Party Scanning PROHIBITED
Acunetix-User-agreement: http://www.acunetix.com/wvs/disc.htm
Accept: */*

El User-Agent entra dentro de lo común, pero descaradamente nada menos que seis cabeceras referencian el software realizando el request. Si desactivamos esa “supuesta tecnología” que llaman AcuSensor todavía nos quedan tres:

GET /index.php HTTP/1.1
Pragma: no-cache
Cache-Control: no-cache
Referer: http://www. site-web.org/
Host: www. site-web.org
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Acunetix-Product: WVS/8.0 (Acunetix Web Vulnerability Scanner - Free Edition)
Acunetix-Scanning-agreement: Third Party Scanning PROHIBITED
Acunetix-User-agreement: http://www.acunetix.com/wvs/disc.htm
Accept: */*

La solución rápida pasa por parsear las cabeceras y reconocer la cadena “Acunetix” con el objetivo de desechar la petición o redirigirlo hacia una página en blanco carente de nuevos enlaces que indexar. Para ello creamos un archivo “blank.php” bien vacío bien con…

<html> <body> <p>Nothing</p> </body> <html>

…por aquello de que hay aplicaciones que no indexan contenido sin texto. Y a continuación colocamos el siguiente script al principio del “index.php” (aquellos adeptos a ASP y NET pueden codear lo mismo):

<?php
$headers = apache_request_headers();
$found = false;
foreach ($headers as $header => $value)
{
if (strpos($header, "Acunetix") !== false)
$found = true;
}
if ($found)
{
header("Location: http://www.web-site.org/blank.php");
exit;
}
?>

Ahora lanzamos un escaneo completo y optimizado para la tecnología PHP contra la página, el resultado obtenido lo vemos en la imagen.

Figura 1: Resultado obtenido con Acunetix

Exacto, lo que no se puede ver no se puede escanear. La rama “Site Structure” muestra algo que nada tiene que ver con el contenido real de la web en cuestión, con lo que se ha conseguido el objetivo de confundir al escaneo automático por defecto.

Tras algunas pruebas se deduce que el directorio "images" se chequea a partir de una lista de “directorios probables” - un fuzzing estático -, así también páginas como "stats.php", los archiconocidos sitemap.xml y robots.txt, y todos esos ficheros jugosos (juicy files) de los cuales Chema Alonso, a través de su preciada FOCA, tan gentilmente nos ha avisado siempre que tratemos con especial atención.

Autor: blackngel
blackngel@blackbycode.com

*********************************************************************************
- Confusing Acunetix Kiddies & No-Limit Crawlers (1 de 2)
- Confusing Acunetix Kiddies & No-Limit Crawlers (2 de 2)
*********************************************************************************