Web Hosting Talk : Web Hosting Main Forums : Hosting Security and Technology : xmlrpc exploit affects many software packages

[JohnCrowley]

http://news.netcraft.com/archives/20..._exploits.html

It's in the wild now and is affecting a large number of sites. Upgrading these software packages is highly recommended.

- John C.

[papi]

I was just about to start a thread about this when I saw this one. This is a serious issue and it's got little attention on wht and other forums ..

What I would like to know is whether recompiling apache/php (cpanel boxes) would help here at all? I mean is this problem fixable by simply getting a new xmrpc/pearxmlrpc version compiled into php OR is this problem much MUCH worse and each separate installation of affected script that uses the xmlrpc libraries

Either way .. everyone should know, you have dozens of entry points for remote php execution on each of your boxes due to this xmlrpc issue

[JohnCrowley]

Originally posted by papi
I was just about to start a thread about this when I saw this one. This is a serious issue and it's got little attention on wht and other forums ..

What I would like to know is whether recompiling apache/php (cpanel boxes) would help here at all? I mean is this problem fixable by simply getting a new xmrpc/pearxmlrpc version compiled into php OR is this problem much MUCH worse and each separate installation of affected script that uses the xmlrpc libraries

Either way .. everyone should know, you have dozens of entry points for remote php execution on each of your boxes due to this xmlrpc issue

The problem is 3 fold:

1. Upgrade pear xmlprc right away
2. Upgrade phpxmlrpc if you have it installed.
3. All the software listed in the above link has xmlrpc embedded in its files (i.e. not using shared pear library), so the software itself (i.e. wordpress, phpads, etc...) needs to be upgraded to take care of this problem.

- John C.

[papi]

The nature of the flaw poses a dilemma for site operators on shared hosting services, who may run affected applications on their sites but not have the ability to update the server's PHP installation with the secure libraries. Disabling XML-RPC features is the recommended workaround.

That is giving me some hope however ... if that information is correct, then all we (server admins) needs to do is recompile apache/php and make sure when we do that, that the new versions of xmlrpc and pearxmlrpc are used ... So in my case, since I use cpanel I'll have to wait for Cpanel to update their easyapache script

[papi]

Originally posted by JohnCrowley
The problem is 3 fold:
.
3. All the software listed in the above link has xmlrpc embedded in its files (i.e. not using shared pear library), so the software itself (i.e. wordpress, phpads, etc...) needs to be upgraded to take care of this problem.

- John C.

Ok that just plain SUX and I don't know why anyone would even think that can be done.

I've scanned our servers, and have detected more than a hundred different installations of scripts that use xmlrpc such as postnuke, wordpress etc.

There is no way on earth to get every single one of these people to update every single one of their scripts. And no I am not being lazy, just realistic.

Is there any way to stop attacks on these vulnerable scripts through mod_security ??

[papi]

It's quite amazing how no one seems to give a **** because on the surface this looks harmless ...

Guess what? IT'S NOT!

The vulnerability in xmlrpc and the dozens of different scripts that use it allows REMOTE PHP EXECUTION ie. anyone can execute php commands from remote incl. script kiddies which no doubt will root thousands of boxes thanks to this one.

[darksoul]

Originally posted by papi
It's quite amazing how no one seems to give a **** because on the surface this looks harmless ...

Guess what? IT'S NOT!

The vulnerability in xmlrpc and the dozens of different scripts that use it allows REMOTE PHP EXECUTION ie. anyone can execute php commands from remote incl. script kiddies which no doubt will root thousands of boxes thanks to this one.

People give a ******* but everyone is busy fixing it

[papi]

how exactly ya fixin' it? Has anyone come up with a viable solution for shared hosting servers (ie. with dozens of affected scripts on each box)

[comafish]

Originally posted by papi
how exactly ya fixin' it? Has anyone come up with a viable solution for shared hosting servers (ie. with dozens of affected scripts on each box)

I second this request

[darksoul]

The first thing we did was pushing

SecFilter "xmlrpc.php"

into our mod_security configs.
This generated no problems so far.
Next step is updating php and resolving the problems
that might arise from the first step.
Keep in mind... if you're using a control panel
you'll have to update the autoinstallers like fantastico as well
so that new scripts get installed with the patched version.
(This when fantastico and the other auto install systems will
update their versions)

[hostito]

Cpanel thread on same subject here:

http://forums.cpanel.net/showthread....&highlight=XML

[McRox]

Originally posted by papi
The vulnerability in xmlrpc and the dozens of different scripts that use it allows REMOTE PHP EXECUTION ie. anyone can execute php commands from remote incl. script kiddies which no doubt will root thousands of boxes thanks to this one.

YOUR customers can also execute php, do you trust any customer?

Security is more than keeping your customer's scripts up-to-date..

Anyway, there are 2 exploits:

1) XMLRPC for PEAR
2) XMLRPC for PHP

Solution:

1) Run the following commands:
pear upgrade XML_RPC

If it's updated, your version should be 1.3.1:

root@mcrox [/]# pear list | grep RPC
XML_RPC 1.3.1 stable

2) Upgrade your PHP to version 4.4.0RC2 OR disable XMLRPC by recompiling php without it.

Please note that XMLRPC is needed for Horde and many other customer's scripts, so choose..

You could also add the following rule to mod_security:

SecFilter "xmlrpc.php"

like what darksoul suggested, but it wont stop 100% of the exploits..

A better one is:

SecFilter "xmlrpc"
SecFilter "xml_rpc"

OR

SecFilter "xml_rpc"

[papi]

Re the modsec filters ... while I'm sure those will stop MOST attacks, the xmlrpc files could be called anything eg. elephant.php and contain the same code

[darksoul]

Originally posted by papi
Re the modsec filters ... while I'm sure those will stop MOST attacks, the xmlrpc files could be called anything eg. elephant.php and contain the same code

Right, but in a real world scenario I doubt your customers modifyed the name of those files.
Plus if they did, the attacker wouldn't know.
What we're trying to protect against here is worms that will most
likely follow a pattern.
Sure, this is a first step and you shouldn't consider it like a fix it all solution.
There are other steps some of which were highlighted here,
that need to be taken in order to completely secure the environment against this bug.

[papi]

Originally posted by darksoul
Right, but in a real world scenario I doubt your customers modifyed the name of those files.
Plus if they did, the attacker wouldn't know.
What we're trying to protect against here is worms that will most
likely follow a pattern.

Good point

Sure, this is a first step and you shouldn't consider it like a fix it all solution.
There are other steps some of which were highlighted here,
that need to be taken in order to completely secure the environment against this bug.

Anything apart from updating pear XMLRPC and the php module (which i didn't have installed on any of our servers ..luckily) ??