Do you dare to show your PHP easter egg?

What is a “PHP Easter Egg”?

The first mention of this specific “attack vector” was disclosed back in 2004 at the seclists.org webappsec mailing list. It appears that a few of the PHP developers smuggled in hidden URL’s which would show various graphics and credits to the authors of involved in the PHP project.

Example: https://php.net/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
(…more query strings can be found at the end of this article in Appendix #1!)

This feature is still widely in use throughout the internet.

Is it bad?

Rumors have circulated around how bad it really is. Most developers doesn’t know of it’s existence, some see it as a funny feature, some mistakes it as being harmless, while others see it as a potential threat to their IT environment.

I mean, really, all you will obtain is silly images of animals and people with sticks in their mouths.

php-dude

That is hilarious.

Generally speaking, pentesters see it as low hanging fruit which really isn’t of much concern except for another advisory in their reports.

“PHP contains a flaw that may lead to an unauthorized information disclosure.The issue is triggered when a remote attacker makes certain HTTP requests with crafted arguments, which will disclose PHP version and another sensitive information resulting in a loss of confidentiality.“ – Open Source Vulnerability Database (OSVDB-12184)

The catch is, there is no publicly available tool to evaluate how bad and widespread the problem really is.

Let’s analyze!

From what can be found openly on internet, you can abuse the data in various ways. For example, you can map some of the graphics to spans of PHP versions:

php1

By analyzing the image, you can conclude what version is running. If you know the version, you’ll get a good estimate of what vulnerabilities may be hidden within the software – as well as the compatibilities with various modules (which in turn may have a varied flora of bugs on their own).

If we look at public vulnerabilities documented at cve.mitre.org, we can assume the following:

php2

Each link under “CVE Vulnerabilities” goes to a vulnerability related to the PHP versions located at the right.There are of course many more vulnerabilities, the ones listed above is just the tip of the iceberg.

More data!

I’ve made an experiment regarding three different PHP setups running on Ubuntu 12.04, using the following versions: PHP 5.3.10-1ubuntu3.4, PHP 5.3.1 and PHP 5.2.8. They’ve been configured in a similar fashion with the corresponding modules. I’ve extracted the “phpinfo author” easter egg (PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000) from each and every setup, and cross-related the data between the setups.

If we compare PHP 5.3.10-1ubuntu3.4 with PHP 5.3.1 we see the following difference:

In PHP 5.3.10-1ubuntu3.4 the xmlns attribute to the <html> tag has been added, containing the following data: “http://www.w3.org/1999/xhtml”.

PHP v5.3.1

php3

PHP v5.3.10-1ubuntu3.4

php4

The authors under the “Quality Assurance Team” node has been completely changed to the following: Ilia Alshanetsky, Joerg Behrens, Antony Dovgal, Stefan Esser, Moriyoshi Koizumi, Magnus Maatta, Sebastian Nohn, Derick Rethans, Melvyn Sopacua, Jani Taskinen, Pierre-Alain Joye, Dmitry Stogov, Felipe Pena.

PHP v5.3.1

php5

PHP v5.3.10-1ubuntu3.4

php6

What can we use this for?

If you scroll up to the PHP elephant image, you see that the whole documented range is starting from 5.3.0 with no further data.

Now we can conclude the following; if the easter egg’s <html> tag contains an xmlns attribute it is at least 5.3.2.

php7

If you’d like to see further comparsions, see Appendix #2.

If we would have similar fingerprints for PHP v5.3.3, v5.3.4 as well as 5.3.5.
We would be able to conclude whether or not CVE-2011-0754 is present or not through the easter egg entirely.

Further data can of course be mined through php.net’s git repository.

Not to forget, this same technique can be applied to all regular PHP modules, as well as SAPI modules and PHP core modules (SPL for example).

Another funny thing!

This whole issue (or feature) is enabled through the “expose_php” setting in php.ini. What people generally don’t know, is that “expose_php” exposes more data than just enabling the easter egg.

The response header from php.net:

php8

That’s right. It injects another HTTP header to the HTML response for all files served. As you can see, the X-Powered-By header leaks the PHP version entirely. This provides a quicker and often more efficient method of fingerprinting, however, due to it’s simplicity it’s also easier to spoof and tamper with than the static analysis presented above.

God Damnit PHP.

There is a search engine called shodan.io which scours the internet for various servers. Unlike other search engines, this one returns the header response data from servers.

If we query shodan for the following keywords (only focusing on Apache web servers):

php9

…We’ll find 4.657.780 HTTP servers, with expose_php set to “On”.

However, if we toggle the X-Powered-By part of the query around by adding the dash (minus) sign, we can with the following query get a fair estimate of “secure” Apache servers:

php10

…Which results in 2.094.659 HTTP Apache servers, which obviously doesn’t leak PHP in the response headers.

The total amount of servers scanned results in the number: 6.752.439 (4.657.780 + 2.094.659).

If this data were to be accurate (statistics always lie), we’d end up with approximately 69% vulnerable Apache web servers. With that in our minds we can assume that this configuration is a really widespread (and common) problem.

Solution.

The most obvious solution is to toggle the “expose_php” setting to Off in php.ini, restart the web server, and done! However this cannot always be applied when using shared hosting.

If .htaccess directives are allowed (mod_rewrite), create an .htaccess file in your webroot directory, containing the following code:

php11

The snippet above will disable access to all easter egg like URL’s.

If the webserver is running Apache, you may be able to add the following statements to your .htaccess-file to disallow the X-Powered-By leak.

php12

Conclusion (tl;dr).

The PHP Easter Egg can be used as a reliable source for fingerprinting software versions (ranging all from PHP itself, to one of it’s many modules). However, it is fairly easy to disable.

Update 12-04-2017: This feature was removed in PHP 5.5.