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). En el primer caso, si imprime "vulnerable", todavía no estáis parcheados. El segundo test creará un archivo llamado "echo" si no estáis parcheados.
env x='() { :;}; echo vulnerable' bash -c "echo Fallo 1 parcheado"
env X='() { (a)=>\' sh -c "echo date"; cat echo
Más información | CVE 2014-6271 - CVE 2014-7169 (vulnerabilidad 2) | Lcamtuf
Ver 66 comentarios