5984,6984 - Pentesting CouchDB
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CouchDB es una base de datos orientada a documentos versátil y poderosa que organiza los datos utilizando una estructura de mapa clave-valor dentro de cada documento. Los campos dentro del documento pueden representarse como pares clave/valor, listas o mapas, proporcionando flexibilidad en el almacenamiento y recuperación de datos.
Cada documento almacenado en CouchDB se le asigna un identificador único (_id) a nivel de documento. Además, cada modificación realizada y guardada en la base de datos se le asigna un número de revisión (_rev). Este número de revisión permite un seguimiento y gestión eficientes de los cambios, facilitando la recuperación y sincronización de datos dentro de la base de datos.
Puerto por defecto: 5984(http), 6984(https)
Esto emite una solicitud GET a la instancia de CouchDB instalada. La respuesta debería verse algo así como una de las siguientes:
Tenga en cuenta que si al acceder a la raíz de couchdb recibe un 401 Unauthorized con algo como esto: {"error":"unauthorized","reason":"Authentication required."} no podrá acceder al banner ni a ningún otro endpoint.
Estos son los endpoints a los que puede acceder con una GET request y extraer información interesante. Puede encontrar más endpoints y descripciones más detalladas en la documentación de couchdb.
/_active_tasks Lista de tareas en ejecución, incluyendo el tipo de tarea, nombre, estado e ID de proceso.
/_all_dbs Devuelve una lista de todas las bases de datos en la instancia de CouchDB.
**/_cluster_setup** Devuelve el estado del nodo o clúster, según el asistente de configuración del clúster.
/_db_updates Devuelve una lista de todos los eventos de base de datos en la instancia de CouchDB. La existencia de la base de datos _global_changes es necesaria para usar este endpoint.
/_membership Muestra los nodos que son parte del clúster como cluster_nodes. El campo all_nodes muestra todos los nodos que este nodo conoce, incluyendo los que son parte del clúster.
/_scheduler/jobs Lista de trabajos de replicación. Cada descripción de trabajo incluirá información de origen y destino, ID de replicación, un historial de eventos recientes y algunas otras cosas.
/_scheduler/docs Lista de estados de documentos de replicación. Incluye información sobre todos los documentos, incluso en estados completed y failed. Para cada documento, devuelve el ID del documento, la base de datos, el ID de replicación, origen y destino, y otra información.
/_scheduler/docs/{replicator_db}
/_scheduler/docs/{replicator_db}/{docid}
/_node/{node-name} El endpoint /_node/{node-name} se puede usar para confirmar el nombre del nodo Erlang del servidor que procesa la solicitud. Esto es más útil al acceder a /_node/_local para recuperar esta información.
/_node/{node-name}/_stats El recurso _stats devuelve un objeto JSON que contiene las estadísticas del servidor en ejecución. La cadena literal _local sirve como un alias para el nombre del nodo local, por lo que para todas las URL de estadísticas, {node-name} puede ser reemplazado por _local, para interactuar con las estadísticas del nodo local.
/_node/{node-name}/_system El recurso _system devuelve un objeto JSON que contiene varias estadísticas a nivel de sistema para el servidor en ejecución_._ Puede usar ___local como {node-name} para obtener información del nodo actual.
/_node/{node-name}/_restart
/_up Confirma que el servidor está activo, en funcionamiento y listo para responder a solicitudes. Si maintenance_mode es true o nolb, el endpoint devolverá una respuesta 404.
**/_uuids** Solicita uno o más Identificadores Únicos Universales (UUIDs) de la instancia de CouchDB.
**/_reshard** Devuelve un conteo de trabajos completados, fallidos, en ejecución, detenidos y totales junto con el estado de re-particionamiento en el clúster.
Se puede extraer información más interesante como se explica aquí: https://lzone.de/cheat-sheet/CouchDB
Si esa solicitud responde con un 401 no autorizado, entonces necesitas algunas credenciales válidas para acceder a la base de datos:
Para encontrar credenciales válidas, podrías intentar forzar el servicio.
Este es un ejemplo de una respuesta de couchdb cuando tienes suficientes privilegios para listar bases de datos (Es solo una lista de bases de datos):
Puedes obtener información de la base de datos (como el número de archivos y tamaños) accediendo al nombre de la base de datos:
Lista cada entrada dentro de una base de datos
Leer el contenido de un documento dentro de una base de datos:
Gracias a las diferencias entre los analizadores JSON de Erlang y JavaScript, podrías crear un usuario administrador con las credenciales hacktricks:hacktricks con la siguiente solicitud:
Más información sobre esta vulnerabilidad aquí.
Ejemplo de aquí.
En la documentación de CouchDB, específicamente en la sección sobre la configuración del clúster (enlace), se discute el uso de puertos por CouchDB en modo clúster. Se menciona que, al igual que en modo independiente, se utiliza el puerto 5984. Además, el puerto 5986 es para APIs locales de nodo, y lo más importante, Erlang requiere el puerto TCP 4369 para el Demonio de Mapeo de Puertos de Erlang (EPMD), facilitando la comunicación entre nodos dentro de un clúster de Erlang. Esta configuración forma una red donde cada nodo está interconectado con todos los demás nodos.
Se destaca un aviso de seguridad crucial respecto al puerto 4369. Si este puerto se hace accesible a través de Internet o cualquier red no confiable, la seguridad del sistema depende en gran medida de un identificador único conocido como "cookie". Esta cookie actúa como una salvaguarda. Por ejemplo, en una lista de procesos dada, se podría observar la cookie llamada "monster", lo que indica su papel operativo en el marco de seguridad del sistema.
Para aquellos interesados en entender cómo se puede explotar esta "cookie" para la Ejecución Remota de Código (RCE) en el contexto de sistemas Erlang, hay una sección dedicada disponible para una lectura más profunda. Detalla las metodologías para aprovechar las cookies de Erlang de maneras no autorizadas para lograr el control sobre los sistemas. Puedes explorar la guía detallada sobre el abuso de cookies de Erlang para RCE aquí.
Ejemplo de aquí.
Se exploró una vulnerabilidad recientemente divulgada, CVE-2018-8007, que afecta a Apache CouchDB, revelando que la explotación requiere permisos de escritura en el archivo local.ini. Aunque no es directamente aplicable al sistema objetivo inicial debido a restricciones de seguridad, se realizaron modificaciones para otorgar acceso de escritura al archivo local.ini con fines de exploración. A continuación se proporcionan pasos detallados y ejemplos de código que demuestran el proceso.
Primero, se prepara el entorno asegurando que el archivo local.ini sea escribible, verificado al listar los permisos:
Para explotar la vulnerabilidad, se ejecuta un comando curl, dirigido a la configuración cors/origins en local.ini. Esto inyecta un nuevo origen junto con comandos adicionales bajo la sección [os_daemons], con el objetivo de ejecutar código arbitrario:
La verificación subsiguiente muestra la configuración inyectada en local.ini, contrastándola con una copia de seguridad para resaltar los cambios:
Inicialmente, el archivo esperado (/tmp/0xdf) no existe, lo que indica que el comando inyectado aún no se ha ejecutado. Una investigación adicional revela que hay procesos relacionados con CouchDB en ejecución, incluyendo uno que podría potencialmente ejecutar el comando inyectado:
Al terminar el proceso de CouchDB identificado y permitir que el sistema lo reinicie automáticamente, se activa la ejecución del comando inyectado, confirmado por la existencia del archivo que faltaba anteriormente:
Esta exploración confirma la viabilidad de la explotación de CVE-2018-8007 bajo condiciones específicas, notablemente el requisito de acceso escribible al archivo local.ini. Los ejemplos de código proporcionados y los pasos procedimentales ofrecen una guía clara para replicar la explotación en un entorno controlado.
Para más detalles sobre CVE-2018-8007, consulta el aviso de mdsec: CVE-2018-8007.
Ejemplo de aquí.
Se exploró una vulnerabilidad conocida como CVE-2017-12636, que permite la ejecución de código a través del proceso de CouchDB, aunque configuraciones específicas pueden prevenir su explotación. A pesar de las numerosas referencias de Prueba de Concepto (POC) disponibles en línea, son necesarios ajustes para explotar la vulnerabilidad en la versión 2 de CouchDB, que difiere de la versión 1.x comúnmente atacada. Los pasos iniciales implican verificar la versión de CouchDB y confirmar la ausencia de la ruta esperada de los servidores de consulta:
Para acomodar la versión 2.0 de CouchDB, se utiliza una nueva ruta:
Los intentos de agregar e invocar un nuevo servidor de consultas se encontraron con errores relacionados con los permisos, como se indica en la siguiente salida:
Una investigación adicional reveló problemas de permisos con el archivo local.ini, que no era escribible. Al modificar los permisos del archivo con acceso root o homer, se volvió posible continuar:
Los intentos posteriores de agregar el servidor de consultas tuvieron éxito, como lo demuestra la falta de mensajes de error en la respuesta. La modificación exitosa del archivo local.ini se confirmó a través de la comparación de archivos:
El proceso continuó con la creación de una base de datos y un documento, seguido de un intento de ejecutar código a través de un mapeo de vista personalizado al servidor de consultas recién agregado:
Un resumen con una carga útil alternativa proporciona más información sobre la explotación de CVE-2017-12636 bajo condiciones específicas. Recursos útiles para explotar esta vulnerabilidad incluyen:
port:5984 couchdb
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
