[VIM] Re: A few more apps vulnerable to PHP XML-RPC exploits (fwd)

[security curmudgeon]

---------- Forwarded message ----------
From: GulfTech Security Research <security at gulftech.org>
To: security curmudgeon <jericho at attrition.org>
Date: Fri, 08 Jul 2005 07:33:55 -0500
Subject: Re: A few more apps vulnerable to PHP XML-RPC exploits

Hi Brian,

I have actually wanted to post this info on my website for some time now, but 
have been too busy, but feel free to share this info as a lot of sources have 
the wrong information.

1) If an application is using the vulnerable phpxmlrpc then it is vulnerable 
regardless of how they implement it really. This is because the vulnerability 
occurs as the incoming data is being parsed by the xmlrpc server. For example, 
exploit code released for the PostNuke or Drupal xmlrpc issues will easily work 
on anything else vulnerable to the issue. I would say the only difference is 
that some applications that are vulnerable did not name the file xmlrpc.php, 
but otherwise it is all the same.

2) XOOPS as far as I know NEVER used any type of the vulnerable phpxmlrpc 
libraries. I did find a vulnerability in their xmlrpc interface, but it was an 
sql injection issue, and not remote code execution.

3) The vulnerabilities I reported in WordPress that prompted the release of 
1.5.1.3 were NOT related to the phpxmlrpc issues, but instead were like the 
XOOPS issues, and just a standard case of highly exploitable SQL Injection. 
However, it has been confirmed by a WordPress team member that people using 
WordPress version earlier than 1.5 ARE vulnerable to the phpxmlrpc 
vulnerability. So, they used to use it but do not use it anymore :)

I hope this helps as even CERT has the wrong info it seems.

Kind Regards,

James


security curmudgeon wrote:

> Hey James,
> 
> I haven't had time to dig into the details of this, but the amount of 
> applications vulnerable due to this flaw is pretty amazing.
> 
> Based on your extensive research, how do you see these vulnerabilities as 
> they relate to each other? Is this truly a single vulnerability affecting 
> many products because they use the same vulnerable code? Or are these 
> slightly different because each product implements the routines differently?
> 
> We're still debating on whether this gets one entry in OSVDB, or gets broken 
> out (like CVE appears to be doing).
> 
> Thanks for any insight!
> 
> Brian
> OSVDB.org
>
>