PoC - A Cryptominer in the Couch

Bubble or not, the Bitcoin speculation have made us hear controversial statements from 'distinguished and fancy' people which assert that it will worth a million ---> John McAfee: $1mn by 2020 or I'll eat my D. As one of its consequences, attacks abusing server vulnerabilities for cryptomining are growing with the crypto currencies popularity as well.

While taking my daily morning Twitter dose, I found a Trend Micro blog mentioning a couple of security issues of a NoSQL service which have been exploited by some "wannabe but not on my pc" Monero miners. The targeted service was the 'relaxing' Apache CouchDB.


CouchDB is an open source database software developed on Erlang which focuses on ease of use by using a NoSQL architecture and JSON  objects to store data. Deployed by default on port 5984, the service allows their users to manage all the databases using Javascript as query language and HTTP as API, providing everything you need to be relaxed, even if your server is being hacked *cough*.

The two vulnerabilities which have been exploited are:
The first one permits an attacker to create an admin user on the database remotely by sending a crafted JSON message. After being created, the user will have the maximum privileges on the database. I've developed a simple python PoC for Exploit-DB which can be found here.


After finding a vulnerable server, it's possible to execute the python exploit which creates an administrative user at the database. Here you can find the exploit options to achieve the vulnerability exploitation.


Finding a Vulnerable Server

By taking a look at SHODAN with the query: port:5984 CouchDB/2.0.0 we can find some vulnerable servers which has the Apache CouchDB deployed on its default port, some of those already tagged by SHODAN as compromised >:)

Despite of the easy-finding of many vulnerable servers and the strong temptation of document this PoC using one of those, I'll be ethical (as always...) and use a local vulnerable machine to demonstrate how this works.

I deployed a preconfigured vulnerable database which has an administrative user created, that means it cannot be accesed or modified without having the admin credentials.


The database also has deployed the Fauxton administrative tool which can be accesed through a browser at the /_utils directory. After trying to login with the exploiter:123456 credentials, a login error is sent back from the service.


Exploiting the Couch

Now, by using the Exploit-DB python script against the server, we can create the admin user at the database. 


After being created, I could successfully login as the exploiter user with ultra secure password 123456. Easy peasy:


How it works?

CouchDB manages user accounts through a special database called _users. When a user is created or modified, the server verifies the intended modification with a Javascript validate_doc_update function to ensure that is a secure and valid change.

However, there is an issue between the Javascript JSON parser and jiffy, a parser used internally by CouchDB. This issue is exploitable when sending duplicate keys against the server.

 Duplicate keys:

 {"test":"test1", "test":"test2"}

 Erlang (jiffy parse):

{[{<<"test">>,<<"test1">>},{<<"test">>,<<"test2">>}]}

 Javascript (JSON parse):

 {test: "test2"}

For a given key, jiffy will store both values, but the JSON parser will save only the last one. This can be  applied to an user object, for creating an admin user, like:

 curl -X PUT 'http://localhost:5984/_users/org.couchdb.user:exploiter'
-d '{
  "type": "user",
  "name": "exploiter",
  "roles": ["_admin"],
  "roles": [],
  "password": "123456"
}'

 This works because for Erlang parser (jiffy) we are admin already, but for the JSON parser we have no privileges, so the crafted message passes and updates the database with the desired data like showed above at the duplicated keys example. For authentication and authorization, the Erlang module is in charge for most of their logical processes, which gives free rain to exploit this security breach.

 Relax.


¬#r4wd3r'

Comentarios

Publicar un comentario

Entradas populares de este blog

RID Hijacking: Maintaining access on Windows machines

Imagen
The art of persistence is ( and will be... ) a matter of concern when successfully exploitation is achieved. Sometimes is pretty tricky to maintain access on certain environments, specially when it is not possible to execute common vectors like creating or adding users to privileged groups, dumping credentials or hashes, deploying a persistent <bind/reverse> shell, or anything that could trigger an alert on the victim. This statement ratifies why it's necessary to use discrete and stealthy techniques to keep an open door right after obtaining a high privilege access on the target. What could be more convenient that only use OS resources in order to persist an access? This is the new post-exploitation technique which I have named RID Hijacking . The RID Hijacking Attack By using only OS resources, it is possible to hijack the RID of any existing account on the victim (even the 500 Administrator Built-in Account ), and assign it to another user account. This attack wil...
Leer más

Extracting NTDS Users Data... The Fastest Way.

Extracting what? One of the most tedious and long tasks a pentester has to do when assessing a company's domain, is the extraction of the NTDS.dit file, located ( usually ) in the Domain Controllers of the Active Directory . Retrieving the  hashes of all users from the  Active Directory is the first thing that a hacker ( well... I think ) should do after obtaining Domain Admin  privileges. Obtaining the  LM/NTLM hashes is crucial; it gives a huge list of possibilities to maintain access after an effective exploitation ( i.e. Golden Ticket, password cracking, pass-the hash, etc.) , and looks beautiful when is documented in a pentesting report ;) Common ways to dump hashes There are at least 3 well known ways of extracting the LM/NTLM hashes from Active Directory . Extracting the  NTDS.dit   file from a shadow copy using vssadmin , dumping the tables datatable and link_table with  esedbexport of esedebtools framework , and retrie...
Leer más

Off-by-one overflow explained

Imagen
One of the most common vulnerability that could be found in the wild is the buffer overflow . Either found as a stack overflow or heap overflow , it could allow not only reading but overwriting memory addresses which shouldn't be accessible from the standard program execution flow. By doing a code revision, or maybe some reversing over a binary or executable, it is possible to find this kind of vulnerabilities which impact the integrity, confidentiality and availability of the information when exploited by an attacker. Off by one in x86 This vulnerability occurs when a buffer operation is executed once more than it should. Let's look the next vulnerable c code: This program takes the string entered as argument when executing the program (i.e. ./program argument ), and copies it to the buf  variable, which size is 128 bytes. Nevertheless, there is a terrible mistake in the  for loop definition, but why? The buf array length is defined as 128, it is a char array...
Leer más