Segundo con Shadow Web Analyzer
Tras ver que el primer objetivo se ha logrado, ¿qué más se podría hacer? Pues los creadores del conocido software de escaneo de vulnerabilidades SSS sacaron a la luz la herramienta orientada a contenido web Shadow Web Analyzer, de cuya página oficial puede descargarse una versión de prueba. Seguimos el mismo procedimiento que aplicamos con Acunetix y observamos las siguientes cabeceras:
He configurado la herramienta para pasar a través de un proxy pero éste no elimina la cabecera en cuestión y el resultado obtenido es idéntico. He ahí una contra-idea para los fans de dicha herramienta: instalar un proxy intermedio que elimine la cabecera "Range:" antes de cursar la petición.
Idea Maligna: Que un sitio web contenga sólo una página en blanco es cuanto menos sospechoso. Más interesante todavía resulta lo siguiente: redirigir al escáner hacia una serie de páginas previamente diseñadas (y con apariencia similar a la web original) para contener campos y formularios supuestamente vulnerables pero cuidadosamente controlados, esto es, al estilo wargame, de modo que un listado de falsos positivos por parte del programa mantendrá ocupado al personaje de turno trabajando en ciertas brechas preparadas a tal fin.
No-Limit Crawlers Attack
Lo que aquí muestro no es más que una idea feliz que engaña a los programas sin chequeo de límites para seguir escaneando e indexando páginas hasta el infinito. El concepto que se me ocurrió es sencillo. Primero diseñar una página que cada vez que se visita, crea dinámicamente otra página cuyo nombre de fichero es un número aleatorio más la palabra “crawler” (por ejemplo 382934349crawler.php), y que muestre un link hacia esa nueva página.
Después el código de la página actual será copiado íntegramente en la nueva página. Por último, el mismo script tiene que borrar todos los ficheros en el directorio actual que contengan la palabra “crawler” pero que no sean la página misma ni la nueva creada.
Imaginemos pues que diseñamos el citado fichero con el nombre “734821crawler.php” y en el introducimos esto:
…que le diría que tiene que indexar y visitar otro enlace por ejemplo en “/craw/1205516587crawler.php”. Si esto llega a producirse el proceso se repite una y otra vez, creando nuevas páginas de forma dinámica, mostrando el enlace a la nueva creada y borrando las antiguas. Un ciclo infinito. Acunetix no cae en este juego puesto que su configuración por defecto marca los siguientes límites:
En el caso que nos ocupa los settings que frenan esta idea feliz son “Link depth limitation”, “Maximum Lumber of files in a directory” y sobre todo “Crawler file limit”.
Pero en este apartado hablábamos de no-limit crawlers, y bajo esta categoría han caído en la sencilla trampa algunas herramientas como Win Web Crawler o DRK Spider programado en Java.
Esta última parte no es más que una curiosa idea que ha venido a complementar el objetivo principal con el que comenzamos el artículo, entorpecer los escaneos automáticos y sin control profesional de aquellos que navegan sin rumbo fijo, tanto en la red como en la vida. Por lo demás… Happy Hacking!
Autor: blackngel
blackngel@blackbycode.com
*********************************************************************************
- Confusing Acunetix Kiddies & No-Limit Crawlers (1 de 2)
- Confusing Acunetix Kiddies & No-Limit Crawlers (2 de 2)
*********************************************************************************
Tras ver que el primer objetivo se ha logrado, ¿qué más se podría hacer? Pues los creadores del conocido software de escaneo de vulnerabilidades SSS sacaron a la luz la herramienta orientada a contenido web Shadow Web Analyzer, de cuya página oficial puede descargarse una versión de prueba. Seguimos el mismo procedimiento que aplicamos con Acunetix y observamos las siguientes cabeceras:
GET / HTTP/1.0En este caso el software se publicita a sí mismo a través del User-Agent, pero filtrar por esta cadena no es una idea de largo alcance puesto que en el modo personalizado SWA te permite escoger entre otros cuatro predefinidos o establecer el tuyo a medida. Lo que sí llama nuestra atención es la inusual Range: bytes=0-, en el RFC oficial podemos leer lo siguiente:
User-Agent: ShadowWebAnalyzer (http://www.safety-lab.com/)
Accept: */*
Accept-Language: ru
Range: bytes=0-
Host: www.site-web.org
14.35.2 Range Retrieval Requests
HTTP retrieval requests using conditional or unconditional GET methods MAY request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies to the entity returned as the result of the request:
Range = "Range" ":" ranges-specifier
A server MAY ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible...Parece que su objetivo es solicitar una parte en concreto de un recurso, y no todo el fichero en la petición GET. Dado que no interrumpe el funcionamiento normal de nuestro website agregamos lo siguiente a nuestro anterior script:
if ((strpos($header, "Range") !== false) && (strpos($value,"bytes=0-") !== false))Y el resultado previsible es:
$found = true;
 |
| Figura 2: Resultado obtenido con SWA |
He configurado la herramienta para pasar a través de un proxy pero éste no elimina la cabecera en cuestión y el resultado obtenido es idéntico. He ahí una contra-idea para los fans de dicha herramienta: instalar un proxy intermedio que elimine la cabecera "Range:" antes de cursar la petición.
Idea Maligna: Que un sitio web contenga sólo una página en blanco es cuanto menos sospechoso. Más interesante todavía resulta lo siguiente: redirigir al escáner hacia una serie de páginas previamente diseñadas (y con apariencia similar a la web original) para contener campos y formularios supuestamente vulnerables pero cuidadosamente controlados, esto es, al estilo wargame, de modo que un listado de falsos positivos por parte del programa mantendrá ocupado al personaje de turno trabajando en ciertas brechas preparadas a tal fin.
No-Limit Crawlers Attack
Lo que aquí muestro no es más que una idea feliz que engaña a los programas sin chequeo de límites para seguir escaneando e indexando páginas hasta el infinito. El concepto que se me ocurrió es sencillo. Primero diseñar una página que cada vez que se visita, crea dinámicamente otra página cuyo nombre de fichero es un número aleatorio más la palabra “crawler” (por ejemplo 382934349crawler.php), y que muestre un link hacia esa nueva página.
Después el código de la página actual será copiado íntegramente en la nueva página. Por último, el mismo script tiene que borrar todos los ficheros en el directorio actual que contengan la palabra “crawler” pero que no sean la página misma ni la nueva creada.
Imaginemos pues que diseñamos el citado fichero con el nombre “734821crawler.php” y en el introducimos esto:
<html>Esta página la introduzco en un directorio “craw\” dentro del server y añado un enlace en la página principal (index.php), quizás oculto:
<body>
<?php
$dir_handle = @opendir(".") or die("No se pudo abrir el directorio actual");
while ($file = readdir($dir_handle))
{
if ((strpos($file, "crawler") !== false) && (strcmp(basename($_SERVER['PHP_SELF']), $file) != 0 ) && (strcmp($file, "734821crawler.php") != 0 ) )
{
unlink($file);
}
}
closedir($dir_handle);
$newFileName = strval(mt_rand(0, mt_getrandmax())) . "crawler.php";
if (!copy(basename($_SERVER['PHP_SELF']), $newFileName))
{
echo "Error al copiar a $newFileName...\n";
}
echo "\n<a href=\"$newFileName\">blackbycode</a>";
?>
</body>
</html>
<a style="display:none;" href="craw/734821crawler.php">Lastlink</a>Lo que ocurrirá cuando el web spider haga un request a la página es que esta creará otra página idéntica pero con distinto nombre, borrando otras anteriores si las hubiese de modo que como máximo en el servidor sólo existirán tres archivos del tipo “anticrawler”. El robot interpretaría el siguiente resultado…
 |
| Figura 3: Resultado que interpretaría el crawler |
…que le diría que tiene que indexar y visitar otro enlace por ejemplo en “/craw/1205516587crawler.php”. Si esto llega a producirse el proceso se repite una y otra vez, creando nuevas páginas de forma dinámica, mostrando el enlace a la nueva creada y borrando las antiguas. Un ciclo infinito. Acunetix no cae en este juego puesto que su configuración por defecto marca los siguientes límites:
 |
| Figura 4: Límites del crawler en Acunetix |
En el caso que nos ocupa los settings que frenan esta idea feliz son “Link depth limitation”, “Maximum Lumber of files in a directory” y sobre todo “Crawler file limit”.
 |
| Figura 5: Crawlers sin límites |
Pero en este apartado hablábamos de no-limit crawlers, y bajo esta categoría han caído en la sencilla trampa algunas herramientas como Win Web Crawler o DRK Spider programado en Java.
Esta última parte no es más que una curiosa idea que ha venido a complementar el objetivo principal con el que comenzamos el artículo, entorpecer los escaneos automáticos y sin control profesional de aquellos que navegan sin rumbo fijo, tanto en la red como en la vida. Por lo demás… Happy Hacking!
Autor: blackngel
blackngel@blackbycode.com
*********************************************************************************
- Confusing Acunetix Kiddies & No-Limit Crawlers (1 de 2)
- Confusing Acunetix Kiddies & No-Limit Crawlers (2 de 2)
*********************************************************************************
Buen articulo >:))
ResponderEliminarCacho lammmmer blackngel, si bloqueas peticiones con el header range bloquearas muchas conexiones reales de navegadores. Porfavor si no sabes lo que haces ni para que se usa range no escribas un articulo
ResponderEliminar@blacklammmmmer, esperamos con impaciencia tu propuesta.
ResponderEliminarYo he implementado soluciones similares para perder a algún bot o crawler, pero en lugar de crear archivos en tiempo real, uso mod rewrite de apache de forma que determinadas peticiones (por ejemplo las que empiecen con crawler*) vayan todas a el mismo fichero cambiando de la misma forma que tú has hecho, la URL a la que apunte el enlace.
ResponderEliminar