El objetivo es aprender cómo encontrar fallos de autenticación en aplicaciones web y también cómo explotarlos.

Ataques de diccionario

El método más obvio de ataque a un formulario web de autenticación es conseguir las credenciales por fuerza bruta.

Pero en esta clase de fuerza bruta no intentamos simplemente números o caracteres alfabéticos simples. Lo que hacemos es usar un diccionario de usuarios y contraseñas que son lo más comunes y ver si podemos encontrar la combinación correcta.

A esto se le conoce como ataque de diccionario.

Para realizarlo, hay multitud de herramientas, como Hydra o Medusa, pero el problema con estas herramientas de líneas de comando es que necesitamos pasarles un montón de argumentos y eso puede resultar confuso.

Por eso, cuando intentemos un ataque de diccionario en un formulación de aplicación web, es más cómodo usar Burp Suit.

De este modo, capturamos la petición de autenticación en Burp y usamos Intruder para realizar el ataque.

Para eso:

  1. Nos conectamos al puerto 8888 de la máquina objetivo de esta habitación.
  2. Ahora, mientras que en Burp tenemos la captura activada y en Firefox tenemos Foxy Proxy activado con Burp (recordemos cómo configurar Burp con Firefox si se nos ha olvidado), introducimos los valores que queramos dentro de los campos usuario y contraseña que hay en la página.
  3. Enviamos esa petición a Intruder y, para la posición del payload, simplemente vamos a tratar de adivinar la contraseña del usuario jack. Como payload podemos usar cualquier lista de contraseñas por defecto, o una parte de la conocida lista rockyou.
  4. Comenzamos el ataque y esperamos un poco, si todo es correcto, notaremos que una de las peticiones enviadas genera una respuesta más larga que las demás.

Ataque de fuerza bruta con Burp

Como podemos ver en la imagen superior, el valor de la quinta respuesta es 530, mientras que el resto es de 480. Esto puede significar que Burp ha sido capaz de identificarse correctamente en la cuenta de jack con la contraseña 12345678.

Respondemos a las preguntas.

¿Cuál es la bandera encontrada cuando te identificas como Jack?

fad9ddc1feebd9e9bca05f02dd89e271

Ahora intentamos lo mismo para el usuario mike, ¿cuál es la bandera encontrada?

Repito el proceso y pruebo a pegar como payload una sencilla lista de unas 200 palabras habituales.

La contraseña sale enseguida (12345).

e1faaa144df2f24aa0a9284f4a5bb578

Re-registro

Muchas veces, un desarrollador olvida sanear el input del usuario (usuario y contraseña), lo que puede hacer que el código sea vulnerable a cosas como inyección SQL.

Pero eso puede ser difícil de explotar, así que nos vamos a centrar en una vulnerabilidad mucho más fácil, el re-registro de un usuario existente.

Entendamos esto con un ejemplo.

En una aplicación existe un usuario admin y queremos acceder a su cuenta. Lo que podemos hacer es registrar de nuevo ese usuario con una pequeña modificación.

Vamos a introducir « admin», con ese espacio al principio. Así, el nuevo usuario se registrará (porque no existe), pero tendrá los mismos privilegios que admin si ocurre ese fallo de saneamiento.

Vayamos a la máquina desplegada y tratemos de registrar el nombre de usuario darren. Nos va a decir que ya existe, de modo que registramos « darren».

Veremos que podremos ver el contenido del usuario darren, que en este caso es la bandera que precisamos.

fe86079416a21a3c99937fea8874b667

Seguimos el mismo proceso con arthur, ¿cuál es su bandera?

d9ac0f7db4fda460ac3edeb75d75e16e

Token web JSON

El JSON Web Token (JWT) es uno de los métodos más habituales de autorización. Es una clase de cookie que se genera usando hashing HMAC o llaves públicas/privadas.

Así que, como cualquier otra clase de cookie, le permite conocer al sitio qué clase de acceso tiene el usuario que está actualmente identificado.

Lo único especial de JWT es que está en formato JSON (después de decodificarlo).

JWT puede estar dividido en 3 partes separadas por un punto (.):

  1. Cabecera. Consiste en el algoritmo usado y el tipo de token { “alg”: “HS256”, “typ”: “JWT”} donde alg puede ser HMAC, RSQ, SHA256 o incluso el valor none.
  2. Payload. La parte que contiene el acceso concedido a cierto usuario, etc. Esto puede variar de sitio web en sitio web, algunos pueden tener un simple nombre de usuario y algún ID, pero otros pueden tener muchos otros detalles.
  3. Firma. Es la parte usada para asegurar la integridad de los datos mientras se transfieren. Está encriptada con el algoritmo alg que se haya pasado como valor en la cabecera. Solo puede ser desencriptado por un secreto predefinido (que debería ser difícil).

Poner las 3 partes juntas y codificarlas habiéndolas separado por un punto (.) asemejaría a algo como esto:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Ese ejemplo ha sido tomado de jwt.io y es interesante echar un vistazo para saber más sobre JWT.

Explotación

Usado adecuadamente, es una manera muy segura de autenticación. El problema es «adecuadamente». Muchos desarrolladores configuran mal el sistema, dejándolo abierto a explotación.

Uno de los métodos de explotación es usar fuerza bruta con diccionario para encontrar el secreto con el que se ha encriptado el token JWT y usarlo para generar nuevos tokens.

Pero aquí vamos a ver otra interesante manera de explotar los JWT.

Si recordamos, en la sección de cabecera se ha dicho que alg puede ser cualquier algoritmo o incluso ninguno, si es que no se utilizó encriptación.

Esto último no debería usarse nunca en producción, pero si hay una mala configuración…

El ataque consiste en que alguien puede identificarse como usuario de bajo privilegio, obtener el token JWT de ese usuario, decodificarlo y editar las cabeceras para poner el valor de alg a None.

Esto significaría que no se ha usado encriptación y el atacante no necesitaría por tanto conocer el secreto.

En la práctica

Vamos a ver este método en la práctica, visitando el puerto 5000 de la máquina de la habitación.

Es una página muy sencilla de autenticación y podemos identificarnos como dos usuarios: user y user2.

Vamos primero a autenticarnos con las credenciales user:user y cuando lo hagamos, capturamos la petición en Burp.

Veremos que hay una petición a /protected y también que hay un token JWT.

Ataque a JWT

Ahora cogemos este token y lo decodificamos trozo a trozo.

Si decodificamos la primera parte, nos dará:

{“typ”:“JWT”,“alg”:“HS256”}

La segunda es:

{“exp”:1586620929,“iat”:1586620629,“nbf”:1586620629,“identity”:1}

Si tratamos de decodificar la tercera, nos dará cosas sin sentido, pero no pasa nada porque solo necesitamos las dos anteriores.

Ahora, si miramos el valor identity, probablemente se usa para identificar al usuario, pero editarlo no funcionará, porque como ya hemos dicho, la tercera parte está encriptada.

Para superar esto precisamos hacer cambios en la cabecera, así como en el valor identidad.

Codificamos lo siguiente en Base64 y esa será nuestra primera parte.

{“typ”:“JWT”,“alg”:“NONE”}

Para la segunda, codificamos esta cadena.

{“exp”:1586620929,“iat”:1586620629,“nbf”:1586620629,“identity”:2}

Observa cómo hemos cambiado identity 1 por identity 2.

La cuestión es que, como hemos cambiado el valor del algoritmo a ninguno, no precisamos tercera parte con valor encriptado, podemos poner simplemente un punto después de la segunda parte.

De esa manera, la cadena final quedaría así.

eyJ0eXAiOiJKV1QiLCJhbGciOiJOT05FIn0K.eyJleHAiOjE1ODY3MDUyOTUsImlhdCI6MTU4NjcwNDk5NSwibmJmIjoxNTg2NzA0OTk1LCJpZGVudGl0eSI6MH0K.

Ahora, abrimos las herramientas de desarrollo de nuestro navegador y editamos la cookie guardada del sitio es esta nueva y pulsamos el botón Go, de manera que veremos cómo la aplicación nos recibe con: “Welcome user2:guest2”.

Este tipo de configuración errónea es común y podría ser explotada para escalar privilegios y robar información.

Usando este método, ¿cuál es la bandera del usuario admin? La pista nos advierte de que el valor de la identidad del admin será el uid del usuario root en Linux, es decir, cero.

92498880383088033228

No auth

En algunos casos, no hay siquiera una autenticación apropiada y el sistema está abierto a que cualquiera pueda explotarlo.

Cuando te registrar y te autenticas, a veces te conceden un cierto id que es un número o acaba en uno. En muchas ocasiones, los desarrolladores aseguran sus aplicaciones, pero a veces, en algunos lugares, puede ocurrir que cambiando ese número podamos ver datos ocultos o privados.

Para probar esto, nos vamos al puerto 7777 de la máquina y creamos una cuenta. Con ella, visitamos nuestro espacio privado.

Explotando No Auth

Como podemos ver en la imagen, la URL contiene /users/1. Tratamos de cambiar a valor 2 para acceder a la cuenta de administración.

Explotando No Auth

Las probabilidades de encontrar esta vulnerabilidad son muy bajas, pero quién sabe si podemos ser afortunados.

Debemos encontrar la manera de entrar en el espacio del superadmin.

ponemos users/0 guiados por la lógica anterior del uid de root en Linux y aparece.

¿Cuál es su contraseña?

abcd1234

¿Cuál es su bandera?

72102933396288983011