dungsocool/cve-2017-12635_36Laboratorio paso a paso que demuestra la explotación de CVE-2017-12635 (escalada de privilegios) y CVE-2017-12636 (ejecución remota de código) contra Apache CouchDB 1.6.0, con evaluación de riesgos y guía de remediación.
Comenzando con lo que se está ejecutando en el entorno. Listo todos los contenedores activos:
docker ps
La víctima expone un único puerto: 5984
⇒ Hago curl directamente a él para obtener más información:
curl -i http://192.168.3.137:5984/
Analizando la respuesta:
Respuesta: HTTP/1.1 200 OK, lo que demuestra que el servicio en el puerto 5984 está activo y se puede acceder directamente a través de HTTP.
Cabecera del servidor: CouchDB/1.6.0 (Erlang OTP/17) y el cuerpo JSON que contiene "version":"1.6.0" confirman que se trata de Apache CouchDB versión 1.6.0.
Evaluación de la Superficie de Ataque:
El servicio CouchDB está expuesto externamente a través del puerto 5984. Este es el puerto predeterminado para la API HTTP de CouchDB, permitiendo la interacción con la base de datos a través de una API REST.
La versión CouchDB 1.6.0 es una versión antigua, anterior al parche 1.7.1. Según la documentación de Apache, las versiones de CouchDB en este rango se ven afectadas por:
roles duplicadas en JSON.=> Pensamiento: A partir de la respuesta obtenida, hay suficiente evidencia para determinar que la víctima está ejecutando Apache CouchDB 1.6.0 en el puerto 5984. Esta es una versión antigua asociada con la cadena de explotación de CVE-2017-12635 y CVE-2017-12636. Por lo tanto, una ruta de explotación lógica es primero probar el estado de autenticación y luego evaluar el potencial de escalada de privilegios o ejecución de comandos a través de la API HTTP de CouchDB.
CVE-2017-12635 explota la discrepancia entre dos analizadores JSON en CouchDB. Al enviar un documento de usuario a /_users con dos claves roles duplicadas, CouchDB usa la segunda clave roles para verificar los privilegios de escritura del documento, pero usa la primera clave roles para los permisos reales del usuario después de la creación. Por lo tanto, un atacante establece el primer roles en ["_admin"] y el segundo roles en [] para eludir la verificación de validación, lo que resulta en que el usuario creado tenga privilegios de administrador.
Según la documentación de CouchDB, CouchDB almacena la información del usuario en una base de datos especial llamada _users, donde cada documento de usuario tiene un ID con el formato org.couchdb.user:<username>. Dado que necesitamos crear un usuario llamado hacker, el endpoint utilizado es /_users/org.couchdb.user:hacker. Creo un nuevo usuario y le asigno privilegios de administrador para ver cómo responde el servidor.
curl -X PUT http://192.168.3.137:5984/_users/org.couchdb.user:hacker \
-H "Content-Type: application/json" \
-d '{
"type": "user",
"name": "hacker",
"roles": ["_admin"],
"roles": [],
"password": "password123"
}'
La respuesta devuelta es true, lo que demuestra que el usuario se creó correctamente. Realizo una verificación utilizando las credenciales de administrador recién creadas: curl -u hacker:password123 http://192.168.3.137:5984/_users. El endpoint /_users es una base de datos del sistema, que por defecto solo los administradores pueden leer sus metadatos. Si lo solicita un usuario normal → 403 Forbidden. La respuesta 200 OK con información completa de la base de datos confirma que la cuenta hacker efectivamente tiene privilegios de _admin. Esto se alinea perfectamente con la hipótesis de CVE-2017-12635 en Apache CouchDB 1.6.0.
Resumen:
He verificado con éxito CVE-2017-12635 en Apache CouchDB 1.6.0. Inicialmente, el puerto 5984 solo mostraba que la API HTTP de CouchDB estaba expuesta. Después de la huella digital mediante curl, la respuesta confirmó que el servicio es CouchDB 1.6.0, una versión dentro del rango de vulnerabilidad de CVE-2017-12635.
En lugar de concluir inmediatamente que RCE es posible, verifiqué el flujo de autenticación paso a paso primero. Al enviar un documento de usuario a /_users con dos claves roles duplicadas, la carga útil creó exitosamente al usuario hacker. A continuación, la solicitud a /_users mediante curl -u hacker:password123 devolvió 200 OK junto con detalles de la base de datos del sistema, lo que demuestra que el usuario hacker realmente posee privilegios de _admin.
En consecuencia, una vez adquiridos los privilegios de administrador de CouchDB, la superficie de ataque se expande a CVE-2017-12636, ya que los administradores pueden modificar la configuración de CouchDB a través de la API HTTP. Esto sirve como requisito previo para evaluar más a fondo las capacidades de ejecución remota de código en el servidor.
⇒ Pensamiento: Usar los privilegios de administrador recién adquiridos para probar la ejecución de comandos a nivel de SO.
Según la Documentación de Apache CouchDB, un Query Server es un proceso externo utilizado por CouchDB para procesar funciones de diseño, como una vista JavaScript en el mecanismo MapReduce. Cuando un documento de diseño declara un campo "language", CouchDB utiliza este valor para buscar el servidor de consulta correspondiente en la configuración query_servers.
Si el documento de diseño contiene "language": "javascript", CouchDB consulta la configuración query_servers.javascript para determinar qué proceso debe iniciarse para manejar la función map/reduce. Esto es un diseño legítimo de CouchDB, ya que el núcleo de CouchDB no ejecuta directamente todo el código de vista dentro del motor de base de datos.
⇒ El problema en CVE-2017-12636 reside en la capacidad de un administrador de CouchDB para modificar la configuración del servidor a través de la API HTTP. Algunas de estas configuraciones incluyen rutas a binarios o procesos a nivel de sistema operativo que CouchDB lanzará. Por lo tanto, después de obtener privilegios de administrador mediante CVE-2017-12635, un atacante puede modificar query_servers.<language> para que apunte a un comando del SO. Al activar una vista que utiliza el idioma correspondiente, CouchDB iniciará el comando, resultando en la ejecución de comandos en el servidor.
Flujo de Explotación:
query_servers.cmd a través del endpoint /_config."language": "cmd".query_servers.cmd e inicia el proceso configurado.