Vulnerabilidad en MongoDB permite la ejecución de código arbitrario en el servidor

El investigador de seguridad con sobrenombre de agixid, parte de la empresa franco-suiza SCRT, ha publicado una vulnerabilidad en el sistema de bases de datos MongoDB. Esta permite la ejecución de código remoto, manipulando el puntero utilizado por el método nativeHelper para ejecutar comandos del sistema. Ya ha sido publicado un exploit para el fallo.

MongoDB es un sistema de bases de datos no relacional de código abierto desarrollado por la compañía 10gen. Es una base de datos documental, esto es, que almacena sus datos de forma estructurada. En concreto, utiliza un formato extendido de JSON, llamado BSON, propio de este sistema. Actualmente es el sistema NoSQL más popular, contando con versiones para varios sistemas operativos, y siendo utilizado en los back-ends de empresas como SAP, SourceForge o Foursquare.

La investigación de agixid pretendía ahondar en los entresijos del método ‘run‘ del sistema para tratar de ejecutar código en el servidor. Este método ejecuta en una shell el comando que se le pase como parámetro (por ejemplo, ls en sistemas Linux). Sin embargo, este comando es sólo valido en el cliente y no permite ejecutar código a través de consultas al servidor.

Agidix descubrió que el método run simplemente realiza una llamada a nativeHelper, una función del motor JavaScript SpiderMonkey de Mozilla, pasando como parámetros un vector asociativo (run_) y el comando a ejecutar. Este vector run_ no está definido en el lado del servidor, pero sí se puede utilizar directamente un vector de la forma {“x”:0x01234}, por ejemplo, para suplirlo. El valor asociado a x apunta a la dirección de memoria de una función JavaScript, y que será ejecutada sin ninguna comprobación a través de un método de tipo NativeFunction. Al poder controlar el puntero a la función que se ejecuta, se puede ejecutar código arbitrario en el servidor.

La vulnerabilidad, con identificador CVE-2013-1892, ha sido probada en la versión 2.2.3 de MongoDB para sistemas de 32 bits. La rama 2.4 no se ve afectada, ya que se ha cambiado el motor JavaScript a V8, motor de Google, que no es vulnerable. Sin embargo, la última versión de la rama 2.2 (2.2.4) fue publicada el día 26 de marzo sin ninguna alusión a la vulnerabilidad. Por otro lado, ya se ha publicado un módulo en Metasploit para su explotación.

  

Francisco López