NeoVault

Se nos proporciona un sitio web como este:

Enumeración

Un vistazo rápido al código fuente del sitio web nos indica que está construido con Next.js. Por lo tanto, podemos encontrar rutas disponibles en los archivos de JavaScript:

Como se puede ver, hay dos versiones de la API: v1 y v2. Debemos comprobar si los endpoints de v1 son accesibles. Si lo son, podrían tener algunas vulnerabilidades que fueron corregidas en v2:

$ curl -X GET 94.237.49.23:42577/api/v1/auth/me
{"message":"API v1 is deprecated, please use the new one instead"}
$ curl -X POST 94.237.49.23:42577/api/v1/auth/login
{"message":"API v1 is deprecated, please use the new one instead"}
$ curl -X POST 94.237.49.23:42577/api/v1/transactions/download-transactions
{"message":"Unauthorized"}
$ curl -X POST 94.237.49.23:42577/api/v1/transactions
{"message":"Unauthorized"}

Algunos de los endpoints no son accesibles, pero los de /api/v1/transactions parecen estar accesibles, aunque necesitamos estar autenticados. Así que, vamos a crear una cuenta e iniciar sesión:

¡Sorprendentemente, hemos recibido 100$ de crédito de bonificación!

Vamos a descargar el archivo PDF con los detalles:

Con esto, sabemos el nombre de la otra cuenta: neo_system.

Solución

Vamos a inspeccionar la petición web que generó el archivo PDF:

Vemos que proviene de /api/v2/transactions/download-transactions. ¿Y si lo cambiamos para usar la API v1?

Necesitamos proporcionar un _id. Para quienes no estén familiarizados, este _id probablemente provenga de una base de datos MongoDB, que se usa como un identificador de objeto, y no debería ser devuelto al usuario, ya que identifica claramente la base de datos utilizada por el servidor.

Si actualizamos la página y vamos nuevamente a “Transactions”, veremos una petición que toma la información de la transacción, y podemos ver el _id del usuario neo_system:

Entonces, vamos a usar eso para descargar las transacciones de este usuario usando ese _id:

La petición fue exitosa, así que podemos decir que la API v1 del servidor es vulnerable a Insecure Direct Object Reference (IDOR), ya que podemos descargar cualquier archivo PDF con información sensible mientras conozcamos el _id de un usuario existente.

Ahora, podemos guardar la respuesta como un archivo PDF y revisarlo:

Parece haber otro usuario llamado user_with_flag. Como su nombre lo sugiere, este usuario tiene la flag. Así que, intentemos obtener un PDF como este usuario.

Esto puede ser bastante difícil ya que no conocemos el _id de este usuario. Sin embargo, podemos suponer que el servidor tiene otra vulnerabilidad relacionada con MongoDB, concretamente que podría ser vulnerable a inyección NoSQL. Un payload típico para explotar vulnerabilidades de NoSQLi es usar un filtro $ne, de modo que los resultados proporcionados por MongoDB no coincidan con algún patrón. Por ejemplo, usemos {"$ne": "x"}:

Bueno, el servidor requiere un formato válido de _id, así que usemos el que teníamos antes:

Flag

Después de guardar la respuesta como archivo PDF, encontramos la flag:

HTB{n0t_s0_3asy_1d0r}