Introduzione
Attualmente sto sperimentando l'analisi della scatola nera PHP e non sono riuscito a trovare alcuna informazione utile. Ci sono alcuni approcci su come determinare, ad es. La versione di Apache, ma per PHP sembra che internet conosca solo le cosiddette "uova di Pasqua PHP". Su php.net ho trovato molte informazioni sugli errori PHP, sulle funzioni deprecate e sui log delle modifiche, ma non sono stato in grado di trovare qualcosa di simile a ciò che ho Sto cercando qui (una sorta di elenco completo o strumento o carta o almeno idee). Quindi, prima di reinventare la bicicletta, tenterò la fortuna qui.
Dobbiamo accettare alcune limitazioni, che ho elencato di seguito. Per ora accetto anche i test basati su errori (dal momento che è difficile fare ipotesi senza che siano abilitati i messaggi di errore PHP), ma non su ogni server sono abilitati i messaggi di errore PHP.
Non abbiamo:
-
phpinfo() - PHP easter eggs (dato che PHP > = 5.5.0 deprecato e PHP < 5.5.0 possono essere usate regole di riscrittura o
expose_php=off(X-Powered-Bydisabilitato)) - nessuna cartella, file da framework noti
- nessun cookie, intestazione o altri parametri specifici del framework
- qualsiasi accesso al codice sorgente (unica eccezione: generatori di captcha pubblici o alcuni PayPal / Xsolla / qualunque ... o altri script di terze parti) L'elenco di directory
- è disattivato
- se ci sono bug PHP, il percorso esposto non ci dice sulla versione o sui framework di PHP, ecc.
- il cosiddetto "google hacking" non ci aiuta a coltivare alcuna informazione aggiuntiva in questo esempio
Il server è sicuro - hey man, appartiene a Chuck Norris - quindi nessuna soluzione che si basa sullo sfruttamento di eventuali vulnerabilità, che si tratti di 0 giorni, iniezioni SQL, esecuzione di codice in modalità remota o altro.
Abbiamo:
- la consapevolezza che PHP è in esecuzione sul server specificato
- Bug di PHP (
display_errors=on) - tipi di input errati come:foo.php?id[]=1invecefoo.php?id=1, script buggy,host/foo.php/foo.phpè permesso causando in alcuni casi oscuri casi di errori PHP (es. upload di file), ecc.
L'estensione - .php può essere facoltativa, quindi
foo.php?id=baro solo/foo/bar/
Ciò che sono riuscito a trovare fino ad ora
Indovina la versione di 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)
Indovinare le informazioni da phpinfo (senza averne accesso):
- 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)
Domanda
C'è qualcos'altro che può essere usato in modo più o meno generico per determinare la versione PHP del server e indovinare più informazioni che di solito vediamo in phpinfo () (→ php.ini e altri file .ini).
Ho sentito che è anche possibile misurare i tempi di risposta del server e correlarli con le funzioni PHP o le versioni PHP utilizzate, ma non ne vedo alcun esempio: gli script PHP potrebbero essere molto complessi, quindi non ho idea di come dovrebbe funzionare tale metodo.
Nota a margine
Lascia che sia un overkill totale e raccolga tutti i possibili exploit PHP conosciuti, li implementa e bruteforce il server, incrementando l'exploit della versione di PHP (se exploit per PHP = 5.xx non funziona, prova un altro exploit per una versione PHP più alta) (Parlo qui delle pure possibilità teoriche e nel contesto della ricerca accademica). Oltre a tutti i problemi etici e legali (che teniamo presente qui) ci sono 2 possibilità:
a) Alcuni degli exploit funzioneranno (il server sarà autohacked o DoS-edito da questo strumento di sfruttamento teorico, qualunque sia) e saremo in grado di determinare la versione corretta di PHP (missione compiuta ).
b) Tutti gli exploit falliranno, il che ci dice che il server ha la versione più recente di PHP o che gli exploit possono essere applicati solo per alcuni casi speciali che non abbiamo qui.