php vulnerability need to upgrade

#2 Thu, 11/14/2013 - 03:32

MDS85

When the php5-cgi package is installed on Debian and Ubuntu or php-cgi is installed manually the php-cgi binary is accessible under /cgi-bin/php5 and /cgi-bin/php

I could be wrong, but it seems the fastest way to mitigate this would be to just remove access to the /cgi-bin/ folder. Upon some investigation, the /cgi-bin/ directories that Virtualmin creates for virtual hosts do not contain either the "php" nor "php5" executables.

This exploit report is rather talking about the default apache website. /usr/lib/cgi-bin/ is where these executables are kept and it appears they are only accessible from the default website, so as long as you have one normal virtualhost which acts as the default website, you're not vulnerable.

Though, it would be wise to either comment out or completely remove the following block from Webmin Tab > Servers > Apache Webserver > Global Configuration > Edit Config Files > Find and edit "/etc/apache2/sites-available/default"

Then find:

   ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
   <Directory "/usr/lib/cgi-bin">
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
      Allow from all
    </Directory>

...And either remove it, comment it out, or maybe even change "Allow from all" to "Deny from all".

(don't forget to restart apache!)

We're in 2013, I'm not even sure why /cgi-bin/ is still a thing by default, except for what, awstats :p. Such is life.

Although these seem like the proper steps, I would also like confirmation.

#3 Thu, 11/14/2013 - 07:15

agentbleu

MDS85, thank you for the input and suggestions, while you are probably correct i have 2 servers so far affected both have at least one normal virtualhost, i suspect this is though that the IP level it where it is showing "it works" and the default was not removed, so /var/www etc. Right now im thinking that a php update is required but that is serious hassle from experience so if can be avoided that would be better.

#4 Thu, 11/14/2013 - 07:45

agentbleu

also im running

This virtual server is using the mod_php execution mode for PHP, such does not allow per-directory version selection.

#5 Thu, 11/14/2013 - 07:49

andreychek

Howdy,

Well, you mentioned having a non-standard PHP version... is that something you need?

As when using the standard packages available on Ubuntu, that issue should be corrected.

You link mentions the security ID for that vulnerability, "CVE-2012-1823".

Ubuntu published a fix for CVE-2012-1823 in May of last year, there's information on that here:

http://www.ubuntu.com/usn/usn-1437-1/

#6 Thu, 11/14/2013 - 08:25

agentbleu

Im thinking if in webmin, Apache Webserver, you delete the default Virtual Server /var/www/ along with the associated cgi path that should solve this issue?

#7 Thu, 11/14/2013 - 08:38

agentbleu

and inside webmin / servers / Apache webserver / Configure Apache Modules / unclick cgi and fcgid then update enable selected modules so they are not enabled

#8 Thu, 11/14/2013 - 08:42

agentbleu

andreychek, thanks for input this is a new twist on that exploit that first appeared on 30th Oct 2013 and is a hot issue right now, if you look online you will see a lot of discussion of people getting hacked recently as of that date.

http://www.reddit.com/r/netsec/comments/1phjr7/apache_php_5x_remote_code... http://forum.excito.net/viewtopic.php?f=9&t=4633&start=90

#9 Thu, 11/14/2013 - 12:19

andreychek

I would be curious if you could exploit a stock Debian, Ubuntu, or CentOS installation running PHP as CGI.

I read the full Forum thread that you linked to, as well as the reddit link -- and I don't see anything in there which confirms that the standard, patched versions of those have a problem.

In fact, I see some references to folks using a default Ubuntu install, who tested and were not vulnerable.

A lot of what I'm reading there makes me wonder if it's largely folks running non-standard PHP versions that are having this problem.

-Eric

#10 Thu, 11/14/2013 - 13:05

agentbleu

I have it on 2 set ups one is

I have on 3 different installs of virtualmin, all totally different, set up years apart and have nothing connected and are standard installs

#11 Thu, 11/14/2013 - 13:07

agentbleu

to check any install for the issue look in error log and do a search for

Security Alert!

that will show all the exploits from the 30th oct

Tue Oct 29 21:07:33 2013] [error] [client 66.197.237.101] Security Alert! The PHP CGI cannot be accessed directly. [Tue Oct 29 21:08:55 2013] [error] [client 66.197.237.101] Security Alert! The PHP CGI cannot be accessed directly. [Tue Oct 29 21:10:16 2013] [error] [client 66.197.237.101] Security Alert! The PHP CGI cannot be accessed directly. [Tue Oct 29 21:10:16 2013] [error] [client 66.197.237.101] Security Alert! The PHP CGI cannot be accessed directly. [Tue Oct 29 23:45:40 2013] [error] [client 66.197.237.101] Security Alert! The PHP CGI cannot be accessed directly. [Tue Oct 29 23:47:01 2013] [error] [client 66.197.237.101] Security Alert! The PHP CGI cannot be accessed directly. [Tue Oct 29 23:48:23 2013] [error] [client 66.197.237.101] Security Alert! The PHP CGI cannot be accessed directly. [Tue Oct 29 23:48:23 2013] [error] [client 66.197.237.101] Security Alert! The PHP CGI cannot be accessed directly. [Wed Oct 30 11:13:31 2013] [error] [client 103.10.98.110] Security Alert! The PHP CGI cannot be accessed directly. [Wed Oct 30 23:02:10 2013] [error] [client 217.199.213.13] Security Alert! The PHP CGI cannot be accessed directly. [Wed Oct 30 23:12:29 2013] [error] [client 217.199.213.13] Security Alert! The PHP CGI cannot be accessed directly. [Thu Oct 31 13:45:18 2013] [error] [client 213.202.244.211] Security Alert! The PHP CGI cannot be accessed directly. [Fri Nov 01 03:49:16 2013] [error] [client 66.84.18.202] Security Alert! The PHP CGI cannot be accessed directly. [Fri Nov 01 03:49:17 2013] [error] [client 66.84.18.202] Security Alert! The PHP CGI cannot be accessed directly. [Fri Nov 01 10:20:59 2013] [error] [client 82.98.104.217] Security Alert! The PHP CGI cannot be accessed directly. [Fri Nov 01 10:21:04 2013] [error] [client 82.98.104.217] Security Alert! The PHP CGI cannot be accessed directly. [Fri Nov 01 12:24:25 2013] [error] [client 91.238.255.71] Security Alert! The PHP CGI cannot be accessed directly. [Fri Nov 01 20:55:33 2013] [error] [client 205.207.165.210] Security Alert! The PHP CGI cannot be accessed directly. [Fri Nov 01 23:37:28 2013] [error] [cl

#12 Thu, 11/14/2013 - 13:33

andreychek

Howdy,

I'm not trying to be dense or disagreeable, I'm just trying to verify whether this is indeed an issue on a stock installation of a distro (you indicated above that one of yours was running a non-standard PHP version, which may indeed be vulnerable).

The errors that you're showing from your logs above -- those messages seem to appear when the attack was successfully mitigated (that is, when it doesn't work).

I attempted to perform some of the exploits provided on a test Ubuntu 12.04 installation I have here, and all were unsuccessful, but it did generate this error each time:

Security Alert! The PHP CGI cannot be accessed directly.
This PHP CGI binary was compiled with force-cgi-redirect enabled.  This means that a page will only be
served up if the REDIRECT_STATUS CGI variable is set, e.g. via an Apache Action directive.  For more
information as to why this behaviour exists, see the manual page for CGI security.

I'll do some more testing, but thus far I wasn't able to reproduce that security issue on an installation containing the default/patched version of PHP.

I'll let you know what I find though!

Oh, just to help out in my testing -- for any of the systems you have where that was indeed a problem (that is, where the exploit was successful), what is the output of "php -v"?

Thanks!

-Eric

#13 Thu, 11/14/2013 - 13:53

agentbleu

Sure of course, but this server was a standard install from the install.sh

root@relevancy: php -v PHP 5.2.4-2ubuntu5.23 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11 2012 03:50:23) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

this might be more helpful

this is on another server

https://p.linode.com/8230

and on another server, both these using standard instal scripts

https://p.linode.com/8231

#14 Thu, 11/14/2013 - 14:03

Locutus

I'm using fcgid for all my Virtualmin hosted websites. I'm seeing this attack pattern in my logs as well; so far all of them were met with a 404 error, since the cgi-bin directory is empty when using fcgi. Apache's default website is disabled.

Can one consider Virtualmin's fcgi implementation safe in terms of this vulnerability?

#15 Thu, 11/14/2013 - 15:02

andreychek

Regarding whether using FCGID makes one safe -- I suspect the issue there is just that the worm that's going around is only testing on /cgi-bin/, it's probably not testing other directories. The original vulnerability appears to work on FCGID, if I'm reading the info about it correctly.

However, I just setup a brand new Ubuntu 12.04 install, and downloaded the exploit for the issue that's occurring now.

I configured Virtualmin to use CGI for this particular domain. I then needed to copy cgi-bin/php5.cgi to cgi-bin/php-cgi.

Once I did that, I ran the exploit against the server here, and it wasn't successful.

Then, I removed cgi-bin/php-cgi, and copied the actual PHP5 binary, /usr/bin/php-cgi, into cgi-bin.

After doing that, it continued to not be successful... I see this message:

***SERVER RESPONSE***

HTTP/1.1 500 Internal Server Error
Date: Thu, 14 Nov 2013 20:28:42 GMT
Server: Apache/2.2.22 (Debian)
Vary: Accept-Encoding
Content-Length: 612
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>

And this is generated in the Apache error log:

malformed header from script. Bad header=<b>Security Alert!</b> The PHP: php-cgi

The exploit is supposed to be running a program remotely on the server that generates some output... and I'm not seeing any sign of this. I only see an error that the attempt to access the PHP binary directly was a security issue, and was denied.

For anyone who has seen this issue, and feels that can reproduce it --

What output do you receive, when running any of the exploits?

Can you paste in the output that appears to signify a successful exploit?

-Eric

#16 Thu, 11/14/2013 - 15:29

Locutus

Re: FCGId: Okay, what directory would a successor worm need to check to make use of the exploit? If I'm right, I don't see a php executable directly available anywhere in an fcgid Virtualmin installation... The "fcgi-bin" directory is only configured to be used as a handler for *.php files, not to be directly accessible. Only the empty "cgi-bin" directory is accessible.

Is there any vulnerability visible in this Virtualmin default fcgid setup?

DocumentRoot /home/DOMAIN/domains/SUBDOMAIN/public_html
ScriptAlias /cgi-bin/ /home/DOMAIN/domains/SUBDOMAIN/cgi-bin/
DirectoryIndex index.html index.htm index.php index.php4 index.php5
<Directory /home/DOMAIN/domains/SUBDOMAIN/public_html>
Options -Indexes +IncludesNOEXEC +SymLinksifOwnerMatch +ExecCGI
Allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
FCGIWrapper /home/DOMAIN/domains/SUBDOMAIN/fcgi-bin/php5.fcgi .php
FCGIWrapper /home/DOMAIN/domains/SUBDOMAIN/fcgi-bin/php5.fcgi .php5
</Directory>
<Directory /home/DOMAIN/domains/SUBDOMAIN/cgi-bin>
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>

#17 Thu, 11/14/2013 - 17:28

agentbleu

andreychek if you would like to test it against one of my servers that was affected let me know i have 3 which i have secured now but its easy to step it all backwards. so you can test and see, if you want details of the server let me know by email

#18 Fri, 11/15/2013 - 15:31

agentbleu

update the changes i have made to the servers comprimised did not resolve the issue and was hacked via same route again last night, now making more more change that is to

Apache Webserver /Existing virtual hosts / Virtual Server / then delete the /cgi-bin/ account

#19 Fri, 11/15/2013 - 15:39

agentbleu

also lots more talk about this

http://www.howtoforge.com/forums/showthread.php?t=63740

#20 Fri, 11/15/2013 - 16:36

agentbleu

What would be really appreciate from Virtualmin would be a solution for setups that are vulnerable, clearly its a big issue lots of people affected lots on virtualmin and noting so far 3 days after first reported here as to how to handle it from...

#21 Fri, 11/15/2013 - 17:04

andreychek

You mentioned that on your server, you have this PHP version:

php -v PHP 5.2.4-2ubuntu5.23 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11 2012 03:50:23) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

That PHP version isn't a version included in any supported Ubuntu version though. It appears to be the PHP version included with Ubuntu 8.04, which is no longer supported.

The version output there says that it was built prior to the initial exploit being released. That is, the build date of your PHP version is February 2012, but the exploit came out in May of 2012.

That PHP version would indeed be vulnerable.

If your system there is Ubuntu 8.04 (you can verify that by looking in /etc/issue), you'd want to upgrade to a supported distro.

If that is running a supported distro, but it's just running an older PHP version -- we'd recommend upgrading to a PHP version that's not vulnerable to that issue.

-Eric