Intro
Actualmente estoy experimentando con el análisis de caja negra de PHP y no pude encontrar ninguna información útil. Hay algunos enfoques de cómo determinar, por ejemplo. Versión de Apache, pero para PHP parece que Internet conoce solo los llamados "huevos de Pascua de PHP". En php.net encontré mucha información sobre errores de PHP, funciones obsoletas y registros de cambios, pero no pude encontrar nada similar a lo que yo ' m buscando aquí (algún tipo de lista completa o herramienta o papel o al menos ideas). Entonces, antes de reinventar la bicicleta, probaré mi suerte aquí.
Tenemos que aceptar algunas limitaciones, que enumeré a continuación. Por ahora, también estoy aceptando pruebas basadas en errores (ya que es difícil hacer conjeturas sin tener habilitados los mensajes de error de PHP), pero no en todos los servidores están habilitados los mensajes de error de PHP.
No tenemos:
-
phpinfo() - Huevos de Pascua de PHP (ya que PHP > = 5.5.0 está en desuso y las reglas de reescritura de PHP < 5.5.0 podrían usarse o
expose_php=off(X-Powered-Bydisabled)) - no hay carpetas, archivos de marcos conocidos
- no hay cookies, encabezados o cualquier otro parámetro específico del marco
- cualquier acceso al código fuente (única excepción: generadores públicos de captcha o algunos PayPal / Xsolla / lo que sea ... u otros scripts de terceros)
- la lista de directorios está desactivada
- si hay errores de PHP, la ruta expuesta no nos informa sobre la versión o los marcos de PHP, etc.
- el llamado "pirateo de google" no nos ayuda a cultivar información adicional en este ejemplo dado
El servidor es seguro, hey man, pertenece a Chuck Norris, por lo que no hay soluciones que se basen en la explotación de vulnerabilidades, ya sean días, inyecciones de SQL, ejecución remota de código o cualquier otra cosa.
Tenemos:
- el conocimiento de que PHP se está ejecutando en el servidor dado
- Errores de PHP (
display_errors=on): tipos de entrada incorrectos como:foo.php?id[]=1en lugar defoo.php?id=1, scripts con errores,host/foo.php/foo.phpestán permitidos, lo que provoca errores de PHP en algunos casos de borde (por ejemplo, carga de archivos), etc. - la extensión .php puede ser opcional, por lo que
foo.php?id=baro simplemente/foo/bar/
Lo que pude encontrar hasta ahora
Adivinando la versión de PHP:
- 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 - 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
→ 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)
Adivinando información de phpinfo (sin tener acceso a ella):
- 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 - 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
→ 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)
Pregunta
¿Hay algo más que pueda usarse de manera más o menos general para determinar la versión PHP del servidor y adivinar más información que usualmente vemos en phpinfo () (→ php.ini, y otros archivos .ini).
He oído que también es posible medir los tiempos de respuesta del servidor y correlacionarlos con las funciones de PHP o las versiones de PHP usadas, pero no veo ningún buen ejemplo para ello. Los scripts de PHP pueden ser muy complejos, por lo que no tengo idea de cómo debería funcionar este método.
Nota al margen
Dejemos de ser excesivo y recopilemos todas las posibles vulnerabilidades conocidas de PHP, implementémoslas y simplemente apliquemos la fuerza bruta al servidor, incrementando la vulnerabilidad de la versión de PHP (si la vulnerabilidad para PHP = 5.xx no funciona, pruebe otra vulnerabilidad para una versión de PHP superior) (Estoy hablando aquí de posibilidades teóricas puras y en el contexto de la investigación académica). Además de todas las cuestiones éticas y legales (que tenemos en cuenta aquí), hay 2 posibilidades:
a) Algunas de las vulnerabilidades funcionarán (el servidor será hackeado automáticamente o DoS-ed por esta herramienta de explotación teórica, lo que sea) y podremos determinar la versión de PHP correcta (misión cumplida ).
b) Todas las vulnerabilidades fallarán, lo que nos dice que el servidor tiene la versión más reciente de PHP o que las vulnerabilidades se pueden aplicar solo para algunos casos especiales que simplemente no tenemos aquí.