Parche para el módulo http de THC-Hydra: error manejando los códigos de respuesta HTTP

THC-Hydra es una conocidísima herramienta de pentest, la cual ocupa el puesto 15 en el ranking ‘top 100 de herramientas de seguridad de red’ de insecure.org, y es parte de nessus (la herramienta de análisis de vulnerabilidades de mayor renombre del mundo UNIX).
Permite realizar ataques de diccionario por red soportando más de 30 protocolos, con el fin de comprobar la seguridad de nuestros servicios.

Como comentan en su página:

“Number one of the biggest security holes are passwords, as every password security study shows. Hydra is a parallized login cracker which supports numerous protocols to attack. New modules are easy to add, beside that, it is flexible and very fast.”

El número uno de los grandes agujeros de seguridad son las contraseñas, como muestra cada estudio de seguridad de contraseñas. Hydra es un crackeador de login paralelizado que soporta numerosos protocolos de ataque. Añadir nuevos modulos es sencillo, ademas que, es flexible y muy rápido.

“This tool is a proof of concept code, to give researchers and security consultants the possiblity to show how easy it would be to gain unauthorized access from remote to a system.”

Esta herramienta es un código de prueba de concepto, para dar a los investigadores y consultores de seguridad la posibilidad de mostrar lo fácil que sería obtener acceso no autorizado a un sistema remoto

Hace unos días estuve probando el módulo hydra-http, uno de los módulos de THC-Hydra en su última versión (la 5.4) referente al protocolo http, y me dí cuenta que no funcionaba como yo esperaba en determinadas situaciones.

En concreto, da falsos positivos debido a que no parsea correctamente los códigos de estado del protocolo http devueltos por el servidor al realizar las consultas para saber si un usuario es válido en el servidor http o no. Es decir, hay casos en los cuales el usuario es valido pero THC-Hydra no nos informa de ello.

Pongamos un escenario en el cual sabemos que existe un directorio protegido con autenticación, por ejemplo /protected/ en el cúal no existe index.html ni ninguna página por defecto (los usuarios legítimos acceden mediante la uri /protected/path_desconocido), nosotros pasaríamos al thc-hydra como parámetros la dirección del servidor, el usuario y el password (o las listas de estos), así como el path que queremos comprobar (en nuestro caso /protected/).

La herramienta se pondrá en funcionamiento, y realizará una petición a /protected/, si el usuario NO es válido el código de estado que devuelve el servidor será 401 (Authentication Requiered), sin embargo si el usuario es correcto, al no existir un index.html ni similares el código de retorno será 403 (Forbidden), pero debido a un fallo en el manejo de los código de estado http devuetos no nos informará que el usuario es correcto. El mismo error sucede con códigos como 404 (Not found), ya que hydra-http busca el código de respuesta http 200 (Correcto) o 301 (Redirect).

He escrito un parche que corrige este bug, aqui lo teneis:

— hydra-http_orig.c 2007-12-31 14:51:42.000000000 +0100
+++ hydra-http.c 2007-12-31 15:50:29.000000000 +0100
@@ -53,7 +53,7 @@
*/

ptr = ((char *) index(buf, ‘ ‘)) + 1;
– if (ptr != NULL && (*ptr == ‘2’ || strncmp(ptr, “301”, 3) == 0)) {
+ if (ptr != NULL && (*ptr == ‘2’ || *ptr== ‘3’ || strncmp(ptr, “403”, 3) == 0 || strncmp(ptr, “404”, 3) == 0)) {
hydra_report_found_host(port, ip, “www”, fp);
hydra_completed_pair_found();
} else {

para aplicarlo simplemente entrar en el directorio de THC-Hydra 5.4 y patch -p0 < hydra-http.patch
seguidamente compilar de nuevo.

Un ejemplo práctico:

Supongamos que sabemos que existe un recurso protegido llamado /protected/ (pero no tiene un fichero por defecto):

Petición sin usuario:

user@host:~$ wget http://server/protected/ 2>&1 |grep HTTP
Petición HTTP enviada, esperando respuesta… 401 Authorization Required

Petición con un usuario válido:

user@host:~$ wget –http-user=user –http-password=password http://server/protected/ 2>&1 |grep HTTP
Petición HTTP enviada, esperando respuesta… 403 Forbidden

entonces correriamos el hydra, (para simplificar el ejemplo usare solo un usuario/password):

user@host:~/hydra-5.4-src$ ./hydra server http-head -l user -p password -m /protected/
Hydra v5.4 (c) 2006 by van Hauser / THC – use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2007-12-31 16:00:09
[DATA] 1 tasks, 1 servers, 1 login tries (l:1/p:1), ~1 tries per task
[DATA] attacking service http-head on port 80
[STATUS] attack finished for server (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2007-12-31 16:00:10

No encuentra que el usuario sea válido, aunque si lo es!

Sin embargo, aplicamos el parche

user@host:~/hydra-5.4-src$ patch -p0<hydra-http.patch
patching file hydra-http.c

/* recompilamos */
user@host:~hydra-5.4-src$ make clean && ./configure && make

ejecutamos de nuevo con los mismos parámetros:

user@host~/hydra-5.4-src$ ./hydra server http-head -l user -p password -m /protected/
Hydra v5.4 (c) 2006 by van Hauser / THC – use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2007-12-31 16:01:08
[DATA] 1 tasks, 1 servers, 1 login tries (l:1/p:1), ~1 tries per task
[DATA] attacking service http-head on port 80
[STATUS] attack finished for server (waiting for childs to finish)
[80][www] host: server login: user password: password
Hydra (http://www.thc.org ) finished at 2007-12-31 16:01:09

bingo! ahora sí lo encontro!, simplemente era un problema manejando los códigos del protocolo HTTP (buscaba el código 200 o 301). Pero en este caso el código devuelto es 403 (forbidden) y también indica que el usuario es válido (al igual que si hubiera sido 404 (not found).

ACTUALIZACIÓN: Link en inglés: Patch for the THC-Hydra 5.4 error handling http response codes.

Saludos