MySQL Vulnerabilities

We are living in a digital era, as the internet and technology are expanding and becoming more and more popular with each passing day, so are the crimes committed on it. In recent years, the cyber-crimes on businesses or in general have significantly grown. These malicious cybercriminals take advantage of poorly designed or flawed systems used by these businesses for either some self-monetary gains by selling data, Ransom, or by any other means; or for besmirching the company’s name and its reputation. MySQL relational database management system is among one of the most popular open-source RDBMS in use currently, the main purpose of using it is to store the data for web servers or websites. Mostly all of the currently popular web servers and also the frameworks use MySQL as their preferred database. Just like any other piece of software MySQL too has some vulnerabilities which can be exploited and can cause significant damage if carried out properly, so to avoid them and to secure the data let’s look at what these vulnerabilities are and their possible fixes.  

1. SQL Injection: It is among the most common and perilous attacks, in this type of attack the attackers steal information or foist data loss by attacking the database. Basically, it is an injection-type attack where the attacker runs malicious SQL queries that could have various serious implications such as losing data or even data stealing.  

Mostly SQL Injections are carried out on web apps. Attackers make use of some known loopholes and vulnerabilities to target the application by SQL Injection vulnerabilities mainly to bypass application authentication process and security or to cause some harm to the database.  

After carrying out a successful attack the malicious user can access the authorized and authenticated sections of web servers and applications, and can also modify, add or delete the data and can also retrieve the records as well.

Let’s take an example of a situation where we are trying to authenticate a user on some application. To do that first we would have to send or input the user’s login credentials for authentication purposes.    

After the credentials are entered the application will build an SQL query below to check if the user with the entered credentials already exists or not.  Query:

SELECT * FROM utable WHERE username = “UserName001”
 AND password = “user1_password”

This was the case of a normal user. Now, what if an attacker is trying to exploit the system they might enter the password as “ ’*’ OR ‘1’ = ‘1’ ” and when the application builds its query it will look like this:

Query:

SELECT * FROM utable WHERE username = “UserName001” 
AND password = ‘*’ OR ‘1’ = ’1’.

So, whenever the system runs this query it would always give the result to be true and the application thinks that the password is correct. In this query, the first part will look for the user with username “UserName001” with the password “*” and it will either give no result or rule it out to be false. This is where the second part of the query comes into play, here the password will always result in true. The application will let the query pass and hence the malicious user will be able to bypass the authentication. In similar ways, the attacker can also modify, add, delete or retrieve the data as they please. However, this can be circumvented either by using parameterized query/ prepared SQL statements or by sanitizing the user inputs, before the application generates the query for the provided inputs.  

2. Improper Input Validation: Improper Input Validation is a dangerous type of attack where a malicious user carries out an attack on web servers or their instances such as MySQL. These attacks are used to make the instances, services, or network resources inaccessible momentarily or even permanently by disrupting the host, system, or the instance it is connected to. In MySQL, it can make the instance of MySQL crash hence making it momentarily inaccessible by any of the services that are using it as its data source.  

The other issue with this type of vulnerability is that it allows remote authenticated users to cause a DoS attack by using a crafted SELECT statement along with a UpdateXML() command with many unique nested elements. The result of this is a more susceptible MySQL to DoS vulnerability. An attacker could exploit this flaw to takedown the whole database and its instances, rendering other services useless and making them inaccessible to the user.  

The payload along with the commands that can be used in this scenario is as follows:

Syntax:

$mysql->query("SELECT UpdateXML('<a>$a<b>ccc</b>
<d></d></a>', '/a', '<e>fff</e>') AS val1");

To avoid this vulnerability the updated versions of MySQL can be used where this exploit has been patched, version 5.5.* and above are free from this vulnerability.

3. Concurrent Execution using Shared Resources with Improper Synchronization or Race Condition: Concurrent Execution using Shared Resources with Improper Synchronization is an undesired condition that happens when a system tries to run two or more than two operations concurrently, though in a majority of the system the operations are performed in the right order or timing because of the uncontrolled events to make sure that the operations are done effectively.  

In MySQL, this can give rise to a race condition, which can be considered a serious problem. It allows a local user to access the database and after that, they can use privilege escalation or escalate their user privileges and after changing their user privileges, they can carry out an arbitrary code execution attack as a local user of the database. This problematic concurrent execution using shared resources with improper synchronization condition is present in MySQL versions before version 5.5.51, 5.6.x to 5.6.32, 5.7.x to 5.7.14 and 8.x to 8.0.0; MariaDB is also affected with this condition MariaDB versions before version 5.5.52, 10.0.x to 10.0.27, and 10.1.x to 10.1.17. The attackers can use this vulnerability to their advantage by exploiting it and bypassing the imposed security restrictions to run unauthorized and arbitrary commands. This could in turn be used as a launchpad for other attacks. Though now this vulnerability has been patched on the vulnerable versions.

4. Permission, Privileges, and Access Controls: It is an old vulnerability that now has been patched. This vulnerability allowed the malicious users to override the config file of MySQL with numerous settings, so these settings could be implemented when MySQL is started next time.  

5. DNS Injection in ghost: This vulnerability was present in ghost (a triggerless schema migration tool for MySQL) versions before version 1.1.3 which had a file path traversal or directory traversal vulnerabilities. In order to exploit it, the attacker either needs to have access to the target host or they need to trick the admin to run a crafted ghost command on the host running ghost along with the network access from the target host running ghost to the attack’s malicious MySQL server. The -database parameter must also be properly sanitized to avoid this.  

If the code is vulnerable then a command like the below could be crafted and used to exploit this vulnerability.

Syntax:

./gh-ost -user test -password -test -alter
 test -table test -database “test?allowAllFiles=true&”