Battling Windows MySQL: From root to SYSTEM (Part I: MOF Exploitation)

In this two part series I am going to share two methods you can use to gain command execution against Windows MySQL instances when you have privileged MySQL user account. First here in part one, I will cover MOF exploitation technique and then in part 2 I will go over the UDF (User Defined Function) DLL Injection method. They both exploit the MySQL Service which on Windows typically runs as SYSTEM so this can be a very high payout for the exploit as SYSTEM level access means full compromise of the local box if successful. The MOF exploit is very stable and works against pre-Vista machines like XP and Server 2003 while UDF method has less restrictions.

What the heck is a .MOF File?
First and foremost this is a Windows specific file format so automatically rules out non-Windows based targets, sorry. Some nice quotes i pulled from the web "A MOF file contains MOF language statements, compiler directives and comments". "A MOF file can be encoded in either Unicode or UTF-8 format. MOF files are text files that contains definitions of classes and instances using the Managed Object Format (MOF) language." We can leverage their design to use JScript, ActiveXObject and WScript.Shell to run commands or whatever other cool wizardry you can come up with. The code in these files is fairly harmless until it is compiled by a binary tool which comes on windows boxes called 'mofcomp.exe'. The Managed Object Format (MOF) compiler (mofcomp.exe) parses the passed files and adds the classes and class instances defined in the file to the WMI repository which allows the magic to happen. If you want to read more on mofcomp.exe check here. If you want to write your own custom .MOF file to do even more whimsical magic sorcery?. Read up on the specs and requirements here.

Now in Pre-Vista Windows there is a magical home for .MOF files which need compiling by mofcomp.exe tool, and this is at 'c:\windows\system32\wbem\mof\'. Apparently on pre-Vista versions this directory is periodically scanned for new additions. Anything new it finds is passed along to mofcomp.exe and auto-compiled, no human interaction needed. This is our ticket to privilege escalation or our way in when it comes to exploiting MySQL for command execution with this technique. On Windows MySQL tends to run as a privileged user and there are no default restrictions to where this user can write as result - which means we can write files to this magic directory as MySQL user! If we can craft a .MOF template sneaky enough and write it there, it will auto-compile it running our code inside. I should note that after it is compiled by mofcomp.exe it is moved into the 'c:\windows\system32\wbem\mof\good\' directory, if anything fails during compiling it is moved to 'c:\windows\system32\wbem\mof\bad\'. It is worth mentioning that there is also a log file for all mofcomp.exe actions taken which can be found at 'c:\windows\system32\wbem\Logs\mofcomp.log'. This log contains a time-stamp and reference to files compiled along with any errors encountered.

FUN FACT: If you write files here and have them compiled, they will run repeatedly until deleted. Also due to this cyclical nature you can end up with commands occasionally running one more time even after removal of the actual .MOF payload file. For example if you run a onetime instance to create a new user account. It will keep being created if the admin doesn't find the MOF file and simply keeps trying to delete the account itself.....re-appearing accounts for red team pranks anyone?


Connecting the dots to get a shell:
Now that you know about this magical place, and you have read my previous tutorials on writing files with MySQL this wont be a giant leap for us. We first will need to come up with a way to upload a binary file from our local machine to the remote machine. In order to do this we read the file in binary mode, then convert to hex formatting to make injection easy. We will also make a point of using DUMPFILE so its writing as a single line and wont mess with our binary format. Once the file is written, it happens almost instantly but may take a minute or two to get scanned and run so be patient before completely walking away.

Ruby Code to Read Binary and Upload (passed a db connection object, the local file path, and the destination path on target):


Now when it comes to the .MOF template for code execution with this method i borrowed what I could find to suit my needs. I actually found a random PHP version of this exploit sitting on a server I was auditing! It was using a simple template to run commands one at a time through WScript.Shell.run() so I used that as a base for command execution as it compiles without issues in all my tests. I then took the beefier version from MSF found in the /msf/lib/msf/core/exploit/wbemexec.rb script and used for their version of this exploit. This .MOF template takes the location to binary.exe to run (it also has some built-in cleanup code to remove files after). We can use either template to our liking, we can use the simpler template to execute single command at a time or we can use the fancy template to run a binary (which we need to upload before hand). I came up with some code to leverage these features and techniques to achieve code execution, raw binary file uploading via SQL, reverse shell via uploading of nc.exe and then running single command to call home with cmd.exe attached. Below is a quick video demonstration to show you how things can work with the MOF exploit when you find yourself with privileged user access to MySQL on Windows box. You can also find the source code and download links below that.

VIDEO: YouTube

Download Full Exploiter Pack: DOWNLOAD
NOTE: Contains nc.exe & sbd.exe in /payloads)

UPDATE: You can now find this on my Github page here: https://github.com/Hood3dRob1n/SQLi

Pure Ruby Core Source Code: PASTEBIN






Food for thought: This method supposedly doesn't work on newer instances due to them not auto-compiling the .MOF files like we see done with XP and 2k3 systems. Not tested but curious what happens if we pre-compile with mofcomp.exe ourselves and then write to the updated /good/ location.....

Until next time, Enjoy!