Mysql 8.0.25 Exploit

[Lynne Pruskowski]

TheExploit Database is maintained by OffSec, an information security training company that provides various Information Security Certifications as well as high end penetration testing services. The Exploit Database is a non-profit project that is provided as a public service by OffSec.

The Exploit Database is a CVE compliant archive of public exploits and corresponding vulnerable software, developed for use by penetration testers and vulnerability researchers. Our aim is to serve the most comprehensive collection of exploits gathered through direct submissions, mailing lists, as well as other public sources, and present them in a freely-available and easy-to-navigate database. The Exploit Database is a repository for exploits and proof-of-concepts rather than advisories, making it a valuable resource for those who need actionable data right away.

The Google Hacking Database (GHDB) is a categorized index of Internet search engine queries designed to uncover interesting, and usually sensitive, information made publicly available on the Internet. In most cases, this information was never meant to be made public but due to any number of factors this information was linked in a web document that was crawled by a search engine that subsequently followed that link and indexed the sensitive information.

After nearly a decade of hard work by the community, Johnny turned the GHDB over to OffSec in November 2010, and it is now maintained as an extension of the Exploit Database. Today, the GHDB includes searches for other online search engines such as Bing, and other online repositories like GitHub, producing different, yet equally valuable results.

If you are just replacing ' with '' then you could exploit this by injecting a \' which will turn into a \'' and this will allow you to break out because this gives you a "character literal" single-quote and a real single-quote. However, the replacement of "\\" with "\\\\" negates this attack. The double-single-quote is used to "escape" single quotes for MS-SQL, but this isn't proper for MySQL, but it can work.

The following codes proves that this escape function is safe for all except three conditions. This code permutes though all possible variations of control charters, and testing each one to make sure an error doesn't occur with a single quote encased select statement. This code was tested on MySQL 5.1.41.

The conclusion is to always use mysql_real_escape_string() as the escape routine for MySQL. Parameterized query libraries like pdo and adodb always use mysql_real_escape_string() when connected to a mysql database. addslashes() is FAR BETTER of an escape routine because it takes care of vulnerable condition 2. It should be noted that not even mysql_real_escape_string() will stop condition 1, however a parameterized query library will.

Of course you would have to change the table name and the numbers inside the UNION SELECT to match the amount of columns you have. This is a popular way of extracting data like admin user names and passwords.

Since you are using UTF-8 as the encoding, this could be vulnerable to an overlong UTF-8 sequence. An apostrophe character ('), while normally encoded as 0x27, could be encoded as the overlong sequence 0xc0 0xa7 (URL-encoded: %c0%a7). The escape function would miss this, but MySQL may interpret it in a way that causes a SQL injection.

As others have mentioned, you really need to be using mysql_real_escape_string at minimum (easy fix in your case), which should be handling character encoding and other issues for you. Preferably, switch to using prepared statements.

Could someone please point me to a link with some information on multibyte character exploits for MySQL? A friend brought them to my attention, but I've not been able to find much information on the Internet.

Summary. Yes, the issue is that, in some character encodings (like UTF-8), a single character is represented as multiple bytes. One way that some programmers try prevent SQL injection is to escape all single quotes in untrusted input, before inserting it into their SQL query. However, many standard quote-escaping functions are ignorant of the character encoding that the database will use and process their input as a sequence of bytes, oblivious to the fact that a single character might fill up several bytes. This means that the quote-escaping function is interpreting the string differently than the database will. As a result, there are some cases where the quote-escaping function might fail to escape portions of the string that the database will interpret as a multi-byte encoding of a single quote; or might inadvertently break up a multi-byte character encoding in a way that introduces a single quote where one was not previously present. Thus, multi-byte character exploits give attackers a way to do SQL injection attacks even when the programmer thought they were adequately escaping their inputs to the database.

The impact. If you use prepared/parametrized statements to form all database connections, you are safe. Multi-byte attacks will fail. (Barring bugs in the database and the library, of course. But empirically, those seem to be rare.)

However, if you try to escape untrusted inputs and then form a SQL query dynamically using string concatenation, you may be vulnerable to multi-byte attacks. Whether you are in fact vulnerable depends upon specific details of the escaping function you use, the database you use, the character encoding that you're using with the database, and possibly other factors. It can be hard to predict whether multi-byte attacks will succeed. As a result, forming SQL queries using string concatenation is fragile and not recommended.

Technical details. If you'd like to read about the details of the attacks, I can provide you with a number of links that explain the attacks in great detail. There are several attacks:

Attacks on, e.g., UTF-8, that conceal the presence of a quote by using an invalid non-canonical (over-long) encoding of the single quote: see, e.g., here. Basically, the normal way of encoding a single quote has it fit into a single-byte sequence (namely, 0x27). However, there are also multi-byte sequences that the database might decode as a single quote, and that do not contain the 0x27 byte or any other suspicious byte value. As a result, standard quote-escaping functions may fail to escape those quotes.

Mutli-byte attacks are not limited to SQL Injection. In a general sense multi-byte attacks lead to a "byte consumption" condition in which the attacker is removing control characters. This is the opposite of the classic ' or 1=1--, in which the attacker is introducing the single-quote control character. For mysql there is mysql_real_escape_string() which is designed to take care of character encoding problems. Parametrized query libraries like PDO will automatically use this function. MySQLi actually sends the parameters of the query as a separate element within a struct, which avoids the problem entirely.

In this case the 0xE0 is a special byte that signifies start of a 3 byte symbol. When the browser renders this html the flowing "> will be consumed and turned into a single Shift-JIS symbol. If the attacker controls the following input by means of another variable then he can introduce an event handler to obtain code execution.

A little background: We've just had our PBX system hacked. The server itself seems secure (no logged unauthorised console access - SSH etc), but somehow the hackers have managed to inject a new admin user into the PBX software (FreePBX, backed by MySQL). Apache logs imply that the hackers managed to add the user without using the web interface (or any exploit in the web interface).

MySQL will never log you in to a user with the localhost or 127.0.0.1 host specification if you aren't coming from the local system. Note that this also covers the auth bypass vulnerability, CVE 2012-2122; the password comparison might be tricked, but the host comparison is not.

The name root is created by default and is very well known. The literal value root does not have any significance in the MySQL privilege system. Hence there is no requirement to continue with the user name root.

3a8082e126