Nmap Development mailing list archives

Possible Bug - [NSE] PHP version disclosure (OSVDB 12184)


From: Tom Sellers <nmap () fadedcode net>
Date: Mon, 09 Aug 2010 19:20:05 -0500

On 5/29/10 11:24 AM, Gutek wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, here comes a new version.
It now checks both the "special PHP logo" and the "Credits page".
David was right, we have a far better granualrity when using the Credits
as a fingerprint.
However i'm still not quite sure if this Credits page is really
phpinfo() dependant or not, while the logo does not seem to be.

So, the script now checks both: results from the "logo" are now marked
as "gives a range" (let's say, informational), and results from the
Credits are marked "more accurate".

In the end, to help collecting new hashes or to reveal at a glance if a
banner seems really different from the "easteregg fingerprint", the
scripts tries to grab the claimed PHP version from the Header.

During this past week i've scanned hundreds of webservers and so the
fingerprints database has grown and is now more mature. There should
remain only a few unknown signatures but in this case the script will
tell the user what to do.

Here is the new Output :

- ---
- -- @output
- -- PORT   STATE SERVICE
- -- 80/tcp open  http
- -- | php-easteregg: This EasterEgg Matches PHP Versions:
- -- | ('logo' test, gives a range)
- -- | 4.3.11,
- -- | 4.4.0 to 4.4.4,
- -- | 5.0.5-2ubuntu1.1,
- -- | 5.0.5-pl3-gentoo,
- -- | 5.1.0 to 5.1.2
- -- | ('credits' test, more accurate)
- -- | 5.0.5
- -- |_(According to the Header, server claims to be running PHP/5.0.5)

Again, thanks for the advises :)

A.G

Gutek,

        Recently (last week or so) I have noticed that this script has been triggering on every http
and generating hashes.  This occurs even when no real content is returned, such as a 403 (Forbidden)
or 301 (Moved Permanently)

If this behavior is not by design you may wish to check the value of response.status to determine if
the page you requested was returned successfully.  The best bet would be a 200 (ok) response.

Perhaps changing

        if response.body then

to something like

        if response.body and response.status == 200 then


in both of the http.get sections would address this.


I tested this against my own non-php hosts and it removed the false positives.
I tested it against www.php.net and it seemed to work correctly as far as I
can tell.

PORT    STATE  SERVICE REASON
80/tcp  open   http    syn-ack
| http-php-version: Versions from logo query (less accurate): 5.1.4, 5.2.X
| Versions from credits query (more accurate): 5.1.4, 5.2.X, 5.2.12-0.dotdeb.1
|_Version from header x-powered-by: PHP/5.2.12RC4-dev



Thanks much,

Tom






_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: