Si alguna vez habéis trabajado con OS X o Linux, seguro que conocéis bash. Es la terminal por defecto de estos sistemas, donde ponemos los comandos que queremos ejecutar. Es el espacio de trabajo, el equivalente al escritorio cuando usamos el ratón.
Como podréis imaginar, bash es omnipresente y no lo usamos sólo los usuarios sino también muchos programas para ejecutar algunos comandos. Por ejemplo, hay páginas web que internamente llaman a bash para generar algunas páginas (CGI), servidores (y ordenadores) que usan DHCP para obtener sus direcciones IP al conectarse a Internet, y muchas más cosas. Imaginaos qué divertido sería que hubiese un fallo en bash. O mejor aún, no os lo imaginéis: está pasando. De hecho, hasta tiene nombre y todo: Shellshock.
El problema: ejecutando código cuando no toca
Para funcionar, los programas necesitan datos. Supongamos un servidor de Internet que llama a un script de bash para generar una página web. Este script necesitará datos, como las cookies, la ruta de la página que se pide o la cadena que identifica al navegador (user-agent). La forma de pasar estos datos a bash son las llamadas variables de entorno.
La analogía sería que tu ordenador es una habitación. Tú, el servidor, recibes una petición de un usuario y escribes algunos datos sobre esa petición en una pizarra. Luego llamas a bash para que pase a la habitación y haga lo que tiene que hacer. Y una de las primeras cosas que hará será leer de la pizarra los datos que le has dejado (las variables de entorno).
Normalmente, esto funciona bien. La shell (bash) llega, lee los datos, ejecuta sólo lo que tiene que ejecutar y listos. El problema es que a veces, con una cadena especialmente preparada, no sólo lee los datos sino que los ejecuta. Más concretamente, bash ejecuta los comandos que encuentre después de la definición de una función en una variable de entorno. Algo como esto
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
debería definir una función llamada x que no hace nada (el cuerpo de la función es lo que está entre llaves {}). La cuestión es que después bash sigue leyendo y ya no sólo se limita a leer valores sino a ejecutar el código que viene, en este caso echo vulnerable, que imprime "vulnerable" por pantalla.
¿Cómo se puede explotar el fallo?
Bien, ya sabemos cuál es el fallo. Ahora bien, ¿para qué sirve? ¿Cómo se puede alguien aprovechar de ello?
Decíamos al principio que bash está presente en prácticamente todos los ordenadores, y muchos lo tienen expuesto de alguna forma u otra. El ejemplo más llamativo es el de los servidores que generan páginas con bash. En esos casos, simplemente con crear una petición en la que el identificador de navegador (user agent) sea algo como () { :; }; micomandoaquí, podríamos ejecutar comandos arbitrarios en esos servidores. Y con comandos arbitrarios quiero decir que se puede usar la vulnerabilidad para cualquier cosa, desde tumbar todos los servidores vulnerables en un momento hasta montar una enorme botnet, pasando por supuesto por montar ataques de denegación de servicio haciendo que todos los vulnerables envíen tráfico a un cierto objetivo.
El fallo puede permitir a atacantes tomar fácilmente el control de servidores web que usen CGI
Ese es el principal punto de explotación del fallo, y es grave porque es muy fácil de aprovechar. Para que os hagáis una idea, en apenas unas horas y con una búsqueda automatizada muy ingenua, en Errata Sec han encontrado más de 3000 servidores vulnerables. Perfeccionando un poco esa búsqueda y con más capacidad de escaneo, un atacante se podría hacer con muchos sistemas. De hecho, esos ataques ya están en marcha.
Pero no son sólo esos servidores que ejecutan scripts de bash. En Redhat explican que DHCP (el protocolo para que un ordenador obtenga su dirección IP y más instrucciones para conectarse a Internet cuando entra en una red) podría ser otro punto de ataque, ya que permite que el servidor pase variables de entorno que serían interpretadas por el cliente.
En ese caso, sería posible que un servidor de DHCP vulnerable pudiese atacar además a todos los dispositivos que se conecten a su red. Imaginaos qué desastre en grandes empresas.
También es posible que otros servicios, como servidores que ofrecen shells restringidas a sus usuarios (algunos servidores de Git, por ejemplo), puedan ser vulnerables: este fallo permitiría a un atacante saltarse esas restricciones y obtener acceso completo. Además, teniendo en cuenta que bash está presente por todas partes y que muchos programas lo usan incluso sin darse cuenta, podríamos ver todavía más vectores de ataque.
¿Soy vulnerable? ¿Cómo puedo protegerme?
Empecemos diciendo que si no gestionas ningún servidor expuesto a Internet no deberías preocuparte, probablemente. Los sistemas afectados son los que tienen bash, así que estamos hablando de sistemas Linux, OS X y demás derivados UNIX (BSD, Solaris...).
El parche final todavía no está listo
La mayoría de distribuciones Linux ya han distribuido un primer parche, aunque está incompleto y no acaba de corregir del todo la vulnerabilidad. Imaginamos que en cuanto los desarrolladores de bash saquen el parche definitivo lo distribuirán a todos los usuarios. Mientras, una opción puede ser desactivar bash y usar otra shell hasta que esté cien por cien parcheado (nota: hacedlo sólo si sabéis lo que estáis haciendo).
Los que están un poco más expuestos son los usuarios de Apple. Los de Cupertino, con su rapidez habitual en temas de seguridad, todavía no han dado ninguna respuesta. Por suerte, estos ordenadores suelen estar menos abiertos a Internet, y en última instancia ya hay instrucciones para parchear su instalación.
Si queréis comprobar si vuestro sistema está afectado, podéis ejecutar estos dos comandos (el primero para el fallo original, el segundo para el parche incompleto). Si alguno de los dos imprime "vulnerable" por pantalla, es que vuestra versión de bash es susceptible a esos ataques.
env x='() { :;}; echo vulnerable' bash -c "echo Fallo 1 parcheado"
env X='() { (a)=>\' sh -c "echo vulnerable"; bash -c "echo Fallo 2 sin parchear"
Más información | CVE 2014-6271 - CVE 2014-7169 (vulnerabilidad 2)
