Atomic Honeypot – A MySQL Honeypot That Fights Back

All right, let's begin. So this talk is about atomic honeypot that drops shells. So my name is Alex Alexander Rubin and uh I have been working with MySQL the database for long time. I think it's 20 years already or coming up to 20 years. So I started at MySQL EB the company behind MySQL and uh I was doing MySQL consulting architecture open source uh and then four and a half years ago I joined Amazon web services as a database engineer and I started working on MySQL and then I switched to security and we started doing MySQL security research and I created a new team that didn't exist exist before at AWS we call it red

team. So currently I'm a principal security engineer and uh also managing this research relational security red team. So this is our agenda for today. We will be building an atomic honeypot for MySQL that will strike back. So we start with creating a high interaction MySQL honeypot. Basically the idea is to attract those bad actors who are trying to connect your database server and see what they are up to and then we will be using this vector that we have found called MySQL server can attack you. This is usually people don't think about this vector. When people think about the security of MySQL, they think about server. But what if the server itself has been hacked? Now you connect to a

server that you think that you own, but now it's under control of this bad actor. Now the server can actually attack you in this case and we started with this vector and then we converted our high interaction myascale honeypot to atomic honeypot. So again what we wanted to do is we wanted to find out about the common attacks about MySQL server and we want to interact with the attackers and we wanted to download the the the code that they're using the evil code. So if you don't know bots are everywhere and they're scanning your database servers. Database servers are really under attack especially if they are running on a well-known port. So database servers are big target

servers are big target. So here our MySQL honeypot server. We start start the MySQL server and we connect it. We open it from the public internet. And the moment that you open your MySQL server or any database server from the public internet, you will start seeing connections. So people will will find those servers and will try to connect to it. Those are the bots. Those are the bots that trying to attack your server. And uh uh we are after that. So let's start with why do we need a high interaction MySQL honey? MySQL protocol is a little bit different. So MySQL protocol is server initiated. What it really means is that if you just start a TCP server on port let's say

3306 then the client will not be able to connect because there is no prompt. So here is the example of the prompt that MySQL server is giving you. So it will give you a server version. It will give you the the uh salt and it will give you the uh the plug-in name. We will actually be using all of that. So just listen on a port a TCP server is not enough. So what do we need to have to actually create a MySQL honeyot? So the good news is that there's a very simple to use Python library that implements MySQL protocol. So it's called MySQL mimic. So it's very easy to use and it supports it supports a lots

of things. It supports SSL, it supports the MySQL protocol packets and it give you a lots of control over what you can do. So we started with this and we started with a high interaction MySQL honeypot running on a well-known server and we start seeing people connecting bots connecting to us and MySQL have this connection parameters connection attributes similar to HTTP user agent. So basically you can see what client programs what which version they're using and there are this is what uh MySQL defines it defines client version operating system program and program name right platform and program name. So you you know unless people are really try to de decept you right uh you will

see what kind of client programs they're using this is the example of the of the ports that are being connected to us right we can see that they use some of them are using Windows some of them are using Linux there are lots of lots of interesting information here so from We from there we saw two major attacks on MySQL. The first one is attempts to own MySQL server, escape from the database and create a backdoor. It's actually using a very old method and uh it's unlikely that they succeed. They may succeed on some really old servers, but unlikely they succeed right now. And then the second attack is more interesting and probably a little bit

bit more recent. So this is a ransomware attack. those bots try to connect to your MySQL server uh try to brute force the password then downloads your data deletes your data and put a ransomware note note to you. So we are seeing this attack and we this is the attributes the connection attributes the fingerprints of this attack right this is what we're seeing what they're using uh and what is also interesting here they're using MySQL dump myskl dump is um backup program and the reason why we are seeing my skill dump because the whole idea of that attack is that to download your data to drop the data ask for ransom and basically saying if you

will pay us then we will give you data back. So from there we want to see what we can use to strike back and we will be using this MySQL server vector. MySQL server can attack you. Those bots are using client programs, client libraries. So we control the server. We want to see what we can do to basically download the code from there and interact with them. We have been looking at three CVS. The first one is MySQL client arbitrary file read that has been known for a long time. That's a very old attack. The second one is client remote code execution. Again, server will make the client execute your program. And the second one is another

example of remote code execution. Basically the first one we found in 2023. We presented it at uh HitB that year conference and the second one uh we found in 2024 and we presented it at Defcon uh last year. So this presentation is similar to the one that we gave at Defcon but it's it's a full version of that presentation. Let's start with a MySQL client arbitrary file read. This is basically what happens. Super simple. MySQL protocol has this load data local infile capability. Now en imagine if you connect to a server and you do your query whatever it is select one instead of this query my SQL server will send over give me an arbitrary

file and the client will give that file the content of that file back to the server. This is what it is. It's actually very old and has been fixed in all major versions. Now to use that is super simple. You can just download this Python program, run that on your port that will act as a server. Now you specify which file you want to read from the client. That's it. Now client connects and if the client is unfixed then the server will be able to read a file from the client. Here's the quick demo of how it works. So first I download this Python script. Then I run it and I specify I want to read etc password on port 336.

Then I use this MySQL version. It's old version where it's not fixed. Now I connect to my server and that's it. Password obtained. So now I read the password from the client on the server. Now here is how it will look like if the if the client program is patched. So let's see my SQL version 8 and then I will do the same thing. I will connect to my server and the server will initiate the file read but it will not succeed and if we will do just select one manually on that we'll see why so this is the error that it will give us uh if my SQL client doesn't allow this load data in

file. So in this case this is that was fixed and that's why our attack was not successful. The second one is even more interesting. The second one is remote code execution on the client when the client connect to a rogue server. To really understand how it works, we need to first understand the MySQL protocol. So here's how MySQL protocol works. We have MySQL client and MySQL server. And MySQL client connect to the server and say hello MySQL server authentication please. And I have a username and password. And by the way, I will use MySQL native plugin. So MySQL has this ability to implement uh any plugins. It's a pluggable authentication. So with a pluggable authentication, MySQL client can

actually request which plug-in it will use. In this case, it will request MySQL native password plugin. And the server will say, okay, very good. I loaded this plugin and I checked your username and password access granted. Now I have another situation. So the client will say hello my SQL server authentication please and I will use whatever plugin and the server will say no I don't have any idea of what this plugin is let's try try another plugin and the client will actually agree and the client will will say okay I'll try to load another plugin if I have that So basically the server can change the authentication plugin on the client. So then let's look at the code.

MySQL opensource. You can take a look at the code of the client library. It's actually part of the same server repository on GitHub, but it's a it's a client library uh code. And then you can see this. So if you're wondering what loading the plugin is, it's deal open. So here the plug-in name comes from the server. But it also only lo uh only load in the plugins from the plug-in deer. This is a dedicated directory for the plugins and that directory cannot be changed on the server. But what if we will use directory traversal? So if we will use a directory traversal, we can tell the client the to load the arbitrary shared library, right? We can load that file

from any directory. And also there is another issue that will allow me to create a long string here so that it will be able to load an really arbitrary file without this um extension. So this is arbitrary code execution via directory traversal. So again how does it work? First of all, the bad actor will need to upload a shared library file. It can be any location, any file name. And then when MySQL client connects to the server, the server will push the plug-in name and then the client will load that. So here's the quick demo of what we uh did in this particular scenario. My colleague Martin sent me a resume, a PDF file. And when someone sends

you a resume, what would you do? Well, you probably save it at least. You don't need to open it. You don't need to trigger any code from it. You just save it somewhere like documents on Mac. And then this is not a PDF file. It's actually a a binary, a shared library generated from that code here. So that code creates a file on disk and also opens a calculator. This is a demonstration of uh uh the arbitrary code execution. So now let's see how it works. Uh so we our goal is to open a calculator as a demonstration and then this is the file on disk. That's the only thing I need. Now I start my rogue

server here. And in this scenario, I'm trying to connect to my server, but it's really it is hacked and now it's under the control of the bad actor. So now I use MySQL workbench. MySQL workbench will try to connect to my hack database. This is really old version 8008. Don't use that. Now I am connecting to this my hack database. I have the my plug-in directory configured here and I just need to establish the connection nothing else and that's it calculator right so basically we demonstrated that a bad actor can replace your MySQL server with this Python script and get an arbitrary code execution remote code execution on on any client that connects to that

server. So the third one is also interesting and it's really an uh unusual vector. This we discovered in 2024 and uh released to Oracle MySQL. So they fixed that. So this CV is in MySQL dump program. That's a backup program. And what MySQL dump is doing is it connects to your server and generate a set of statements, SQL statements. It will produce a text file. Do you think that text file can contain an exploit? And actually it is the thing is MySQL documentation suggests this. Basically, you if you want to copy one server to another server to set up a replication or something, then you pretty much connect your MySQL dump program to your server one and then pipe

to MySQL common line program which will actually reexecute the statements on the server 2. Now the thing is MySQL command line client have this ability to execute shell commands and because it can execute the shell commands your your rogue server can actually push anything to the client. So what if we what if we'll push something? MySQL actually do a good job escaping those. You detect you you basically expect a string from the server and if it's a string you do enclose in something. But then there's one exception. We found this code where MySQL client library MySQL dump in this case checks the version of the server and don't escape it. It doesn't treat it as a string. It treat it as like as

is. So if you will replace you if you will create a rogue server out of that and then we can push the end of end of line and our command then we have a command execution. So this is a single line patch to MySQL server any version of the server doesn't matter and then we can do a touch and create a new file we can do anything else. So this is how it will work. If we start this server and then we do a TNET to connect to that port, this is what we see. MySQL server sends the version name to the client and now it sends the end of line and our command. Now if you pipe

that to MySQL common line client, then you will have a command execution. So here's how it will look with the MySQL dump output. And uh if you pipe it through MySQL command line then we have command execution. Starting with that we have created our atomic version of high interaction MySQL honeypot and we added two options here. The first option is to implement this CVE 2024 MySQL dump command injection and the second one is the rogue MySQL plug-in that we presented in 2023. And then here is our atomic honeypot and our goal is to get the evil source code. Before we'll go there, I wanted to do one quick demo of how this CV 2024 will work. And this demo is on

Windows. And we will use the MySQL dump program and we'll connect to our honeypot to get the remote command execution. So here's what we'll use. will use this payload visual basic on Windows. Uh basically create a window. This is our honeyot. Our honeyot will have this version string payload and this payload will basically will get that payload from the HTTP server. So we start HTTP server as well. Now this is our old version of MySQL dump before the fix. We run this MySQL dump connect to server and that's it. So because MySQL dump have this uh issue it MySQL dump uh pipe MySQL will have this issue. It will execute the arbitrary command. Now with this

honeypot, we are finally going to explore our bad actors. So we started with attack number one. We started looking at the fingerprints that we have and we realized that this is Windows. The client version is really really old. How? So we have some chance here. But we don't see MySQL dump. So the attack number three will not be will not be feasible here. So we can probably read arbitrary file. We don't know if we can do a remote code execution via plug-in. And there's no MySQL dump. So let's start with uh arbitrary file read. So our first interest were what version of Windows they using and there are multiple files that you can download from Windows. You can download Windows

update uh basically to see what version it is and we quickly realized this is Windows Server 2003 or Windows XP which is really really old. that explains why they're using that version of uh MySQL client. So now with that, our next goal would would be to try an remote code execution. So for the remote code execution, we need to have a DLL. And this is our DL with a payload. Again nothing fancy. Uh just message box. So we have been thinking how do we push the DL file to the attacker server in our previous example right it was a resume but here we don't know how to push but first of all we have started

looking at the queries that those bad actors are sending to the server and we quickly realize this is what they're doing. This is the part of the attack. They're trying to basically uh down they they try to upload their uh their payload and they're using that using FTP server and they have a FTP server somewhere on their infrastructure. So we were thinking maybe we can just push it. We have the FTP server running. It's on the same host. It's uh we know the username and password and maybe we can upload it to the public. So we have created this simulation and in this simulation we are uploading a uh DL to a public location to any FTP server. Then we will run

atomic honeypot to trigger the DL and then we'll get shell. So here's how our attack may have looked like. We decided not to do that uh in uh real world but this is our simulation. Uh let's start it. So basically let's imagine that we have a FTP server running and uh we have this demo and demo and then we will do put into that FTP server into public location. We put an evil DLL our payload. Now what we will do is we will use this plug use this shell uh honeypot and start our honeyot and uh then we will basically adapt that honey to load our plug-in load our DLO and we will specify the path

because we have under assumption that we uploaded it to the public uh directory and then we specify that public directory and we're trying to to launch that from the public directory. Right? So now we start listening on our port. This is our our payload the DDL. We compile that DDL and now we log in. We have our MySQL command line client for the simulation. In reality, it would have been their program. We connect using that MySQL comet line program and that's it. you have been pawned. So this is the how this attack could have been executed on those um uh those bad guys. So to recap the example number one arbitrary file read was successful RC via plug-in

was done via simulation. Attack number two is more interesting. I would say much more interesting. We started with the same thing. We captured the fingerprints and we see here two things. We see a normal MySQL client lib Mariab. Mariab is pretty much the fork of MySQL. Uh and uh we also see here MySQL dump. Now those are the recent versions of the client libraries. So we cannot do arbitrary file read. We cannot do rce via plug-in. But this is our chance to actually try out the latest version of CVE on MySQL dump. Now we started by analyzing what they are doing. We control the server. That means that we see all of those queries that they

run. So we can see what they're doing. They are listing the databases, listing the tables, and then for every database and for every table they find, they run MySQL dump. Now notice here limit 10. What they are doing is they are only only grabbing 10 records from your tables. So they are pretending to actually downloading your database. They are not doing that for real. And if you think about that, that's logical for for those uh bad guys not to download your database because if you if you start downloading terabytes of data, how do you store it? How do you deal with that? So instead, they're just pretending because if you if they will send you a

note, a ransomware note, give me whatever number of bitcoins and I will give you the data back. You may ask, prove to me that you have my data and they will give you 10 records on every table. So that's why what they're doing this, right? But they are running my skill dump. They're running my skill dump with a limit 10. And then we were thinking can we download the code with an arbitrary file rate? No. Can we execute the plug-in code with a plug-in? But then we start thinking is how this attack designed anyway. So we come up with this diagram potential diagram of how this could have been done. There should be some application running

somewhere and from that application they have to execute my skill dump. So there's a if there's a CLI it's a CLI on Linux. So they will uh we we know that this is Linux right. So we know that they are they're doing some execution and then last thing is we seeing again the connection from the application again. So connection from the application MySQL dump suddenly and then connection from the application again. So probably exactly. And then we started experimenting with the table names and the database names. And we see that whatever table name we present on a server will come back to us as a part of that MySQL dump program. So we're thinking is if we control the

database name, if we control the table name, maybe it's a command injection. And really it was a command injection. So basically if you create this schema name and put a command a Linux command here, super simple, then you will get the result back. So this is how we can see we can actually see the process list on their server. You do psax base 64 and then this is a table name will be sent over back to us as a part of the MySQL dump command and this is how we can see this. So it's actually worked. I was surprised but this is how it worked. So we can actually see this. We can see their process list. We can

see their code and we downloaded this evil code. Uh this is what they're doing. They are using a mass scan to scan the to find MySQL and also MongoDB servers on known ports. And then they are doing a brute force password brute forcing to connect and with a known passwords they connect to your server and then run this MySQL dump command. So this is all written in Python. There are multiple command injections there. Command injection every everywhere. So probably those guys have never did a security review of their code. So this is uh basically it. We were able to download we were able to use the MySQL dump uh CV to download their code. So if you want to try it at

home, you can also do that. You don't even need the um MySQL honeyot. You can start a normal burner MySQL database server and then you can create your database names like this. You can do a semicolon and command. You can also do this dollar sign in command. This is bash. It's bash right on Linux. So this is uh either of those probably work since the defcon presentation. I never touched that. I don't know if this has been fixed or not, but the the MySQL dump uh CV was was actually fixed. So this is the summary and conclusion. We have found a new CVE in MySQL dump client utility. This is an unusual attack vector. You are attacking a client from the

server and in this case a client is MySQL dump a backup program and what will happen in this case the payload the evil code is a part of the text file a part of your MySQL dump backups. uh atomic honeypot can attack and stop the attackers potentially and the tool will be released soon. That's it. Thank you very much. [Applause]