[BlueOnyx:14234] Re: PHP Exploit on different BO5108

[Michael Stauber]

Hi Joachim,

> I have found an exploit -
2012-1823<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1823>
> 
> Is bluonyx affected (with or without installed solarspeed php package)?

That's a fairly old exploit which has been reported one year ago and has
been fixed since then in subsequent PHP releases as well as in updates
from RHEL, CentOS and Scientific Linux.

You can check that on your BlueOnyx this way:

[root at 5108r ~]# rpm -q --changelog php|grep CVE-2012-1823
- correct detection of = in CVE-2012-1823 fix (#818607)
- add security fix for CVE-2012-1823 (#818607)

So you can see, the changelog for the RPM "php" shows two references to
that CVE number.

Likewise, the URL you quoted has three links to RHEL security
announcements, in which they explain when and how they fixed it.

So the PHP-5.1.6 on BlueOnyx 5106R and the PHP-5.3.3 on 5107R/5108R are
safe - provided you are fully YUM updated.

> Also with different php-version and all affected with the exploit:
> Solarspeed 5.3.8
> Solarspeed 5.3.19-1
> php-5.3.3-27.el6_5.x86_64 (original)
> 
> Nothing found for now:
> Solarspeed 5.3.26-1

Let us look at the CVE explanation:

Description
------------

sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when
configured as a CGI script (aka php-cgi), does not properly handle query
strings that lack an = (equals sign) character, which allows remote
attackers to execute arbitrary code by placing command-line options in
the query string, related to lack of skipping a certain php_getopt for
the 'd' case.

So what's vulnerable?

PHP older than 5.3.12
PHP older than 5.4.2

The vulnerability can only be exploited if PHP runs as CGI script via
php-cgi. If it's used as DSO (stock behavior on BlueOnyx) this is not
exploitable.

Are Solarspeed PHP packages also affected? Sure. Provided they are older
than PHP-5.3.12 or older than PHP-5.4.2 *and* you run PHP as CGI, like
with suPHP enabled.

The PHP-5.3.8 you mentioned was built on 26th August 2011, so it's now
two and a half years old. Which is fairly ancient all things considered.

If you run third party PHP packages, then it is a good idea to keep them
updated. Like with a subscription to future PHP PKG releases.

> Can someone help me to find where the attack came from?

The problem is as old as PHP itself, as it was never designed with much
in the way of security. All the security measures that were eventually
added are strapped on or bolted on and a lazy programmer will always
find ways around that if a security feature gets into the way of his
sloppy programming.

As a server operator that needs to provide PHP to end users you're
always walking a tight rope between a sensible and secure server
configuration and the demands of your clients. If you lock PHP down the
way I usually do, you'd get complains because this or that horrible PHP
script of your client then refuses to run. You and I know: The problem
is the script. But the client bitches and in the end you'll just sigh
and reconfigure your PHP settings. That's when the problems start.

There are two very common forms of exploits and hacks:

a.) Brute force login attack eventually allows an attacker to "guess"
the username and password of a client. Which is then typically abused to
send SPAM. In lesser cases it's used to login to the server via FTP (you
don't allow shell access, right?) to upload PHP and/or Perl scripts to
be run out of user space.

b.) PHP, as you reported. A badly programmed script in public webspace
is tricked into doing things that it wasn't supposed to do.

Like including a piece of code that's hosted on an entirely different
server. Which can be prevented with allow_url_fopen and
allow_url_include in php.ini.

Or like downloading a piece of malware to /tmp and executing it with the
UID of the webserver. Which can be prevented server side by not allowing
executables in /tmp via the mount options of this partition (standard on
BlueOnyx if installed off the ISOs).

There are other exploit vectors as well, but the two mentioned above are
the most common ones and they all point back to two cardinal sins:

Relaxed PHP configuration for the Vsite in question and badly programmed
PHP scripts.

ANY PHP script that accepts user submitted input (may that be via POST
or GET transactions) must properly sanitize all input. Never ever pass
user submitted data directly to fopen() or other file and/or database
transactions. Never include something without sanitizing the path. Treat
any user submitted data as if it has the plague and you're out of face
masks and rubber gloves. But that's the problem: A lot of programmers
simply don't care about these things. As long as the script "just works"
security is irrelevant.

Lastly, there are large popular PHP scripts such as Wordpress, Typo 3,
Drupal and what not. They all have their own approach on security. They
all have had a long history of getting installs exploited. They all
release security updates fairly frequently. Due to their widespread
usage base they are also a welcome target for these kinds of attacks.
Because every large fix they publish is a hands on set of instructions
for attackers and tells them what to do to exploit installs that have
failed to install the updates.

So what can you do to protect your server(s) from the most common
attacks and exploits?

- Have good backups.
- Install OS updates as soon as they come out.
- Make sure your third party software is up to date, too.
- Make sure your Wordpress/Typo3/etc. pp. installs are up to date, too

Beyond that, enforce strict security procedures when it comes to Vsites
that have PHP enabled. Such as this:

"Server Management" / "Security" / "PHP Settings":

Register Globals:	Off
Safe Mode:		On
Safe Mode GID:		On

Open Basedir:

/home/
/tmp/
/usr/sausalito/configs/php/
/var/lib/php/session/

Disable Functions:	

system,passthru,shell_exec,proc_open,proc_nice,ini_restore

Allow URL fopen:	Off
Allow URL include:	Off

These last two settings are most important. If they're not set to "Off",
then you'll be in a world of pain.

Lastly: On ALL Vsites that use PHP, enable suPHP. The how's and why's
are explained in great detail on this URL:

http://www.blueonyx.it/index.php?page=suphp

Each Vsite will then have its own php.ini, which allows more fine
tuning. suPHP makes sure that PHP scripts only run as the user who owns
the script(s) and also make sure that PHP scripts cannot access scripts
or files owned by other users.

Should a script get exploited nonetheless, then the ownership of the
files in /tmp (or elsewhere) will have the UID of the web owner of the
Vsite where this exploit happened. Which makes it really easy to track
down the origin of the exploit.

With suPHP enabled, system(), passthru(), shell_exec(), "allow url
fopen" and "allow url include" disabled, you'll already have locked down
PHP fairly well and the exploit-ability of badly designed scripts drops
off quite a bit.

Still: It might be a really good idea to examine the webspace of all
Vsites to see what kind of PHP scripts they use. If you find something
that looks questionable or appears as if a liberal arts student has
hacked it together between breakfast and lunch (like the Obamacare
website), then it might be a good idea to let these files have a little
accident or a preventative "chmod 000" might also do the trick.

-- 
With best regards

Michael Stauber