Server Header: CouchDB/1.6.0 (Erlang OTP/17) and the JSON body containing "version":"1.6.0" confirm this is Apache CouchDB version 1.6.0.

Attack Surface Assessment:

The CouchDB service is exposed externally via port 5984. This is the default port for the CouchDB HTTP API, allowing database interaction through a REST API.

Version CouchDB 1.6.0 is an old version, prior to the 1.7.1 patch. According to Apache documentation, CouchDB versions in this range are affected by:

• CVE-2017-12635: Remote Privilege Escalation due to inconsistent handling of duplicate JSON roles keys.
• CVE-2017-12636: Remote Code Execution since an admin user can modify server configurations via the HTTP API.

=> Thinking: From the obtained response, there is sufficient evidence to determine that the victim is running Apache CouchDB 1.6.0 on port 5984. This is an older version associated with the exploit chain of CVE-2017-12635 and CVE-2017-12636. Therefore, a logical exploit path is to first test the authentication state, and then evaluate the potential for privilege escalation or command execution via the CouchDB HTTP API.

II. Testing Authentication Status (CVE-2017-12635)

CVE-2017-12635 exploits the discrepancy between two JSON parsers in CouchDB. When sending a user document to /_users with two duplicate roles keys, CouchDB uses the second roles key to check the write privileges for the document, but uses the first roles key for the actual permissions of the user after creation. Thus, an attacker sets the first roles to ["_admin"] and the second roles to [] to bypass the validation check, resulting in the created user having administrator privileges.

Based on CouchDB Documentation, CouchDB stores user information in a special database named _users, where each user document has an ID formatted as org.couchdb.user:<username>. Since we need to create a user named hacker, the endpoint used is /_users/org.couchdb.user:hacker. I create a new user and assign them admin privileges to see how the server responds.

The returned response is true, proving that the user was created successfully. I perform a verification check using the newly created admin credentials: curl -u hacker:password123 http://192.168.3.137:5984/_users. The /_users endpoint is a system database, which by default only admins can read metadata from. If requested by a regular user → 403 Forbidden. The 200 OK response with full DB info confirms that the hacker account indeed has _admin privileges. This aligns perfectly with the CVE-2017-12635 hypothesis on Apache CouchDB 1.6.0.

Summary:

I have successfully verified CVE-2017-12635 on Apache CouchDB 1.6.0. Initially, port 5984 only showed that the CouchDB HTTP API was exposed. After fingerprinting via curl, the response confirmed the service is CouchDB 1.6.0, a version within the vulnerability range of CVE-2017-12635.

Instead of immediately concluding that RCE is possible, I verified the authentication flow step-by-step first. By sending a user document to /_users with two duplicate roles keys, the payload successfully created the user hacker. Following this, the request to /_users via curl -u hacker:password123 returned 200 OK along with system database details, proving the user hacker genuinely holds _admin privileges.

Consequently, once CouchDB admin privileges are acquired, the attack surface expands to CVE-2017-12636, as admins can alter the CouchDB configuration via the HTTP API. This serves as the prerequisite to further evaluate remote code execution capabilities on the server.

⇒ Thinking: Use the newly acquired admin privileges to test OS-level command execution.

III. From CouchDB Admin Privileges to Remote Code Execution (CVE-2017-12636)

According to the Apache CouchDB Documentation, a Query Server is an external process used by CouchDB to process design functions, such as a JavaScript view in the MapReduce mechanism. When a design document declares a "language" field, CouchDB relies on this value to look up the corresponding query server in the query_servers configuration.

If the design document contains "language": "javascript", CouchDB queries the query_servers.javascript configuration to determine which process to spawn to handle the map/reduce function. This is a legitimate CouchDB design, as the CouchDB core does not directly execute all view code within the database engine.

⇒ The issue in CVE-2017-12636 resides in the ability of a CouchDB administrator to modify the server configuration via the HTTP API. Some of these configurations include paths to operating system-level binaries or processes that CouchDB will launch. Therefore, after gaining admin privileges from CVE-2017-12635, an attacker can modify query_servers.<language> to point to an OS command. When triggering a view that uses the corresponding language, CouchDB will spawn the command, resulting in command execution on the server.

Exploitation Flow:

1. Acquire CouchDB admin privileges via CVE-2017-12635.
2. Write the malicious configuration to query_servers.cmd via the /_config endpoint.
3. Create a design document with "language": "cmd".
4. Trigger the view.
5. CouchDB looks up query_servers.cmd and spawns the configured process.
6. The OS command executes under the privileges of the CouchDB process.

Operational Mechanism

Writing Malicious query_server Configuration

Register a "query server" with an arbitrary name, with the value being the OS command:

This is the OS command that will be spawned by the CouchDB process.

Triggering Execution — Creating Database and Document

Execution Flow:

Verify RCE:

Thinking: This RCE attack is blind/asynchronous because the command output is not returned directly in the HTTP response. Therefore, to prove that the command was executed, I used a payload that generates a side effect by writing the output of the id command to the /tmp/pwned file. When reading the /tmp/pwned file in the container and observing the output uid=1000(couchdb) gid=999(couchdb), we can conclude that CouchDB successfully executed the OS command under the privileges of the couchdb user.

The result uid=1000(couchdb) shows that the command did not run with root privileges, but rather with the privileges of the CouchDB process. This remains sufficient to prove that CVE-2017-12636 leads to Remote Code Execution within the boundaries of the service permissions.

IV. RISK ASSESSMENT & RECOMMENDATIONS

Risk Assessment

The JSON Parser Inconsistency (CVE-2017-12635) vulnerability combined with Query Server Injection (CVE-2017-12636) on the system is assessed at the highest risk level:

Remediation Recommendations

To thoroughly mitigate these vulnerabilities, the system administration team must implement the following measures (ordered by priority):

Urgent Priority (Short-term):

1. Upgrade Apache CouchDB: Immediately update to a secure version (≥ 1.7.1 or ≥ 2.1.1, recommended version 3.x). This is a mandatory measure since the vulnerability lies in the core JSON parser engine (jiffy) and the query server configuration mechanism.
2. Enforce Mandatory Authentication: Configure require_valid_user = true in the local.ini configuration file to block all anonymous API access. Never run CouchDB in "Admin Party" mode (where no admin exists, making everyone an admin).

High Priority (Long-term & Defense-in-Depth):

1. Restrict Network Access to Port 5984: Configure a firewall (iptables/firewall) to only permit trusted IPs to access port 5984. This port should never be exposed to the public internet. If the application and CouchDB reside on the same machine, bind CouchDB strictly to 127.0.0.1.
2. Disable Configuration via HTTP API: Use config_whitelist in the local.ini file to restrict which configuration keys can be modified via the API, preventing attackers from leveraging the /_config/query_servers endpoint to inject OS commands.
3. Restrict Container Networking: Avoid placing the container on a shared default bridge network unless necessary. Configure firewall rules to block the container from actively initiating outbound connections (outbound traffic) to the internet to prevent Reverse Shell execution.