×

MySQL arbitrary file read: a honeypot that kicks back

4.3.2019 18:42 | Přečteno: 19190× | Misc. | | poslední úprava: 20.11.2019 13:59

/etc/shadow

A little-known enabled-by-default feature allows MySQL server to request arbitrary file from the client. I have created a MySQL honeypot that steals, cracks the hashes and sshs back to the attacking machine.

MySQL/MariaDB has a peculiar feature where the client can send a file (presumably in CSV format) and the server will parse it and create a table from it. I'm not convinced this should be a server-side feature, but whatever. On the wire, it looks like this:

Client: LOAD DATA LOCAL INFILE 'foo.csv' INTO TABLE t; Server: Send me foo.csv then. Client: Okay, here it is: [file contents]

What could possibly go wrong.

Client: LOAD DATA LOCAL INFILE 'foo.csv' INTO TABLE t; Server: Send me /etc/passwd then. Client: Okay, here it is: [file contents]

wp-config.php

mysql

--local-infile

And it even works when the server says "Send me /etc/passwd" out of the blue! That's probably because the LOAD DATA SQL command can be computed while the query is being executed, so it isn't known in advance if a file (and which one) will be requested. So the result is that the MySQL server can request arbitrary files from the client. There is an option where this feature can be turned off, but unsurprisingly pretty nobody does it and libraries for most languages (e.g. Python and PHP) have this on by default. There has been for example a security bug in Adminer over this, where strangers requested, containing passwords and stuff. Only the command-lineclient has this off by default and it must be enabled by theoption.

LOAD DATA LOCAL

LOAD DATA

How can we exploit this? The first idea was to create a TRIGGER which will run thecommand. Unfortunately it turns out that triggers cannot contain certain commands - including- and patching MySQL to allow this seemed too complicated.

LOAD DATA LOCAL

The next approach is to sniff the communication between the server and the client performingusing Wireshark and then simply replay it to the victim. The framing/stream format has been immediately obvious even without consulting any documentation/sources - the first three(?) bytes are message length, then the message comes, and we don't need anything more to implement the attack. A simple PoC is here

Btw. someone has already implemented it but it didn't work for me. And claims were made that "modified version of the rogue MySQL server is for sale on the dark web" - okay, so here is my Python script.

Listen on a public IP on port 3306.

Once a client connects, accept any username and password. (the idea here is to attract botnets that are bruteforcing mysql credentials)

Ask the client for /etc/shadow . This can of course fail if the client does not have sufficient permissions, is not running on UNIX, has the file inclusion feature turned off or is running old version of mysql client, which is not compatible with my hacky exploit.

. This can of course fail if the client does not have sufficient permissions, is not running on UNIX, has the file inclusion feature turned off or is running old version of mysql client, which is not compatible with my hacky exploit. Check that sshd is running on the client on port 22.

Crack the shadow file using hashcat and Probable Wordlists. This will of course work only if the password is weak. However, this offline guessing is several orders of magnitude faster than online attack, and also we know the username in case the root login is disabled.

Use the obtained credentials to login back into the box.

The trolls are now fed , so what next? I have created a script that does the following:Plugging the numbers into the Drake equation , I expected a huge success.

/etc/shadow

Unfortunately, Drake equation leads to Fermi paradox (btw. here and here are a cool presentation and a paper about this). I get only about 5 login attempts per day, probably mysql isn't very attractive for bruteforcers, of which only 5 % are willing to share, about half of which can be cracked. To sum up, the honeypot managed to crack only a few remote systems.

Summary

Hodnocení: 94 % špatné • dobré

Komentáře

Okay, so what to do with this when I don't want to do any harm? I have contacted abuse@ for the given addresses, but unsurprisingly received no reply.A mysql exploit created in two hours can generate ~4 rootshells per month.

Vložit další komentář

4.3.2019 19:01

Re: Exploiting MySQL arbitrary file read: a honeypot that kicks 4.3.2019 19:01 Bherzet | skóre: 17 | blog: Bherzetův blog Re: Exploiting MySQL arbitrary file read: a honeypot that kicks

4.3.2019 23:04

Re: Exploiting MySQL arbitrary file read: a honeypot that kicks 4.3.2019 23:04 Bystroushaak | skóre: 36 | blog: Bystroushaakův blog | PrahaRe: Exploiting MySQL arbitrary file read: a honeypot that kicks

4.3.2019 23:12

Re: Exploiting MySQL arbitrary file read: a honeypot that kicks 4.3.2019 23:12 marbu | skóre: 30 | blog: hromada | BrnoRe: Exploiting MySQL arbitrary file read: a honeypot that kicks

5.3.2019 02:19

Re: Exploiting MySQL arbitrary file read: a honeypot that kicks 5.3.2019 02:19 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberecRe: Exploiting MySQL arbitrary file read: a honeypot that kicks

5.3.2019 14:30

Re: Exploiting MySQL arbitrary file read: a honeypot that kicks 5.3.2019 14:30 kralyk z abclinuxu | skóre: 29 | blog: Re: Exploiting MySQL arbitrary file read: a honeypot that kicks

5.3.2019 14:53 sad

Re: Exploiting MySQL arbitrary file read: a honeypot that kicks 5.3.2019 14:53 sadRe: Exploiting MySQL arbitrary file read: a honeypot that kicks

6.3.2019 01:28

Re: Exploiting MySQL arbitrary file read: a honeypot that kicks 6.3.2019 01:28 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberecRe: Exploiting MySQL arbitrary file read: a honeypot that kicks

Založit nové vlákno • Nahoru