 Hello, good afternoon everybody. My name is Muamin Zoprakhar and today I'm going to give a presentation called Advanced My SQL Exploitation. So basically it's how can you conduct a remote code execution on my SQL platform. Here's a very introduction about myself. I'm Secretary Consultant of SecretsAssessment.com. We are a New Zealand-based company focused on the penetration testing and security research. So I'm sure most of the people in this room have a clear idea about SQL injection. It's a conditions where we are able to manipulate SQL treatment through the application and normally a SQL injection is used to view, modify and delete database data. In some cases it's possible to conduct remote code executions by attacking this type of vulnerability. So stack queries are conditions where multiple SQL statement aren't allowed and they are normally being separated by semicolons. Stack queries have been known widely been abused to write a file on the database server. In the Black Hat Europe 2009, Benando Demily demonstrated how stack query can be abused to conduct a remote code execution on a few different databases. And today I'm going to demonstrate how we can conduct a remote code execution on the application that do not support stack query. Here is an example how stack query can abuse on a MySQL platform. This technique is known as a UDF injection tenant. However, it only works on the ASP.NET application due to the stack query allowed. If you look at the stack query tables, on the top side we have different type of applications. On the left side we have all different type of databases. As you can see in this table, there are only two applications that do not support stack query by default. They are known as ASP.NET and PHP. So what we're going to focus today, we're going to focus on the PHP MySQL. As we know, PHP is widely used with MySQL and they are part of the software stack for the LAM and WEM environment. So traditionally, PHP shell can be used to execute commands by attacking MySQL PHP. So if we can just simply execute commands on the web server, why we need more available shells? A good answer for this is the Metaprater Shells. Metaprater Shells is a powerful shell that can be very useful in the post-exploitation process. So we can use Metaprater Shells to conduct a token impersonation attack to escalate our privilege from a local system to administrate the user. And we also can use Metaprater Shells to migrate from one process to another process. Another example is if in some cases when we want to have a graphic user interface, we can just simply use the VNC shell. And all the shells code for this shell can easily be created using a Metasflight framework. So here are some basic techniques in reading and writing files on the MySQL PHP platform. So basically we use select load in file to read a file and then select into out file or down file to write a file. And the next one is the remote code execution technique on the MySQL PHP. So basically we can upload our arbitrary file, compress our arbitrary power, and then this file can be decompressed back to its original size before it is executed using a PHP system function. If the application do not support stack query, the only method to write a file is through the union select. And here are some challenges in writing an arbitrary file through a union select. First, the get request only limit us to only up to 8190 bytes on our patching. And also data from our first query can override our file header. And the last one is data from the extra column can add unnecessary data into our arbitrary file, and this can potentially corrupt our file. So I'm going to explain in details how we can fix all of the issue. So to fix the URL length issue, we can simply use the Zlib module to compress our arbitrary file. In my experiment from 9625 bytes, I was able to compress my file only up to 630 bytes. And this will be able let me to bypass the maximum limit allowed on our patching. And this file can then be decompressed back on the destination before it been executed. Union select will combine a result from the second query and the first query. And most of the time, you will find that the result from the first query will override your file header. So to prevent this to happen, we can inject a non-existing value in the where clause. If you look at this example, question equal 169 will return us a string Defcon. And this string will override our file header. So if we can find any non-existing value to replace a variable question, we can force the application to return us an empty data. And it can prevent our file from being corrupted. So fixing the column issue. So in union selects, the second query required the same amount of column of the first query. In most of the time, you will find you need to inject some unnecessary data into some of this column. To prevent data corruption, our arbitrary file need to be injected in the first column. This is because when we compress our file, Zlib uses Adler32 checksums. And this value is added at the end of our compressed arbitrary file. In IRC, it is stated that anything after this value will be ignored during the compression process. So we can just simply abuse this functionality. Another method is by splitting our arbitrary file into the amounts of columns and then injects our data by sequence into each of these column. Here is an example. Let's say we required three columns. And you can see here the arbitrary data is injected only in the first column. And then we got two null bytes. And this null byte is injected on the second column onward. So remote code executions on the LAM has one limitations. Because by default, directory created in Linux is not writable. But in some cases, you will find the application that required this directory to be writable. One example is the application that allow user to upload contents. So if we can find this type of application, we can abuse the functionality by uploading our arbitrary file into this directory. And also file created through the select into down file is not executable by default. But this is not an issue because we can just simply use a PHP to read the file contents and write to another file. And then this file can be... The permission for this file can be changed using a PHP system function. Remote code execution on the WAM has less limitation compared to the LAM. This is because by default, my SQL run as a local systems. And this user is allowed to write anywhere in the web server directory. If we found a WAM system, we can just simply write our arbitrary file into one of the web server directory and then use the same technique we use on the LAM, which we use a PHP system function to execute this arbitrary file. So what is MySQL? MySQL is a SQL injection takeover tool that I wrote as a proof of concept to demonstrate how we can perform a remote code executions on the LAM on the WAM environment. It contains a few different modules and they are known as SQL injection detections module fingerprint directory module fingerprint operating systems payloads and exploit module. And now I'm going to demonstrate how we can use all this module to upload and execute Metasploit shellcode. Okay, so we're going to try the first module, which is known as SQL injection detection module. So basically it uses a deep blind injection method, which is known as the timing attack. So you can see here SQL injection, Venerability is successfully discovered and it contains only one columns. And then the second one is the fingerprint operating system module. So basically fingerprint operating system module using a load in file method which is tried to load a default file for Linux and Windows. And by doing that, it can compare with the target systems running on the LAM or on the WAM. So as you can see here, you can see that the database is running on the Windows so we know that our target is running on the WAM environment. And then the next module is the fingerprint working directory module. So basically it uses two different methods. They are known as error message method and the other one is load in file method. So basically the error message method is used by injecting a bogus data as part of SQL query. Because normally PHP were written as an error message and this error message contains a sensitive information about the working directory. And then the second method is known as the load in file method. So basically what it does, it tried to load a default file for Apache configuration files because this file contains a sensitive information of working directory as well. So as you can see here, the first method was failed and now it's trying on the second method. And you can see here, here is our web server working directory. So we can just copy this information as required as part of the argument in the exploit module. And then the next one is the payload module. So basically Mike's Cloud will integrate with the MetaSpy framework to create a suitable payload for our target. So let's say I want to create a reverse bind shellcode on the port 9999. As you can see here, our shellcode is successfully created and it bind on port 999, reverse VNC shellcode. And now it's the last module, it's the export module. And as you can see here, here are the arguments required. So we can just simply add all the information that we had before. Writable directory is not required in this case. This is because we know that they are pressing our targets running on Windows. And basically MySQL on Windows run as a local system. So we can just simply write into any web server directory. So in this case, I just choose a web server root directory. And now you will see some bunch of a compressed arbitrary file be uploaded. And then this file will be decompressed back to its original size before it is executed using a PHP system function. And you see the MetaSpy listener is running on port 999 and it's waiting for the connection. And you can see the shellcode is successfully executed and now we have our VNC shells.