Cómo funcionan las MongoDB Injection

Las inyecciones SQL han sido tradicionalmente uno de los vectores de ataque más utilizados por los atacantes. De hecho, es una de las técnicas más eficaces para el robo y la alteración de información sensible. Sin embargo, no existe (aún) una marcada tendencia hacia la explotación de las llamadas bases de datos NoSQL, o sea, bases de datos no relacionales pensadas para el almacenamiento de grandes cantidades de información. De entre todas estas bases de datos NoSQL, quizá el representante más ilustre sea MongoDB. ¿Es inmune a las inyecciones?

¿Qué es MongoDB?

El nombre MongoDB, viene del inglés “humongous” (inmenso). Es un sistema de base de datos no relacional de código abierto y orientado a documentos. MongoDB se basa en colecciones de documentos Json, lo que le otorga una gran flexibilidad en cuanto a la naturaleza de la información que almacena, puesto que puede haber documentos con diferente esquema dentro de una misma colección.

De MongoDB destaca su gran velocidad y escalabilidad, porque puede manejar sin apenas esfuerzo volúmenes de datos del orden de gigabytes. En los últimos tiempos, su nómina de clientes ha crecido considerablemente; Foursquare, MTV, The New York Times, etc. ya lo utilizan.

¿Es MongoDB vulnerable a inyecciones?


Al no tratarse de una base de datos SQL, podría parecer que MongoDB no es vulnerable a inyecciones maliciosas. Sin embargo, veremos que no es así. Se pueden realizar muchos tipos de inyecciones en MongoDB, aunque la viabilidad del ataque depende en gran medida del driver de Mongo utilizado.

Por ejemplo, en PHP es posible realizar una inyección muy similar a la clásica inyección SQL, alterando la consulta de manera que devuelva todo el contenido de una colección.
Imaginemos la típica consulta de credenciales que hay tras un login. En SQL, sería algo como lo que sigue:

SELECT * FROM tUsers WHERE username = ‘username’ AND password = ‘password’


La consulta equivalente en MongoDB sería:

$collection -> find(array( 
 “username” => $_GET[‘username’], 
 “password” => $_GET[‘password’]
)); 

El problema es que PHP permite pasarle objetos al driver de MongoDB, sin que tengan que ser necesariamente strings. Explotando esta vulnerabilidad, podemos pasar un objeto que fuerce una condición “true” y provoque el volcado de la colección. Por ejemplo, enviando una petición como esta:

login.php?username=administrador&password[$ne]=1

Obtendríamos una consulta interna de esta forma:

$collection -> find(array( 
 “username” => “administrador”
 “password” => array(“$ne” => 1)
)); 

Esta consulta devuelve las credenciales de todos los usuarios cuyo nombre de usuario y contraseña sea distinto (“not equal”, $ne) de 1, condición que probablemente cumpla cualquier contraseña.

La solución pasa por “tipar” los objetos que se le pasan al driver. El hecho de que muchos drivers de MongoDB admitan objetos no tipados supone una vulnerabilidad.

¿Cómo comprobar si se es vulnerable?

Como no podía ser de otra manera, Faast incorpora entre su batería de plugins, uno capaz de detectar vulnerabilidades de este tipo. Sin embargo, como ya se ha mencionado, la presencia de esta vulnerabilidad depende enormemente del driver utilizado en el dominio bajo análisis.

Existen multitud de drivers para MongoDB. El plugin de Faast está orientado a detectar inyecciones en MongoDB, aprovechando la capacidad del motor Mongo para ejecutar Javascript. Utiliza la técnica de time-based detection para determinar si la URL que recibe como parámetro es vulnerable, aprovechando a su vez el comando “sleep” de MongoDB, que bloquea todas las operaciones de la base de datos durante un determinado período de tiempo.

Por ejemplo, tras recibir la URL, el plugin de Faast realiza dos peticiones independientes, concatenando las siguientes cadenas a la URL original. En la primera se ejecuta un sleep durante 10 segundos, en la segunda, no.

;if(tojson(this)[0] ==”{“)) {sleep(“10000”)};
;if(tojson(this)[0] ==”{“)) {sleep(“0”)}

Para determinar si es posible inyectar, se compara el tiempo de respuesta de ambas peticiones. Si la diferencia de tiempos es superior a un determinado umbral, se considera positivo y por tanto la URL es vulnerable. Para minimizar la influencia de tiempos de propagación, etc… y evitar falsos positivos, la prueba se repite un número determinado de veces. Será necesario que el resultado de los N intentos sea positivo para considerar la URL como vulnerable.

El auge que están viviendo los motores de bases de datos no relacionales, hace que se conviertan en un objetivo prioritario para los atacantes. Aunque las inyecciones SQL siguen siendo frecuentes, ya no representan una novedad en el mundo del cibercrimen, y las recetas y buenas prácticas para evitarlas están muy estudiadas. Sin embargo, las bases de datos NoSQL suponen un territorio nuevo que explorar. Por eso Faast pretende adelantarse a los atacantes y facilitar que se tomen las medidas adecuadas para salvaguardar la integridad de los datos de los clientes.