ScriptAlias, Backdooring Apache, and the Plesk Remote Code Execution Exploit. (Also a free 0day :P)

/* WARNING: This post is slightly “rambling” as it is written without my usual proofreading and checking over for errors due to being my “field notes” of sorts, and due to current affairs leading to incredible time constraints. For those looking for the “Free 0day” mentioned in the title, read carefully ;) */

So, while experimenting with kingcope’s shiny Plesk RCE exploit – http://seclists.org/fulldisclosure/2013/Jun/21 – I decided to implement my own exploit for it in Python. Thanks to previously writing an exploit for the PHP-CGI vulnerability, this proved to be trivial.

The exploit is here: http://packetstormsecurity.com/files/122163/Plesk-PHP-Code-Injection.html

Now, that is nice and all, but lets take a look at why this vulnerability occurs.

Basically, the Apache config shipped with the vulnerable versions of Plesk, contains the directive ‘ScriptAlias /phppath/ “/usr/bin/”‘. This means that you can call any binary in the /usr/bin directory as a CGI script by passing it, and its arguments, in a URL, like so: host/phppath/php?-h

This allows you to directly call the PHP binary, have it executed as a CGI program, and the “-h” argument would be passed to it. What makes the exploit work, is we call the PHP binary and send it some arguments that allow us to send it PHP code to execute. You can, in fact, call *any* binary in /usr/bin/ and pass it args, the PHP interpreter being the easiest to abuse*

Basically, the vulnerability is caused by using the ScriptAlias directive to point at a directory, allowing one to call arbitrary binaries and use those to execute code.

Now, this is where it gets interesting.

I found it was trivial to “introduce” this vulnerability to an Apache webserver with one line, simply appending ScriptAlias /backdoor/ “/usr/bin/” to the httpd.conf file, or any file included by httpd.conf. This allows for a very sneaky PHP code execution backdoor to be “injected”, leaving no tell-tale files in the webroot, however, it does mean modifying a (often root owned) file. Still an interesting way to “add another way in”.

I then wondered if this line was a common thing to find in Apache config files, and if it could reliably allow remote code execution.

A few google queries later, and I was facedesking. And asking for a VPS to run some tests on.

First off, here is a well ranked guide on google for installing PHP in CGI mode on Ubuntu, which leads to a vulnerable configuration.
http://www.binarytides.com/setup-apache-php-cgi-ubuntu/

Next, we have OpenWRT Wiki showing us how to set up PHP… And leave ourselves open for the pwning.
http://wiki.openwrt.org/doc/howto/http.apache

There were a few others, which I will leave locating up to the reader.

Anyway, there was enough hideous code to make me consider writing an exploit/remote testing utility in Python for this bug, which is in my github repo for exploits at https://github.com/infodox/exploits
Running lolapache.py <site> will begin the process of probing and owning. Check out paths.txt, which contains the paths to probe for.

Demo:

Anyways, now for the TL;DR: If you are gonna be using Apache, and ScriptAlias’ing PHP, you are gonna have a bad time.
As for the free 0day, well. A whole load of boxes use these crappy configs, which means a whole load of boxes are ripe for getting owned by any moron with half a brain.

* I had a hit-and-miss series of tests passing an oneline reverse shell directly to Python interpreter and Perl interpreter, but it was unreliable. Some guys on rdot showed a method of using curl and python to pull down code and execute it.

Using PHP’s data:// stream and File Inclusion to execute code

This is a reasonably old remote code execution trick that I was actually unaware of until recently, illness when I stumbled across it by accident. I have been heavily researching various ways to go from a file inclusion bug to a remote code execution bug, and this one really got me interested.

As we previously mentioned in the I expect:// a shell post, medical you can use certain PHP streams to execute code via a file inclusion vulnerability. This one does not require any PHP extensions to be installed, unlike the expect:// trick, and relies solely on allow_url_include to be enabled, which sadly is becoming a rarity these days.

How this works is simple. PHP has a data:// stream, which can decode and accept data. If you insert some PHP code into this stream and include() it, the code will be executed. Rather simple, and rather effective too. I will cover php://input in a follow up post, and then post my findings on abusing FindFirstFile.

Essentially, instead of including /etc/passwd or a remote file, you simply include the following. data://text/plain;base64,PAYLOAD_GOES_HERE
Where the payload is base64 encoded PHP code to be executed. I choose to base64 encode the payload to avoid some problems I ran into with whitespace and longer payloads.

Now, obviously this would be no fun without a simple proof of concept tool to demonstrate the vulnerability. The following tool is under serious redevelopment at the moment, so it only spawns a bind shell at the moment. Next version will offer several payloads (I am working on a generic payload library for this kind of thing).

Data:// shell to bindshell :)

You can download the current version of the tool here: PHP data include exploit

I will update that code later, might do a video once there is something worth watching.

I expect:// a shell!

This blog post covers a fascinating method of leveraging Local File Inclusion to gain Remote Code Execution on a vulnerable host. It has several downfalls, but overall is one of the more interesting methods I have found, and I have not found any references to it anywhere that I looked online.

PHP has many “wrappers” to parse certain types of things. For example, the php://input or php://filter wrappers, which have been used in the past for both code execution and information disclosure – notably the PHP-CGI Arguement Injection exploit, which uses the php://input wrapper to inject code after making modifications to PHP.ini directives.

One of the more entertaining ones I stumbled across is how PHP handles the expect:// “wrapper”. For those who do not know, “expect” is a program/scripting language of sorts that one can use to interact with other interactive programs. Some of you may be familiar with pexpect from Python, which is used to interact with SSH sessions for automation. It is a rather powerful utility, and is often used by sysadmins to automate procedures which would normally require human interaction.

As it happens, amongst PHP’s many wrappers, there is an “expect://” wrapper. I stumbled across it by accident while looking up the correct way to use php://filter to read files via LFI (I will document that method later, it deserves a post of its own). I knew expect looked familiar, so when I looked more into it, I found examples of people using it in PHP scripts to automate things like ssh-ing to remote boxes, etc.

After a while it dawned on me that something interesting might just happen if I passed expect://ls to an include() call in a PHP script, so I decided to see what would happen.

I used the following vulnerable (to LFI) PHP script, and called test.php?hax=expect://ls

<?php
$code = $_GET[‘hax’];
include($code);
?>

It provided me with a directory listing of my webroot.

expecting shell

remote code execution

After a few minutes of thinking “oh, this is interesting”, I decided to see if I could knock up an interactive shell in Python to automate the whole procedure.

First off, I decided to see could I get it all to work out using Pythons “requests” module…

Seeing as it worked, now it was time to write a “shell”.

Gotshell?

got shell :)

Yes, I now had a somewhat interactive “shell” on the vulnerable host (localhost…). I considered releasing the proof of concept right there, however further messing about was warranted first, obviously. I needed to see how far I could “push” this vuln, and how cool I could possibly make the PoC tool before releasing it to the wild, where someone would doubtlessly give me much abuse about my python :P

So, without further ado, here is the video demo of it. It now checks if the host is vuln (very rudimentary check), and offers the “inline shell” or a reverse shell :) Download links at bottom :)

// Err, the video is on its way, I did not have time to clean it up sadly. I will edit this post in a day or so with the finished video, I promise :)

download link

Local File Inclusion to RCE, abusing tempfiles and phpinfo()

“If you want to win a race condition, you best cheat”.

The following article demonstrates a fascinating method of exploiting Local File Inclusion vulnerabilities first thought up of by the guy who runs Gynvael.Coldwind.pl . It is further documented at Insomnia Security

To start, when you are exploiting a Local File Inclusion, in order to gain remote code execution you must “write” some PHP code somewhere on disc that you can “include”. Normally this means injecting into logfiles, or the /proc/self/environ interface.
In the event you cannot locate the logfiles, or access them, most people simply give up and claim “Yep, it is unexploitable”.
This is not true.

When you upload files via HTTP POST to a webserver running PHP, during the upload it creates a tempfile for the files data, normally in /tmp. This file is “randomly named” (I do not trust the PRNG PHP uses), and is stored for the duration of the upload.

Now, it just so happens that it will create this file irrespective of whether or not you are legitimately uploading (i.e. the webapp is accepting an upload) or not, and the file is deleted when the “upload” finishes.

Because these files are randomly named, and there are no wildcards that we can use on Linux (more on this later!), you might think “So, how does this help me at all?”.

Normally, you would be right. Unless you find a flaw in the PRNG that allows you to predict the “dummy name” of the file, this is not so useful to you. What we need is an information disclosure bug that displays the PHP variables at that particular time…

… Enter PHPinfo(). The phpinfo() call, often found in /phpinfo.php or other such files (often forgotten and not removed on webservers), displays the PHP variables as they are at that point in time… Including the “Dummy Filename” that is currently in use.

So, if we are to send a file upload, containing our evil PHP code, and then include() it (via the LFI), using the path given to us by the PHPinfo page, we gain code execution on the remote server.
Simple?

Yes, but not quite.
The file exists there for mere fractions of a second, so we lengthen the duration of the upload (we upload to the phpinfo file) by padding it with trash data. The insomniasec paper (linked at bottom) explains this better than I will, so I advise reading it! This is a race condition, so to further enhance our chances, we use multiple threads and multiple attempts. One of them will succeed, normally within short order (averages at 30 seconds, see the demo video!). If you have LFI and a phpinfo() page, you WILL gain code execution on the server.

The PHP code you “upload” and execute via include() effectively acts as a “Dropper”, dropping some malicious code that is stored in /tmp with a filename you have set. You then simply include() this dropped file via the LFI bug to execute code, as per normal LFI.

The InsomniaSec guys released, along with their paper, a demo script to show how it works. imax, the mantainer of Fimap (which I also develop) released a Fimap plugin that exploits this vulnerability, and that is what I am about to demonstrate. imax’s code drops a file named “eggshell” which is essentially a stripped down version of the Fimap payload.

The Fimap module is extremely reliable, giving me shells in short order. I have never had an issue with it to date, and normally on remote boxes it takes a minute or so to pop a shell.

Demo Video

Next week I will be releasing a demo of doing this against Windows targets without the lovely PHPinfo bug. A much “truer” race condition :)

Whitepaper (InsomniaSec)

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”.

A few exploits…

So, lately I have been experimenting a lot with the “Requests” module for python. It makes creating and sending HTTP GET and POST requests so incredibly easy, that I had to use it to write some incredibly simple PoC exploits.

First off, recently there was an advisory about a PHPTax remote code execution vulnerability. So, naturally, I wrote a quick and nasty PoC for it. There is a better one in the Metasploit framework, but I simply wrote this to stave off boredom one evening. This one simply throws you a reverse shell (if the moon, sun and Andromeda galaxy are correctly lined up).

http://code.google.com/p/insecurety-research/source/browse/trunk/misc-exploits/phptax_RCE.py

Using “requests”, you can send a GET request using just requests.get(url)
It is that simple.

The second was an earlier exploit I wrote, before I remembered I could simply inject a reverse shell.

It was an exploit for an Xoops RCE bug. I simply had my exploit wget a shell from a remote server.

http://code.google.com/p/insecurety-research/source/browse/trunk/misc-exploits/xoops_rce.py

There are others in that SVN repo to look at, just have a look :)

I will likely write more later on “Rapid Proof of Concept Creation using ‘requests'” if I could be bothered, there are more vulns to exploit in the meanwhile ;)

0x4641494c – Fail Patching and Symantec Remote Root Redux!

Those of you who have been reading this for a while, or who are familiar with my work, might remember this: Symantec Web Gateway Remote Root, a little PoC I knocked together based on an exploit Muts from Offensive Security wrote. His PoC, I felt, was a tad unuseable, so I made an attempt at reinventing it :)

So, naturally, Symantec patched this terrible vulnerability. And everyone breathed a sigh of relief.

Or so they thought! Muts revisited it post-patch, and simply found another way to exploit the EXACT SAME FLAW. And when he released the PoC for his “Exploit: Reloaded”, I like to think he took my advice and wrote a better ‘sploit, as his new one is very similar to my “more weaponized” PoC. A bit neater too… Is this a game of one-upmanship? ;)

Without further ado, here is the exploit: Muts Reloaded!

Anyways, I better go off and finish that demo on Cryptfuscate I promised I would write :)
~infodox