Exploiting MySQL arbitrary file read: a honeypot that kicks

Exploiting MySQL arbitrary file read: a honeypot that kicks

včera 18:42
| Přečteno: 4593×
| Misc.
| Výběrový blog
| poslední úprava: včera 18:42

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

/etc/shadow

, 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]

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

wp-config.php

, containing passwords and stuff. Only the command-line

mysql

client has this off by default and it must be enabled by the

--local-infile

option.

How can we exploit this? The first idea was to create a TRIGGER which will run the

LOAD DATA LOCAL

command. Unfortunately it turns out that

triggers cannot contain certain commands

– including

LOAD DATA

– and patching MySQL to allow this seemed too complicated.

The next approach is to sniff the communication between the server and the client performing

LOAD DATA LOCAL

using 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.

The trolls are now fed

, so what next? I have created a script that does the following:

  • 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.
  • 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.

Plugging the numbers into the

Drake equation

, I expected a huge success.

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

/etc/shadow

, about half of which can be cracked. To sum up, the honeypot managed to crack only a few remote systems.

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.

Summary

A mysql exploit created in two hours can generate ~4 rootshells per month.

Tiskni

Sdílej:
Linkuj
Jaggni to
Vybrali.sme.sk
Google
Del.icio.us
Facebook

Komentáře


Vložit další komentář

včera 19:01

Bherzet

| skóre: 8
| blog:

Bherzetův blog

Re: Exploiting MySQL arbitrary file read: a honeypot that kicks

včera 23:12

marbu

| skóre: 30
| blog:

hromada

| Brno

Re: Exploiting MySQL arbitrary file read: a honeypot that kicks


Založit nové vlákno

Nahoru

Read More

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.