2

When am executing the scanning on security metrics for PCI Compliance, I am getting this following error message. Does anyone know how to resolve this?

*Title: vulnerable web program (phpRPC) Impact: A remote attacker could execute arbitrary commands, create or overwrite files, or view files or directories on the web server.

Data Sent: POST /ie/modules/phpRPC/server.php HTTP/1.0

Host: example.com

Content-type: text/xml Content-Length:162 <?xml version="1.0"?> <methodCall> <methodName>test.method</methodName> <params> <param> <value><base64>'));system(id);exit; </param> </params> </methodCall>

Data Received: ????<img height="1" width="1" style="border- style:none;" alt="" src="//googleads.g.doubleclick.net/p agead/viewthroughconversion/997970389/?value=0&amp;label=PlcJCKu92AQ Q1aPv2wM&amp;guid=ON&amp;script=0"/>

Resolution: 03/09/06 CVE 2006-1032 phpRPC is an xmlrpc library that uses database and rpc-protocol abstraction. It is prone to a remote code execution vulnerability because the decode() function within the rpc_decoder.php script fails to adequately sanitize user-supplied input before processing it in an eval() call.
Successful exploitation would result in arbitrary code execution in the context of the application. PHP scripts that implement the phpRPC library, such as RunCMS, are affected by this issue. RunCMS 1.1 through 1.3.a5 are affected, as is phpRPC up to 0.7.

Resolution: phpRPC is not currently being maintained. RunCMS users should upgrade to a version higher than 1.3.a5 which will hopefully include a fix.

Risk Factor: High/ CVSS2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) CVE: CVE-2006-1032 BID: 16833 [Less]*
Taylan Aydinli
  • 4,333
  • 15
  • 39
  • 33
joby john
  • 21
  • 4
  • You should sanitize URLs and other sensitive information before posting to the internet. I recommend you change domains, etc from the example, unless you already have. – Freedom_Ben Mar 23 '13 at 21:02

2 Answers2

6

This is a relatively old question now, but I believe this is the answer, as I had exactly the same problem.

Security Metrics are effectively trying to call the linux command of id which would return something like this uid=1000(rob) gid=1000(rob) groups=...

My theory is that Security Metrics are checking the response for the string uid= to see if the code has been executed on the remote server. This will coincidentally match Google's Remarketing tag. Eg. in your question the uid= part of: src="//googleads.g.doubleclick.net/p agead/viewthroughconversion/997970389/?value=0&amp;label=PlcJCKu92AQ Q1aPv2wM&amp;guid=ON&amp;script=0"

My solution was to remove the Google Remarketing tag completely on our 404 pages, not just comment it out with a JS or HTML comment. As it was the 404 page being returned for the url that they were posting to (/scripts/modules/phpRPC/server.php) to try and find the exploit.

I hope this helps you, or anyone else coming across this question.

Thanks,

Rob

Rob Holmes
  • 3,768
  • 1
  • 16
  • 19
  • It happens on every page the remarketing tag is on, not just the 404 pages. They attempted to make the same call to a non 404 page now and the scan picked that up now instead. After speaking to Security Metrics I have had to file a false positive request to them to override this penetration test. Am awaiting their response. Failing that a redirect to the 404 page without the tag on for URL's that look like /modules/phpRPC/server.php with a regular expression might do the job... – Ashley Swatton Sep 18 '13 at 19:27
  • 1
    Nice find. This is also true for the Cloudflare session cookie. It returns `__cfuid=[random session hash]` which triggers scans/audits (like Controlscan) to flag the server as vulnerable via phpRPC channels. It seems that the regex/logic of the scan vendors is operating from a simplistic angle....they should be looking for string matching the facets of what really outputs via the `# id` command instead of just any ol `uid=` returned anywhere in the assets. – dhaupin Aug 14 '15 at 17:09
0

This is a relatively serious problem, because an RPC service on your server my be available for use by attackers. Without knowing the specifics of your system, I can't recommend specific fixes. However, the vulnerability you are seeing is most likely caused by an outdated system. You should upgrade and install all patches. If your platform has been EOLed, move to something newer. The Common Vulnerability Enumeration has some specific information about the vulnerability identified by your scanner that may help you.

Freedom_Ben
  • 11,247
  • 10
  • 69
  • 89
  • We are using Windows 2008 server. The project is on the ASP .Net 4.0 with SQL Server as 2008 R2 as back end. We are not using any php server or anything like that. Is it related to any google ads? We have their js code on some pages. I tried to run the test by commenting those lines. Still this error is comming. – joby john Mar 23 '13 at 21:19
  • That is really strange to see this error when you're not running PHP. I suppose it is possible that a site you're linking to (possible through JS) could be vulnerable, but I would have expected the error to go away then once you commented out that code. It doesn't make a lot of sense (I'm sure you are banging your head against the wall). What scanner are you using? Nessus, Retina, etc.? – Freedom_Ben Mar 23 '13 at 21:38
  • the test is executed by security metrics – joby john Mar 23 '13 at 21:42
  • Oh interesting. I have a friend who used to do penetration testing for them. I'll shoot him an email but I don't know if he'll have any ideas. I'm sorry I can't help more, other than to say that they usually have customer service that you could maybe call for help. – Freedom_Ben Mar 23 '13 at 21:44
  • 1
    Thank you very much Ben, I much appreciate your efforts to help me. – joby john Mar 23 '13 at 21:48
  • @Freedom_Ben This has nothing to do with RPC the network service. XML-RPC is completely different. In any case (joby john), try POSTing to this URL with, e.g. curl - "curl -d blah http://yourserver/ie/modules/phpRPC/server.php" and see what comes back. Web scanners are often mistaken. Perhaps your server misbehaves by returning HTTP OK to non-existent URL requests. Or perhaps you need to find a different scanner. – Vitaly Osipov Mar 25 '13 at 00:21