[VIM] Re: A few more apps vulnerable to PHP XML-RPC exploits (fwd)
jericho at attrition.org
Fri Jul 8 08:41:14 EDT 2005
---------- 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
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
22.214.171.124 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.
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!
More information about the VIM