A partir de está publicación y hasta el final, esta serie de artículos será un poco más entretenida, ya que se comenzará a utilizar herramientas comunes para atacar aplicaciones web con ejemplos prácticos. Para continuar desde aquí, con el resto de publicaciones de esta serie, se asume que el lector tiene configurada una máquina virtual con DOJO, tal como se explico hace algunos meses en esta publicación:

https://thehackerway.com/2012/07/09/web-hacking-configurando-dojo-web-security-como-hacklab-parte-iii/

Como se mencionaba en dicho articulo, DOJO es un sistema Ubuntu que cuenta con una buena cantidad de aplicaciones web vulnerables que han sido diseñadas específicamente para practicar diferentes técnicas sobre hacking de aplicaciones web, una de dichas aplicaciones es Hacme Casino una aplicación que simula un Casino virtual.

Atacando HacMe Casino

Ahora bien, asumiendo que Dojo se encuentra iniciado, vamos a comenzar a “jugar” un poco con la aplicación. En primer lugar, HacMe Casino se ejecuta por defecto en el puerto 3000 y la página de bienvenida que se enseña es la siguiente:

hacmecasino_login

Como se puede apreciar, existe un formulario de ingreso y un enlace para crear una nueva cuenta de usuario. En el caso de que se ingrese una cuenta de usuario inexistente o con una contraseña invalida, el mensaje de error que se producirá será el siguiente:

hacmecasino_login2

Ahora bien, una prueba típica para determinar si una página que accede a base de datos, es segura y no tiene vulnerabilidades de SQL Injection, es simplemente intentando manipular los datos que se ingresan en los campos de texto y cualquier otro elemento de interacción con el usuario como combos o checkboxes. La finalidad de esto es determinar si el comportamiento de la aplicación es el esperado y el mismo en todos los casos, por ejemplo, es posible que después de ingresar valores inválidos en los campos de entrada de la aplicación, el servidor como respuesta, enseñe una traza de excepción completa indicando que la consulta SQL ingresada es invalida; así como también es posible que no se enseñe absolutamente nada al usuario final. En el primero de los casos, un atacante puede determinar muy fácilmente que dicha página contiene una vulnerabilidad SQL Injection, dado que la respuesta retornada por el servidor así lo demuestra, sin embargo en el segundo caso, es difícil determinar tal hecho si la respuesta del servidor no cuenta con suficientes detalles, pero esto no significa que la aplicación no sea vulnerable a SQL Injection, esto es lo que comúnmente se conoce como una Blind SQL Injection, ya que un atacante no recibe suficiente información por parte del sistema objetivo, pero aun así, puede acometer cambios en la estructura de la consulta SQL subyacente que utiliza el sistema para acceder a la base de datos. El el caso de HacMe Casino no vamos a ver un mensaje de error que nos enseñe detalles de la consulta SQL que realiza el servidor ni nada que indique una vulnerabilidad, excepto un “pequeño” detalle, el comportamiento de la aplicación cambia.

Simplemente con ingresar el carácter en el campo de texto del usuario, puede apreciarse la diferencia con el mensaje de error presentado cuando se trata de un usuario/contraseña inválidos:

hacmecasino_login3

Como se puede apreciar, el mensaje ha cambiado y en este caso indica que se ha producido un error en le proceso de login, lo que puede ser un indicio de que la consulta SQL que se ha ejecutado contra la base de datos ha fallado.

Hasta este punto, hay un claro indicio de una posible vulnerabilidad SQLi, sin embargo, es muy probable que se puedan encontrar muchas más vulnerabilidades. Nuevamente, como se ha repetido en numerosas ocasiones en este blog, lo más importante para realizar cualquier proceso de pentesting es disponer de suficiente información que permita realizar ataques efectivos. Por este motivo, antes de continuar con la etapa de explotación de está potencial vulnerabilidad, vamos a detallar un poco más sobre un proceso sencillo de recolección de información de esta aplicación web.

Enumeración rápida del servidor web

Una de las primeras actividades que se pueden realizar, es la enumeración activa del servidor web utilizando herramientas como NMAP, aprovechando algunos de los scripts disponibles en dicha herramienta para extraer información del servidor web. Así es posible encontrar información que pueda ser útil para llevar a cabo ataques mucho más directos contra la infraestructura del servidor web tal como se ha mencionado en anteriores publicaciones.

En este caso, he utilizado unos pocos scripts del tipo “HTTP” contra el servidor web, que se encuentra arrancado en el puerto 3000. El comando ejecutado ha sido:

nmap -sSV -T5 -A –script=http-config-backup.nse,http-default-accounts.nse,http-headers.nse,http-put.nse,http-passwd.nse,http-methods.nse,http-method-tamper.nse -p3000 192.168.1.41

Y los resultados que lanza NMAP se pueden apreciar en la siguiente imagen

nmap_hacmecasino

Posteriormente, también se puede utilizar Nikto, en este caso, el reporte de Nikto enseña que la aplicación web permite a cualquiera descargar los ficheros .htaccess con información de configuración que puede ser sensitiva

nikto_hacmecasino

Tanto usando NMAP como Nikto, se ha podido conocer fácilmente el tipo servidor utilizado (Mongrel 1.1.5) el cual se basa en Ruby On Rails, creando una política sencilla en Nessus y ejecutando un escaneo, se puede recoger más información, esta vez relacionada con posibles vulnerabilidades que se pueden explotar

nessus_hacmecasino

Nada mal… en menos de 15 minutos y con el uso de 3 sencillas herramientas tenemos una imagen general del objetivo, aunque es mucho lo que se puede indagar, aquí solamente se ha “rascado” muy por encima.

En la próxima publicación más sobre HacMe Casino.