Guessing PHP version and info from phpinfo using black box analysis

Question

Intro

I'm currently experimenting with PHP black box analysis and couldn't find any useful information. There are some approaches how to determine e.g. Apache version, but for PHP it seems that internet knows only so called "PHP easter eggs". On php.net I found lots of information about PHP errors, deprecated functions and change logs, but was not able to find anywhere anything similar what I'm searching here for (some sort of comprehensive list or tool or paper or at least ideas). So before reinventing the bicycle I'll try my luck here.

We have to accept some limitations, which I listed below. For now I'm accepting also error-based tests (since it is difficult to make any guesses without having PHP error messages enabled), but not on every server are PHP error messages enabled.

We don't have:

• phpinfo()
• PHP easter eggs (since PHP>=5.5.0 deprecated and PHP<5.5.0 rewrite rules might be used or expose_php=off (X-Powered-By disabled))
• no folders, files from known frameworks
• no framework specific cookies, headers or any other parameters
• any access to the source code (only exception: public captcha generators or some PayPal/Xsolla/whatever... or other third party scripts)
• directory listing is off
• if there are PHP bugs, then exposed path doesn't tell us about PHP's version or frameworks, etc
• so-called "google hacking" doesn't help us in farming any additional information in this given example

The server is secure - hey man, it belongs to Chuck Norris - so no solutions that rely on exploiting any vulnerabilities, be it 0days, SQL injections, remote code execution or anything else.

We have:

• the knowledge that PHP is running on the given server
• PHP bugs (display_errors=on) - wrong input types like: foo.php?id[]=1 instead foo.php?id=1, buggy scripts, host/foo.php/foo.php is allowed causing in some obscure edge cases PHP errors (e.g. file upload), etc.
• .php extension may be optional, so foo.php?id=baror just /foo/bar/

What I was able to find so far

Guessing PHP version:

- several built-in PHP functions found by analysing PHP error messages
    → PHP change logs → check if any of exposed functions is deprecated in some PHP versions
- PHP<5.3.X allows strings to contain null bytes \0
    → problems with include(), copy(), ... (but we don't have such vulnerabilities on that server, e.g. only Alphanumeric input and chars: {.,-_} are allowed, special chars will be replaced with '')
- IF PHP<5.3.0: strlen(Array) = 5
- IF PHP>=7.0.0: casting NaN or infinity to integer = always 0, not more undefined and platform-dependent
- .php3: PHP=3.x.x, .php4: PHP=4.x.x. (trivial)

Guessing infos from phpinfo (without having any access to it):

- foo.php?id=99...99 (large number) → IF response contains:
    → "2 147 483 647" → 32bit system (extra whitespaces for better readability)
    → "9 223 372 036 854 775 807" → 64bit system
- max_post_size VS upload_max_filesize
- number of allowed input parameters:
    → p1[]=1&p2[]=1&... (use fake parameters in some parameter checking loop which doesn't expect wrong input type)
    → e.g. error based detection
- float precision: 2.9999999999999999=3 (16 digits) VS 2.999999999999999=2 (15 digits)
- determine "Timeouts", error based

Question

Is there anything else what can be used in more or less general way to determine server's PHP version and guess more information which we usually see in phpinfo() (→ php.ini, and other .ini files).

I heard that it is also possible to measure server response times and to correlate them with used PHP functions or PHP versions, but I don't see any good example for it - PHP scripts might be very complex, so I have no idea how such method should work.

Side note

Let be total overkill and collect all possible known PHP exploits, implement them and just bruteforce the server, by incrementing PHP version's exploit (if exploit for PHP=5.x.x. doesn't work, test another exploit for higher PHP version) (I'm speaking here about pure theoretical possibilities and in context of academic research). Besides all the ethical and legal issues (which we keep in mind here) there are 2 possibilities:

a) Some of the exploits will work (server will be autohacked or DoS-ed by this theoretical exploitation tool, whatever) and we'll be able to determine the right PHP version (mission accomplished).

b) All exploits will fail, which tells us that server has the newest PHP version or exploits can be applied only for some special cases which we just don't have here.

Answer 1

It's easy to conceive of how one would build a taxonomy of identifying characteristics of distinct PHP versions and runtimes- set up a lab, run different frameworks and application types on different versions of PHP, etc, and watch response times, traffic, etc. This process is common, and one can usually substantially automate the discovery of differences. PHP is organic enough that there likely are many version-specific identifying charateristics.

That said, as the post itself says, PHP is not a standalone entity. As a component of a system under analysis, it is necessarily only one small piece- a runtime that lives on top of many distinct OSes, hosts numerous varied and distinct programs, connects to an infinite variety of other systems, etc.

Any specific identified characteristic in the PHP runtime may be confounded in numerous ways by variations in the other necessary parts of the system that PHP cannot do without. The way that a particular version of PHP delivers bytes on the wire may be confounded by the fact that it is running on Windows rather than Linux (and specific versions therein, which themselves have their own fingerprints).

So I would caution against this "PHP black box analysis" activity, absent other context specifically about confounding differences. Any findings are likely to be tainted.

Relatedly, web service black box analysis is of course a thing, and a valuable finding of that process could be- oh, this service looks like it's written in PHP, perhaps version A or maybe version B, using framework W, on OS Blah, for X, Y and Z reason. Overall classification is very valuable.

Component-specific identification attempts, absent the classification of other necessary pieces, is, in my experience, often misguided.