Otra aplicación web vulnerable existente en DOJO es InsecureWebApp, dicha aplicación se encuentra escrita en JSP y contiene una buena cantidad de ejemplos de funciones vulnerables que pueden ser explotadas fácilmente. En los siguientes posts hablaré sobre dichas vulnerabilidades y como es posible explotarlas. El primer paso, como se ha mencionado en muchas ocasiones, es el de recolectar tanta información como sea posible sobre la aplicación web. No solamente son importantes los detalles técnicos, también es muy importante conocer detalles funcionales sobre la aplicación en cuestión, saber para que está hecha y en general cuales son sus características.
Para comenzar, dado que no se trata de una aplicación que se encuentra en Internet y estamos realizando pruebas en un entorno local, evidentemente no es necesario llevar a cabo un proceso de Footprinting para saber recolectar información pública en Internet, ni tampoco es necesario recolectar información sobre un objetivo concreto, tareas que suele desarrollar un atacante en un entorno real. Así que de momento nos limitaremos a perfilar la aplicación web y conocer detalles sobre la plataforma en la que se ejecuta. Para ello, podemos utilizar herramientas tales como Nmap, Nikto y DirBuster (con el fin de conocer cualquier otra aplicación que se encuentré en ejecución en el mismo servidor web).
El resultado de un escaneo en el puerto 8080 utilizando Nmap ha sido el siguiente:
Como se puede apreciar, se trata de un servidor web Apache Tomcat, sin embargo no tenemos información sobre la información concreta del servidor web, además también podemos ver que al parecer los métodos HTTP PUT y HTTP Delete se encuentran habilitados, lo que posiblemente puede significar que es posible crear y borrar ficheros en el servidor, aunque será necesario realizar pruebas para saberlo. Por otro lado, también vemos que al parecer hay un proxy que está realizando redirecciones. Ahora, si intentamos utilizar httprint para determinar cual es la versión exacta del servidor, nos encontramos con lo siguiente:
Como podemos ver, el acceso directo al contexto “/” por el puerto 8080 se encuentra filtrado por un proxy que realiza una redirección al contexto “/” en el puerto 80, en donde se encuentra en ejecución un servidor web Apache.
Sabemos entonces que el servidor realiza una redirección cuando intentamos acceder al contexto raíz y si accedemos a un contexto inexistente?
Podemos apreciar en la imagen anterior, que el mensaje de error que nos enseña el servidor al tratar de acceder a un recurso no encontrado, enseña la versión del servidor web: Apache Tomcat/4.1.31
En una publicación anterior, se ha hablado sobre algunas de las pruebas de penetración que se pueden llevar a cabo sobre servidores web Tomcat, ver aquí: https://thehackerway.com/2013/01/30/web-hacking-atacando-servidores-web-vulnerables-tomcat-parte-xxi/
Ahora, para obtener más información sobre el objetivo, podemos utilizar otras herramientas, como por ejemplo W3AF y sus módulos de descubrimiento y auditoría para detectar cualquier tipo de anomalía o simplemente información que puede ser útil para llevar a cabo ataques contra el servidor web. No se aconseja habilitar todos los plugins de descubrimiento por el tiempo que puede llevar la ejecución de cada uno, así que lo más recomendable es seleccionar cada uno de forma separada, en las siguientes imágenes se enseña la aplicación de algunos los plugins interesantes para extraer más información del objetivo
Como se puede apreciar, los plugins de descubrimiento empleados han sido:
discovery urlFuzzer userDir robotsReader http_vs_https_dist detectTransparentProxy allowedMethods fingerprint_WAF
Y los resultados que han arrojado son bastante interesantes, podemos ver, por ejemplo, que al parecer, se admiten métodos HTTP potencialmente inseguros tales como PUT y DELETE.
Luego hay otro plugin que puede ser muy útil, el plugin xssedDotCom el cual suele ser muy eficiente para detectar vulnerabilidades XSS, pero que también puede dar falsos positivos.
Como puede apreciarse en la imagen, al parecer se han encontrado posibles vulnerabilidades XSS, pero resulta confuso el script que se indica, dado que no tiene nada que ver con el objetivo que se ha indicado, esto solamente significa, que al parecer en la página de Login, hay un problema del tipo XSS, ya que al manipular los parámetros de entrada, el plugin xssedDorCom ha detectado un comportamiento “inesperado” y por este motivo, se enseña un ejemplo “ficticio” de las pruebas de XSS que se han realizado.
Si intentamos ingresar, por ejemplo, en el campo de login, el primero de los valores que nos enseña el plugin en sus resultados: ><script>alert(‘Fugitif’)</script>
podemos apreciar una respuesta HTTP 500 indicando que se ha producido un error interno en la aplicación
Lo que es un claro indicio de que hay un problema de validación en los parámetros de entrada de la aplicación.
En la próxima entrada, vamos a intentar sacar más información de esta aplicación utilizando otros plugins de W3AF, centrándonos especialmente en los plugins de auditoria para explotación de posibles vulnerabilidades y vamos a comenzar a utilizar otras herramientas para pruebas de penetración en aplicaciones web tales como Arachni y WebSploit Framework
Seguridad en Sistemas y Técnicas de Hacking. TheHackerWay (THW) 