NoSQLI Lab 1

Skills

• Detecting NoSQL injection

Certificaciones

• eWPT
• eWPTXv2
• OSWE
• BSCP

Descripción

Este laboratorio utiliza un filtro de categoría de producto que está impulsado por una base de datos NoSQL en MongoDB. Es vulnerable a una inyección NoSQL. Para resolver el laboratorio, debemos realizar un ataque de inyección NoSQL que haga que la aplicación muestre productos no lanzados

---

Resolución

Al acceder a la web vemos esto

Si hacemos click sobre una categoría, la web nos redirige a https://0a54001f047c9ab1803bb2bf00d800cb.web-security-academy.net/filter?category=Gifts

Hay dos tipos de inyección NoSQL

• Syntax Injection - Ocurre cuando se puede romper la sintaxis de la consulta NoSQL, lo que le permite inyectar su propia carga útil. La metodología es similar a la utilizada en la inyección SQL. Sin embargo, la naturaleza del ataque varía significativamente, ya que las bases de datos NoSQL utilizan una variedad de lenguajes de consulta, tipos de sintaxis de consulta y diferentes estructuras de datos

• Operator Injection - Ocurre cuando puedes usar operadores de consulta NoSQL para manipular consultas

En este laboratorio vamos a explotar una Syntax Injection. Es posible detectar vulnerabilidades de inyección NoSQL al intentar romper la sintaxis de la consulta. Para ello, debemos probar cada input enviando cadenas de datos fuzz y caracteres especiales que desencadenen un error de base de datos o algún otro comportamiento detectable si la aplicación no los sanitiza o filtra adecuadamente. Debemos usar caracteres especiales y cadenas de fuzz enfocadas al lenguaje de programación que use la API de la base de datos, de lo contrario, debemos utilizar una amplia variedad de cadenas de fuzz para cubrir varios lenguajes de API. En este caso, esta es una cadena bastante completa

'"`{
;$Foo}
$Foo \xYZ

En el caso de que tengamos que introducir el payload en una URL, este debe estar encodeado

%27%22%60%7b%0d%0a%3b%24Foo%7d%0d%0a%24Foo%20%5cxYZ%00

Podemos codificar estas cadenas usando el Decoder de Burp Suite o usando la extensión Hackvertor. Con Hackvertor tenemos varias formas de URL encoding.

• urlencode - Esta función realiza una codificación estándar de URL. En este caso, se codifican todos los caracteres especiales en la URL y se reemplazan por su representación en formato hexadecimal precedida por un %. Sin embargo, un detalle importante es que los espacios se codifican como +

• urlencode_all - Esta función es más exhaustiva en su enfoque. Codifica todos los caracteres, incluyendo los no imprimibles y especiales, que normalmente no se codificarían en una URL estándar

• urlencode_not_plus - Esta función es similar a la función urlencode, pero con una diferencia clave, no codifica los espacios como +, sino que los mantiene como %20, que es la representación estándar de un espacio en las URL

• burp_urlencode - Esta función realiza una codificación estándar de URL como la función urlencode, pero optimizada para Burp Suite para evitar problemas con proxies y herramientas de seguridad

Las vulnerabilidades de inyección NoSQL pueden ocurrir en una variedad de contextos y es necesario adaptar las cadenas de fuzzing en consecuencia. De lo contrario, es posible que se produzcan errores de validación que hagan que la aplicación nunca ejecute la consulta. El payload anterior está preparado para ser inyectado en una URL, por lo que la cadena está URL encodeada. En algunas aplicaciones, es posible que debamos inyectar el payload a través de un JSON. En ese caso, deberíamos adaptar el payload, lo cual daría esta cadena como resultado

'\"`{\r;$Foo}\n$Foo \\xYZ\u0000`

Para determinar qué caracteres interpreta la aplicación como sintaxis, podemos probar a inyectar caracteres individuales. En este caso, al añadir una comilla simple ' provocamos un error, el cual vemos al acceder a https://0ac100b804c954f18566cbf6003f001e.web-security-academy.net/filter?category=Gifts'. No urlencodear nada porque lo hace el navegador por nosotros. Nos damos cuenta de que estamos ante un MongoDB, esta base de datos no relacional usa como lenguaje JavaScript

Si escapamos la comilla simple \', la consulta ya no provoca el error al acceder a https://0ac100b804c954f18566cbf6003f001e.web-security-academy.net/filter?category=Gifts\'

Después de detectar una vulnerabilidad, el siguiente paso es determinar si se pueden influir en las condiciones booleanas mediante la sintaxis NoSQL. Para probar esto, debemos enviar dos solicitudes, una con una condición falsa como ' && 0 && 'x y otra con una condición verdadera como ' && 1 && 'x. Primero vamos a probar con la condición falsa, para ello vamos a tener que urlencodear el payload con cualquier codificación que no sea la de urlencode_not_plus. Vemos que no nos salen los tres productos que nos salían anteriormente al acceder a https://0ac100b804c954f18566cbf6003f001e.web-security-academy.net/filter?category=Gifts%27+%26%26+0+%26%26+%27x

Probamos con la condición verdadera, al acceder a https://0ac100b804c954f18566cbf6003f001e.web-security-academy.net/filter?category=Gifts%27+%26%26+1+%26%26+%27x vemos que sí salen los tres productos. Esto sugiere que la condición falsa afecta la lógica de la consulta, pero la condición verdadera no y, por lo tanto, confirmamos la existencia de una Syntax Injection

Ahora que hemos identificado que podemos influir en las condiciones booleanas, podemos intentar anular las condiciones existentes para aprovechar la vulnerabilidad. Por ejemplo, inyectando una condición de JavaScript que siempre se evalúe como verdadera, como '||'1'=='1. Esto nos llevaría a https://0ac100b804c954f18566cbf6003f001e.web-security-academy.net/filter?category=Gifts%27||%271%27%3d%3d%271 y nos mostraría todos los productos existentes independientemente de la categoría. Debemos tener cuidado al inyectar una condición que siempre se evalúa como verdadera en una consulta NoSQL. Si bien esto puede ser inofensivo en el contexto inicial en el que está inyectando, es común que las aplicaciones utilicen datos de una sola solicitud en varias consultas diferentes. Si una aplicación lo usa al actualizar o eliminar datos, por ejemplo, esto puede provocar una pérdida de datos accidental

También podemos agregar un Null Byte %00 después del valor de la categoría. MongoDB puede ignorar todos los caracteres después de un Null Byte, lo que significa que se ignoran todas las condiciones adicionales en la consulta de MongoDB. No es necesario URL encodear el payload en este caso https://0ac100b804c954f18566cbf6003f001e.web-security-academy.net/filter?category=Gifts%27%00