How to Turn a MySQL Honeypot into a Remote Code Execution Engine

TLDR: This research demonstrates how to weaponize the MySQL protocol against clients by turning a standard honeypot into an RCE delivery mechanism. By exploiting CVE-2023-21980 and CVE-2024-21096, attackers can force client machines to read arbitrary files or execute shell commands during a standard database connection. Security teams must audit their database client versions and restrict LOAD DATA LOCAL INFILE capabilities to prevent these client-side attacks.

Most security professionals treat the database as the target. We spend our time looking for SQL injection, broken authentication, or misconfigured permissions on the server side. We rarely consider that the database server itself might be the one pulling the trigger on the client. This research flips the traditional threat model on its head, showing that a compromised or malicious MySQL server can easily achieve remote code execution on any client that connects to it.

The Protocol is the Vulnerability

The MySQL protocol is inherently server-initiated. When a client connects, the server dictates the flow of the conversation. This design choice is a goldmine for anyone running a high-interaction honeypot. By using mysql-mimic, a Python library that implements the MySQL protocol, you can build a honeypot that doesn't just log connection attempts but actively interacts with the attacker.

The real danger lies in the client-side handling of server responses. If a client is running an unpatched version of the MySQL client or a tool like mysqldump, it blindly trusts the server's instructions. This trust is exactly what allows for the exploitation of CVE-2023-21980. When a client attempts to connect, the server can request a file read via the LOAD DATA LOCAL INFILE command. If the client is not configured to block this, it will happily send the contents of any file on its local disk back to the server.

Weaponizing the Client

The research goes beyond simple file exfiltration. By leveraging CVE-2024-21096, an attacker can achieve full remote code execution. This vulnerability exists because mysqldump fails to properly sanitize the server version string and other metadata returned by the server.

During a standard backup operation, mysqldump connects to the server and executes a series of queries. If the server is malicious, it can inject shell commands into the metadata fields that mysqldump processes. Because mysqldump often runs with the privileges of the user performing the backup, this command injection runs with those same privileges.

The attack flow is deceptively simple:

1. The attacker hosts a malicious shared library (DLL or .so) on an FTP server.
2. The attacker configures the honeypot to return a version string containing a directory traversal payload.
3. The client, attempting to connect to the "database," is forced to load the malicious library from the attacker-controlled location using the LoadLibrary function.

# Example of a malicious payload string injected via the server version
5.7.43
\\ touch /tmp/pwn

This technique effectively turns a routine database backup into a vehicle for arbitrary code execution. For a pentester, this is a critical finding. If you are performing an internal assessment, you don't need to find a web application vulnerability to get a shell. You only need to find a developer or a CI/CD pipeline that connects to a database you control.

Real-World Impact and Testing

During engagement scenarios, this vulnerability is most potent when targeting automated systems. Think about how many Jenkins jobs or Kubernetes cron jobs run mysqldump to back up production data. These systems are often configured with broad network access and run with elevated permissions. If an attacker can perform a man-in-the-middle attack or compromise a single database node, they can pivot to the client machine, escalate privileges, and move laterally through the network.

When testing for this, you should check if your target environment allows LOAD DATA LOCAL INFILE. You can test this by attempting to read /etc/passwd or C:\Windows\win.ini from a client machine using a rogue MySQL server. If the client returns the file content, you have confirmed the vulnerability.

Defensive Measures

Defending against this requires a shift in how we manage database clients. First, ensure that all MySQL clients and mysqldump utilities are updated to the latest versions, as vendors have patched these specific RCE vectors. Second, disable LOAD DATA LOCAL INFILE globally in your client configurations. This is a legacy feature that is rarely needed in modern production environments and is a primary vector for client-side file theft.

Finally, treat database connections as untrusted network traffic. If you are running automated backup scripts, ensure they run in isolated containers with minimal filesystem access. Do not assume that the database server is a benign entity. If the server is compromised, it can and will attack the clients that connect to it.

This research serves as a stark reminder that the security of a system is only as strong as the weakest link in the communication chain. In this case, the link is the implicit trust the client places in the server's protocol responses. Stop trusting the server, update your binaries, and start auditing your client-side configurations before an attacker does it for you.