Tag Archives: RFI

Bogus RFI Reports Getting Out of Hand

I know we’re all getting tired of the Remote File Inclusion (RFI) vulnerabilities being disclosed that end up being debunked, but this one takes the cake so far (yes I’m behind on e-mail).

Fri Jun 16 2006
http://archives.neohapsis.com/archives/bugtraq/2006-06/0321.html
(1) path/action.php, and to files in path/nucleus including (2) media.php, (3) /xmlrpc/server.php, and (4) /xmlrpc/api_metaweblog.inc.php

Sat Jun 17 2006
http://archives.neohapsis.com/archives/bugtraq/2006-06/0447.html
Demonstrated that the vulnerability is bogus.

Mon Oct 30 2006
http://archives.neohapsis.com/archives/bugtraq/2006-10/0486.html
media.php

Mon Oct 30 2006
http://archives.neohapsis.com/archives/bugtraq/2006-10/0501.html
Demonstrated (again) that the vulnerability is bogus.

So not only is it fake, it was also previously disclosed and debunked. I swear, Bugtraq moderators should seriously consider blocking any RFI disclosure from hotmail.com. Would save Vulnerability Databases a lot of time.

[product] (script.php) Remote File Include [exploit|vulnerability]

Somewhere out there is a point-and-click web application that allows neophyte “security researchers” (yes, that is a joke) to quickly whip up their very own Bugtraq or Full-Disclosure post. I’m sure others have noticed this as well? More and more of the disclosures have too much in common, and unfortunately for VDBs, more and more are completely bogus reports. I feel bad for the vendors as much as I feel for those of us trying to track vulnerabilities. Anyway, some of the many things these disclosures have in common:

- Title (example: EasyBannerFree (functions.php) Remote File Include Exploit)
– # Everything is commented as if this is supposed to be a script
– The remote file inclusion is http://shell.txt or SHELLURL.COM
– It has a single line of source code quoted to “validate” the finding (example: rrequire ( $path_to_script.”globals.inc.php”);
– May have 80 lines of perl code to exploit a single http:// line, because it looks cool
– Contains more greets/thanks than vulnerability information
– If their disclosure is proven false, they never seem to reply to explain themselves

Odds are strong they won’t include the vendor or give enough information to find it via extensive searching. Odds are good it will not contain the version supposedly affected and contain typos in the script or variable names. And worst of all, it is a glorified “grep and gripe” disclosure. Meaning, they grep out the ‘require’ line, don’t bother to check any other portion of the code, and assume it is vulnerable. Some will go so far as to say stuff like “ (tested on Version 1.13)” even though it is quickly proven false.

So, “security researchers” disclosing all these remote file inclusion bugs. Test your finds before you publish, no more grep and gripe crap please.

Follow

Get every new post delivered to your Inbox.

Join 5,408 other followers