Como se ha visto en el articulo anterior, algunos de los plugins de W3AF son bastante útiles para conseguir de forma rápida, información sobre una aplicación web y la infraestructura del servidor. En el articulo anterior, solamente se han incluido algunos plugins de descubrimiento de W3AF, en esta publicación, vamos a utilizar algunos de los plugins de auditoria y haremos una corta introducción a Arachni, el cual, como en el caso de W3AF, es una herramienta muy completa para la ejecución de pruebas de penetración contra aplicaciones web y aunque ya viene incluida en Dojo, es interesante realizar una instalación manual de la herramienta con la última versión disponible.
Para ello, podemos descargar la última versión estable desde aquí:
http://www.arachni-scanner.com/download/
Sin embargo, a la fecha de escribir este articulo, he visto que hay algunas dificultades a la hora de instalar esta herramienta desde el tarball disponible dando el siguiente error:
Si tiramos del repositorio GIT (http://www.arachni-scanner.com/developement/code-repository/) e intentamos instalar desde dichos fuentes, solamente es necesario instalar algunas dependencias para su correcto funcionamiento
Ahora bien, esta herramienta funciona por medio de diferentes módulos que están divididos en varias categorías según el tipo de ataque que se quiera probar, por ejemplo, existen módulos específicos para probar ataques XSS, SQLi, LDAPi, CSRF, entre otros.
Los primeros comandos que nos viene bien probar son el comando para listar la ayuda con las opciones disponibles y los módulos que podemos utilizar, estas opciones son –help y –lsmod respectivamente.
Ahora podemos comenzar a realizar algunas pruebas, por ejemplo, podemos intentar determinar si Arachni es capaz de encontrar algún punto vulnerable a XSS en la aplicación. Sin nos fijamos en el comando de ayuda, podemos ver que para indicar a Arachni que utilice algunos módulos concretos, podemos especificar la opción “-m” o “–modules” por ejemplo, el siguiente comando seria valido:
./arachni –modules xss* http://192.168.1.41:8080/insecure/public/index.jsp
Como se puede ver, la sintaxis es sencilla, primero se especifican las opciones para “personalizar” la ejecución del comando y luego va la URL de la aplicación web que queremos auditar. El resultado del comando anterior, se enseña en la siguiente imagen:
La herramienta se encarga de ejecutar un crawler que se encuentra integrado en la herramienta y procede a ejecutarse de forma automática para seguir los links que se encuentren en la URL especificada, esto con el fin de intentar encontrar muchas más vulnerabilidades en el sitio web auditado.
Si nos fijamos en el reporte, al parecer se ha detectado algún tipo de problema en el formulario ForgotLogin.jsp.
Si nos fijamos detenidamente en dicho formulario, nos encontramos no solamente con que contiene una vulnerabilidad XSS que permite inyectar código HTML en la pagina, sino que también, nos encontramos con que no se realizan las validaciones adecuadas en los datos que se ingresan y que van a parar directamente contra la base de datos, es decir, el formulario también es vulnerable a SQL Injection.
HTML Injection en formulario
SQL Injection en formulario
A pesar de que hemos detectado una potencial vulnerabilidad del tipo SQL Injection, cuando intentamos ejecutar el siguiente comando desde Arachni:
./arachni –modules sql* http://192.168.1.41:8080/insecure/public/index.jsp
Nos encontramos con lo siguiente:
Como podemos ver, no ha encontrado la vulnerabilidad SQLi de forma automática, es por este motivo que siempre se aconseja realizar pruebas manuales y no solamente fiarse de los resultados que nos ofrecen herramientas como esta.
Por otro lado, podemos ejecutar todos los módulos disponibles con el fin de encontrar toda la información posible sobre vulnerabilidades existentes en la aplicación web, para ello, simplemente omitimos el uso de la opción “–modules”. En dicho caso, el proceso puede tardar mucho más, pero también retornará muchísimos más resultados que pueden ser útiles.
Finalmente, existen algunas opciones que permiten controlar el funcionamiento de la herramienta, por ejemplo, tenemos opciones de propósito general que permiten, entre muchas más cosas, depurar (–debug) enseñar solamente resultados positivos (–only-positives) limitar el número de peticiones http concurrentes (–http-req-limit) especificar una cabecera personalizada en las peticiones (–custom-header) establer un user agent determinado (–user-agent).
Por ejemplo, el siguiente comando seria valido:
./arachni –only-positives –http-req-limit 10 –user-agent «Soy un agente del karma» –custom-header=»Content-type text/html» http://192.168.1.41:8080/insecure/public/index.jsp
Otras opciones que pueden ser muy interesantes, son aquellas de la categoría de “Auditor”, ya que permiten indicar que se realicen pruebas de auditoría sobre links, formularios, coookies o headers
./arachni –only-positives –audit-links –audit-forms –audit-cookies –audit-headers http://192.168.1.41:8080/insecure/public/index.jsp
Arachni es una herramienta más del “arsenal” que podemos complementar con otras de las que ya hemos hablado en otras ocasiones tales como Nikto, W3AF, SQLMap, entre otras.
Esto es todo de momento, en la próxima publicación vamos a hablar un poco más sobre como encontrar y explotar vulnerabilidades en aplicaciones web utilizando como ejemplo Insecure WebApp
Seguridad en Sistemas y Técnicas de Hacking. TheHackerWay (THW) 