Deep Dive and Simulation of a MariaDB RCE Attack: CVE-2021-27928

In early 2021, a new vulnerability, identified as CVE-2021-27928, was discovered and published. It affects multiple versions of the open-source relational database management systems (RDMBS) MariaDB and Percona Server, and the wsrep (write set replication) plugin for MySQL. Fortunately, security professionals swiftly released a patch to ensure that affected systems could be updated to mitigate risks.

Vulnerability Details

CVE-2021-27928 essentially is a remote code execution (RCE) vulnerability. It has a CVSSv3 and CVSSv2 scores of 7.2 and 9.0, respectively, which classifies this vulnerability as High. Moreover, this vulnerability is categorized under CWE-94, which is Improper Control of Generation of Code. This emphasizes that the issue arises from the database's failure to properly sanitize inputs and control the execution of code from untrusted sources.

This vulnerability affects some versions of MariaDB, Percona, and MySQL. MariaDB is a well-known RDBMS that is generally used in a variety of applications because of its robustness and flexibility. The Percona Server is a variant of MySQL that is described as a fully compatible, enhanced, and open-source drop-in replacement for any MySQL database that integrates many of MariaDB's features and is known for its performance and reliability. The wsrep is implemented as a plugin to be a replication API in conjunction with the Galera Cluster library used for adding synchronous multimaster replication capabilities to MySQL and MariaDB. The versions affected by CVE-2021-27928 include:

• MariaDB: Versions before 10.2.37, 10.3.28, 10.4.18, and 10.5.9
• Percona Server: Versions through March 3, 2021
• wsrep patch for MySQL: Versions through March 3, 2021

The crux of CVE-2021-27928 lies in how MariaDB, Percona, or MySQL handles the wsrep_provider and wsrep_notify_cmd configuration options. These parameters are components of the Galera Cluster integration, a well-known clustering solution used for synchronous replication among various database nodes. Essentially, the Galera Cluster is deployed mainly in environments where it is imperative to preserve high availability and scalability of clusters.

The `wsrep_provider` parameter defines the location of the Galera library that will be used for synchronous replication, and it is commonly set to the absolute path of the 'libgalera_smm.so' file. On the other hand, the `wsrep_notify_cmd` parameter determines the script or command that will be executed whenever there is a modification in the node’s state. Examples of state changes include joining or leaving a cluster. Therefore, the injection of malicious paths or commands into these system variables can facilitate attacks directed toward the database to enable the loading and execution of arbitrary libraries (e.g., an implanted *.so payload file). Basically, this vulnerability is set off by an untrusted search path that can be exploited to perform eval injections. An attacker that has obtained the necessary privileges can manipulate the wsrep_provider and wsrep_notify_cmd parameters, which consequentially enables them to execute arbitrary commands on the host operating system.

Exploit Demo via Docker

Docker can be used to test out and have first-hand experience exploiting this vulnerability. The goal is to pull a vulnerable version of MariaDB and go through the exploitation process to eventually obtain reverse shell access.

Docker is used in cybersecurity to test vulnerabilities by creating isolated, reproducible environments. It allows security professionals to simulate attacks, run exploits, and analyze responses without affecting the host system. Docker's containerization ensures consistent testing conditions, making identifying, assessing, and mitigating security flaws easier.

In this example, as shown in Figure 1, the Docker image 'mariadb:10.5.8' was pulled as it falls between the vulnerable MariaDB version range of 10.5.0 before 10.5.9. In this particular case, the Docker image was pulled from the official MariaDB registry to ensure reliability.

Figure 1. A vulnerable version of a MariaDB Docker image is pulled.

Figure 2. The 'docker images' command is executed to confirm pulled images.

The 'docker run' command is then executed on this pulled Docker image to enable the MariaDB instance to start. As shown in Figure 3, the flags include '-it' and '-e'.

The '-it' flag is the combination of two flags which are '-i' and '-t', respectively. The '-i' flag enables users to interact with the container's processes, while the '-t' flag makes the container's output more readable and allows for features like command-line editing and history. When combined, it provides an interactive shell session where users can run commands as if they were directly logged into the container.

The '-e' flag allows the passing of environment variables to the container using the command line. It can be used to specify configuration values, secrets, or any other necessary environment variables that the application inside the container might need. In this particular case, a single environment variable named 'MYSQL_ROOT_PASSWORD' was used to setup the root password of the MariaDB database server.

Figure 3. The 'docker run' command is executed with the MYSQL_ROOT_PASSWORD environment variable configured.

Figure 4. The 'docker ps' command is executed to confirm running images.

Before going further with the running MariaDB Docker instance, a payload to be executed on the target machine to obtain the reverse shell must be created. The tool 'msfvenom' is a versatile command-line tool in the Metasploit Framework used to generate and encode various payloads for exploits, facilitating penetration testing and security assessments. It was used to create the reverse shell payload in the form of a '.so' library, with local IP address (LHOST) and the intended local port (LPORT) to receive the reverse shell call as parameters.

Figure 5. Using 'msfvenom' to create a reverse shell payload file

Figure 6. The payload file 'CVE-2021-27928.so' has been created.

The created payload 'CVE-2021-27928.so' file is then transferred to the target machine via the 'docker cp' command. The first parameter of the command line is the local absolute path of the intended file to be transferred, while the second parameter is the absolute path of the target machine to which the file will be transferred.

Figure 7. The 'docker cp' command is executed to transfer the payload file to the vulnerable MariaDB target machine.

The running MariaDB Docker instance is then accessed by executing a 'docker exec' command with the MySQL command that enables MySQL root access. Once the appropriate password is entered on the prompt, access to the MariaDB command-line interface (CLI) has been obtained.

Figure 8. The 'docker exec' command is executed with the 'mysql' command to access the MariaDB CLI.

Before running the payload, a reverse shell listener on port 4444 is executed using Netcat, a networking utility tool, to receive the reverse shell call when the payload is eventually executed on the target machine.

Figure 9. Netcat listener on port 4444

Finally, the vulnerability is exploited by setting the global variable 'wsrep_provider' to the value of the absolute path of the payload. Setting this configuration will consequentially execute the planted '*.so' payload file which triggering the Netcat listener to accept reverse shell call.

Figure 10. Activating reverse shell payload on the target machine

This exploitation has opened RCE capability for attackers equipped with a MariaDB CLI. It was a lateral move as the reverse shell was not obtained with a root user account. If it were, the potential impact of the damage to the target host would have been devastating.

Figure 11. The Netcat listener is activated to spawn a reverse shell.

Privilege Escalation with CVE-2021-27928

In some cases, this vulnerability could lead to more devastating forms of attacks, such as privilege escalation. The HackTheBox platform has demonstrated such an attack on a vulnerable Capture-The-Flag machine called Shibboleth.

In the demonstration shown in Figure 12, the enumeration and process to acquire the initial foothold has been skipped to focus on the CVE-2021-27928 exploitation to obtain root access to the host. Access to a non-root (e.g. 'ipmi-svc') reverse shell and MariaDB CLI has already been obtained.

Figure 12. Access to the MariaDB CLI has been obtained.

The creation of the '*.so' payload file has been created and then made available for download via Python's 'http.server' module to enable the file to be transferred later.

Figure 13. Using 'msfvenom' to create a reverse shell payload file.

The non-root reverse shell is then used to download the '*.so' payload file into the target host via the 'wget' command.

Figure 14. Transferring the reverse shell payload to the target machine via the 'wget' command.

Before moving forward with the exploit, a new local terminal is created to set up a Netcat listener on port 4444 to anticipate payload execution.

Figure 15. Netcat listener on port 4444

Finally, the payload is executed by configuring the MariaDB system variable 'wsrep_provider' to have the absolute path of the '*.so' file, which effectively executes the reverse shell payload.

The idle Netcat listener has now been activated to spawn root reverse shell access to the host.

Figure 16. The Netcat listener is activated to spawn a reverse shell as root.

MariaDB Source Code Fix

The MariaDB team was quick to resolve this vulnerability. The Jira ticket  emphasized the writability of the `wsrep_provider` and `wsrep_notify_cmd` system variables. It then dives into the details of how both of these variables can be exploited. The description section of the Jira Ticket concludes by merely deciding to convert these affected system variable to have `read-only` properties.

The actual commit that resolved the issue can be found on MariaDB’s GitHub page. Basically, the fix was done to the `sql/sys_vars.cc` file. The `sql/sys_vars.cc` file is written in the C++ programming language and is responsible for defining and managing system variables in the MariaDB source code. System variables in MariaDB are configuration parameters that control various aspects of the server's operation. These variables can be configured to customize the behavior of the database server. In addition, these system variables can be set dynamically or startup.

The modification to this file that fixed this issue was a mere insertion of the `READ ONLY` parameter to both system variables. This establishes that these variables are read-only and, therefore, prevents modifications to these variables during runtime.

Figure 17. Adding 'READ_ONLY' parameter to both the 'wsrep_provider' and 'wsrep_notify_cmd' system variables

Conclusion

Security professionals must quickly resolve RCE attacks due to the potentially high negative impact they can have on organizations. This is especially true if the affected product is a database that may hold sensitive data. One example of such data might be personally identifiable information (PII), which may lead to privacy invasion, fraud, or identity theft. Another example of sensitive data that might be exposed is corporate intellectual property which can lead to the loss of competitive advantage and financial loss.

Trustwave's dbProtect and AppDetectivePro products address the CVE-2021-27928 vulnerability as a component of a missing patch check. To deliver the most recent protection available, Trustwave SpiderLabs security researchers constantly monitor for new vulnerabilities and the methods used to exploit them.