Reto Web WackoPicko (II)

En la entrada pasada se analizo todos los recursos inicialmente disponibles. Una vez identificado todos los posibles vectores de ataque vamos a proceder a analizarlos. En el caso de la entrada iré directamente a aquellos recursos donde encontre vectores explotables y el motivo por el cual consideré que podrían serlo.

Se procederá primero a auditar la parte concerniente a la visibilidad de un usuario no registrado correspondiente a la parte superior del diagrama visto en la entrada pasada.

Dentro de este bloque el primer recurso ha analizar es el asingado a crear usuario (/users/register.php):

1. Se procedio a comprobar si la pagína web devolcia algun campo de los introducidos, es decir, si al poner un nombre incorrecto la página web nos indicaba que el nombre era incorrecto, de forma que, podriamos tratar de introducir código HTML en los campos de entrada y ver si la web lo escupia tal como se lo enviamos de forma que pudiera ser vulnerable a XSS. No hubo exito.
   
   
2. También se intento la ejecución de código SQL sin exito.
   
   
3. Para finalizar se comproba si al introducir un usuario existente la página notificaba que el usuario ya existia. En este caso la web notificaba que el usuario ya existia y por tanto estamos ante un metodo que nos permite obtener los usuarios existentes en la web.
   
   
   

Dentro de este mismo bloque, tenemos un enlace que nos permite comprobar la robustez de la contraseña. El recurso en concreto es "passcheck.php" en el cual al introducir una contraseña comprueba mediante un grep a un fichero si la contraseña existe ya en el fichero. Al disponer del comando que se ejecuta solo necesitamos unas pocas nociones de shell para conseguir ejecutar ordenes en el sistema. Para ello se prepara una condición para que la parte de la izquierda sea una orden correcta, seguida de un "|" y para finalizar añadimos al final la almohadilla (#) para eliminar la parte de la derecha de la orden. Veamos como hay que hacerlo:

Inicialmente introducimos como contraseña a comprobar lo siguiente:

root /etc/passwd #

Ejecutandose la siguiente orden:

grep ^root /etc/passwd #$ /etc/dictionaries-common/words

Donde la página web nos notifica que el password es una mala contraseña. Esto es porque al existir la cadena root en el fichero "/etc/passwd" el fichero PHP lo interpreta como que existe en el diccionario y por tanto es una contraseña trivial.  Si pusieramos en vez de la cadena "root" algo tal que "abcdefgjrhgdjfghd" nos diria que la contraseña es correcta.

Sabiendo ya como poder ejecutar ordenes el el sistema vamos a poner a la izquierda la orden anterior acompañado con un "y ejecuta también esto" o "|". Por ejemplo, si queremos saber en que directorio nos encontramos usando la orden "pwd" introduciriamos como campo contraseña lo siguiente:

root /etc/passwd | pwd > prueba | echo #

Donde al acceder al recurso "http://IP_Serv_Web/WackoPicko/prueba" nos mostraria el directorio donde esta WackoPicko. 

Ahora vamos a ejecutar lo anterior pero introduciendo más ordenes como listado del directorio, id del usuario y volcado del fichero "/etc/passwd":  

root /etc/passwd | pwd > prueba && ls >> prueba && id >> prueba && cat /etc/passwd >> prueba && ps -aux >> prueba | echo #

Teniendo en cuenta que gracias a esto ya podemos ir listando los directorios internos de la Web y que mediante un simple grep eliminando la shell "php" seriamos capaces de obtener el código completo de la página Web. Realizando este proceso llegamos a cosas tan originales como encontrar el fichero ourdb.php, existente en el directorio "include", donde se encuentra almacenado el usuario y la contraseña de la BBDD usada por la aplicación:

root /etc/passwd | grep -iv '<?php' include/ourdb.php > prueba | echo #

Devolviendo la web el siguiente mensaje:

Donde al acceder a prueba veriamos lo siguiente:

Con esta vulnerabilidad ya podriamos ser capaces de obtener todo el código fuente de la página Web y encontrar las vulnerabilidades como si de una caja blanca se tratara. A pesar de ello vamos a seguir auditando la web como si no hubieramos encontrado esta vulnerabilidad.

Una vez auditado la parte de registrar usuario, se va a proceder a auditar la parte de autenticación del usuario o Login existente en el recurso ("/users/login.php"). Primeramente introducimos un usuario no existente y luego un usuario existente (creado previamente) pero usando una contraseña incorrecta. Vemos que para ambos casos (casos fallidos) la respuesta de la web es la misma.

Este tipo de recursos web de autenticación suele presentar dos posibles vectores de ataque. El primero es mediante fuerza bruta al no tener ningún tipo de bloqueo por multiples intentos fallidos y la otra es por inyección de SQL: 

1. Si tenemos en cuenta que en el registro de usuarios podiamos averigurar que usuarios eran nuevos, lo único que tenemos que hacer es explotar dicha vulnerabilidad e intentar obtener una lista de usuarios validos. Posteriormente con Hydra podriamos intentar sacar una posible contraseña ejecuando una orden como la siguiente (en mi caso solo obtuve los usuarios que había creado yo previamente):
   hydra -L user.list -P /pentest/passwords/john/password.lst -s 80 -f IP_SERVIDOR  http-post-form "/WackoPicko/users/login.php:username=^USER^&password=^PASS^:invalid"
2. La segunda posibilidad es mediante inyección SQL, donde vemos que al introducir en el campo usuario (username) una comilla simple " ' " la web falla mostrando un mensaje de alerta típico de las MYSQL:
   You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\'', `salt`)) limit 1' at line 1
   Pues nada con un poco de SQL básico lo que tenemos que hacer es que la comprobación del SELECT siempre sea valido, por ejemplo introduciendo como usuario la condición siempre valida de que 3 es igual a 3, añadiendo al final la almohadilla "#" para omitir la parte derecha de la consulta original, empleando para ello la siguiente orden:
   admin' or 3=3#
   Gracias a esto podemos saltarnos la autenticación de la web, y por tanto, no requiriendo la contraseña.

Con los fallos documetados en esta entrada ya seriamos capaces de saltarnos la autenticación de la Web y ejecutar comandos en el entorno permitiendo entre otras: obtener el código fuente de la página Web, usuario y contraseña de la BBDD, información del sistema, ejecución de comandos con usuario no privilegiado y posibilidad de escalada de privilegios.

En la próxima entrada, y última del reto, veremos los otros fallos que he encontrado dando por finalizado WackoPicko hasta una próxima versión.