CouchDB, Erlang and cookies – RCE on default settings

In this short article, I want to share how to get RCE on a system with CouchDB installed on most installations on a local network or external network that are not behind a firewall. For reference, in Shodan there were about one and a half thousand of them.

TLDR: At the end of the article there are links and methods of operation.

Intro

CouchDB is an open source document-oriented database management system that does not require a description of the data schema, is distributed freely, written in Erlang (Wiki).

CouchDB instances in EPMD's answer on shodan.io
CouchDB instances in EPMD’s answer on shodan.io

I met her by chance, during the preparation of a security product of a South Korean company (spoiler – I found a lot of interesting things, I’m preparing an article). At first I thought that the developers did not know the software from which they assembled their “product” to protect other companies from cybersecurity threats, but it turned out that this is a massive problem.

Like any program written in Erlang, CouchDB has built-in support for distributed computing (clustering). The cluster nodes communicate using the protocol Erlang/OTP Distribution Protocolwhich provides for the possibility of executing OS commands through a module request OS:

Of course, to connect you need to know the secret phrase – “cookie” in Erlang / OTP terminology. This phrase is stored either in the .erlang.cookie file or in vm.args in the directory with the program. In the case of CouchDB, this is the file /opt/couchdb/etc/vm.args

The CouchDB installer leaves the default cookie value even when installed in Standalone – “monster” mode.

It would seem that it’s okay, take it and change this “password” by default, but the problem is that the administrator may not be aware of this functionality. After all, the information that you need to change the cookie is only in the manual on the site in the section with cluster settings:

And these are not my conjectures – out of one and a half thousand hosts on shodan.io when randomly checking, I did not stumble upon CouchDB, whose administrator saw this warning. Moreover, the creators of the security product I wrote about above are also among them.

In other words, if you stumble upon a CouchDB host on your own or a customer’s network, it is likely to be vulnerable.

Detection

In order to connect to an Erlang host, you need to know the node’s dynamic port. Erlang Port Mapper Daemon is responsible for its detection. You can ask him for information about the nodes in several ways.

By sending three bytes directly to the tcp/4369 daemon port:

echo -n -e "\x00\x01\x6e" | nc -vn <IP> 4369

Or using the nmap scanner:

nmap -sV -Pn -n -T4 -p 4369 --script epmd-info <IP>

Exploitation

To connect to a node, you need access to the EPMD TCP port (tcp/4369) and to the port of the node itself, which is usually chosen at random.

There are several ways to operate:

Based on the script code 1F98DI added an automatic request for information from EPMD:

By the way, use the standard Erlang emulator erl to connect to CouchDB will not work, because you need to specify the node name in the format name@host.fqdnand it is by default couchdb@127.0.0.1. Probably the developers of CouchDB considered this a reliable way to protect.

Correction

Fixing this problem is quite simple, you need to replace the default cookie with something else in the file /opt/couchdb/etc/vm.args

This one-liner, run as root, will do the job:

COOKIE=$(tr -dc 'a-zA-Z0-9' < /dev/urandom | head -c32);\ 
sed -i "s/-setcookie\ monster/-setcookie\ ${COOKIE}/g"\
/opt/couchdb/etc/vm.args

Then you need to restart the CouchDB daemon.

Outcome

I hope this article will be useful and help someone improve the security of their systems, and someone to take another flag.

The CouchDB security team promised to fix the installer in future releases, not caring much about current installations.

Additional links for information on the topic:

Similar Posts

Leave a Reply Cancel reply