¿Recuerdas Heartbleed? Si te crees el bombo y platillo de hoy, Shellshock está en esa liga y con un nombre igual de cojonudo aunque desprovisto de un logo chulo (alguien en el departamento de marketing de estas vulneraciones tiene que ponerse a ello). Pero con toda seriedad, tiene el potencial de ser un gran problema y como hice con Heartbleed, quería reunir algo definitivo tanto para mí como para otros para diseccionar el bombo del verdadero riesgo subyacente.
Para establecer la escena, permítanme compartir algunos contenidos de la entrada del blog de Robert Graham que ha estado haciendo un excelente análisis sobre esto. Imagina una petición HTTP como esta:
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Que, cuando se emite contra un rango de direcciones IP vulnerables, da como resultado esto:
Por decirlo de forma sucinta, Robert acaba de orquestar un grupo de máquinas externas para que le hagan ping simplemente emitiendo una petición cuidadosamente elaborada a través de la web. Lo que es realmente preocupante es que ha hecho que estas máquinas emitan un comando arbitrario (aunque sea un ping bastante benigno) y eso abre todo un mundo de posibilidades muy serias. Permítanme explicarlo.
¿Qué es Bash y por qué lo necesitamos?
Salte esto si es una noticia vieja, pero el contexto es importante para aquellos que no están familiarizados con Bash, así que establezcamos una comprensión básica. Bash es un shell *nix o, en otras palabras, un intérprete que permite orquestar comandos en sistemas Unix y Linux, normalmente conectándose a través de SSH o Telnet. También puede operar como un parser para scripts CGI en un servidor web como el que típicamente veríamos corriendo en Apache. Lleva existiendo desde finales de los años 80, donde evolucionó a partir de implementaciones de shell anteriores (el nombre deriva del shell Bourne) y es enormemente popular. Hay otros shells para las variantes de Unix, pero el problema de Bash es que es el shell por defecto para Linux y Mac OS X, que obviamente son sistemas operativos muy extendidos. Este es uno de los principales factores por los que este riesgo es tan importante – la ubicuidad de Bash – y se describe como «una de las utilidades más instaladas en cualquier sistema Linux».
Puedes tener una idea de la huella de Bash cuando miras las últimas estadísticas de servidores web de Netcraft:
Cuando la mitad de la red está ejecutando Apache (que normalmente se encuentra en Linux), eso es un tamaño significativo de un pastel muy, muy grande. Ese mismo artículo de Netcraft informa de que acabamos de superar la marca de los mil millones de sitios web y, aunque un montón de ellos comparten los mismos hosts, eso sigue siendo un montón de instalaciones de Bash. Oh – eso es sólo servidores web también, no se olvide que hay un montón de otros servidores que ejecutan Linux y volveremos a otros dispositivos con Bash un poco más tarde también.
Bash se puede utilizar para una amplia gama de funciones administrativas típicas, todo, desde la configuración de sitios web a través de controlar el software integrado en un dispositivo como una cámara web. Naturalmente, esta funcionalidad no está pensada para ser abierta al mundo y, en teoría, estamos hablando de usuarios autentificados que ejecutan comandos que han sido autorizados a ejecutar. En teoría.
¿Cuál es el fallo?
Déjame empezar con el CVE de la base de datos de vulnerabilidades del NIST porque da una buena idea de la gravedad (el subrayado es mío):
GNU Bash a través de 4.3 procesa cadenas de arrastre después de las definiciones de funciones en los valores de las variables de entorno, lo que permite a los atacantes remotos ejecutar código arbitrario a través de un entorno manipulado, como lo demuestran los vectores que implican la función ForceCommand en OpenSSH sshd, los módulos mod_cgi y mod_cgid en el servidor HTTP Apache, los scripts ejecutados por clientes DHCP no especificados y otras situaciones en las que la configuración del entorno se produce a través de un límite de privilegios de la ejecución de Bash.
Lo califican con un «10 sobre 10» en cuanto a gravedad o, en otras palabras, tan malo como puede ser. A esto se suma el hecho de que es fácil ejecutar el ataque (la complejidad de acceso es baja) y, quizás lo más significativo, no se requiere autenticación cuando se explota Bash a través de scripts CGI. El resumen anterior es un poco enrevesado, así que vamos a reducirlo a la mecánica del fallo.
El riesgo se centra en la capacidad de definir arbitrariamente variables de entorno dentro de un shell Bash que especifican una definición de función. El problema comienza cuando Bash continúa procesando los comandos de la shell después de la definición de la función, lo que resulta en lo que clasificaríamos como un «ataque de inyección de código». Volvamos al ejemplo de Robert y tomemos esta línea:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
La definición de la función es () { :; }; y el comando del shell es la sentencia ping y los parámetros subsiguientes. Cuando esto se procesa dentro del contexto de un shell Bash, se ejecuta el comando arbitrario. En un contexto web, esto significaría a través de un mecanismo como un script CGI y tampoco necesariamente como una cabecera de petición. Merece la pena leer el aviso de seclists.org en el que se entra en más detalles, incluyendo la afirmación de que la ruta y la cadena de consulta podrían ser vectores potenciales para el ataque.
Por supuesto, una forma de mitigar este vector de ataque en particular es simplemente desactivar cualquier funcionalidad CGI que haga llamadas a un shell y, de hecho, algunos lo recomiendan. En muchos casos, sin embargo, eso va a ser un cambio muy importante y, como mínimo, uno que va a requerir algunas pruebas extensas para asegurarse de que no causa problemas inmediatos en el sitio web, que en muchos casos, lo hará.
La prueba HTTP anterior es una simple pero efectiva, aunque sólo una implementación sobre un protocolo común. Una vez que empiezas a lanzar en Telnet y SSH y aparentemente incluso DHCP, el alcance aumenta dramáticamente por lo que de ninguna manera estamos hablando sólo de explotar los servidores de aplicaciones web aquí. (Aparentemente el riesgo sólo está presente en SSH post-auth, pero en una etapa tan temprana de la divulgación pública inevitablemente veremos otros vectores de ataque emerger todavía.)
Lo que también hay que recordar es que el alcance del daño potencial se extiende mucho más allá de hacer ping a una dirección arbitraria como en el ejemplo de Robert, que es simplemente una pequeña prueba aseada que podría orquestar una máquina para emitir un comando shell. La pregunta es la siguiente: ¿Qué daño podría hacer un atacante cuando puede ejecutar un comando shell de su elección en cualquier máquina vulnerable?
¿Cuáles son las ramificaciones potenciales?
El potencial es enorme – «conseguir shell» en una caja siempre ha sido una victoria importante para un atacante debido al control que les ofrece sobre el entorno de destino. Acceso a datos internos, reconfiguración de entornos, publicación de su propio código malicioso, etc. Es casi ilimitado y además es fácilmente automatizable. Hay muchos, muchos ejemplos de exploits por ahí que podrían ser fácilmente disparados contra un gran volumen de máquinas.
Desgraciadamente, cuando se trata de la ejecución de código arbitrario en un shell en hasta la mitad de los sitios web en Internet, el potencial es bastante amplio. Una de las obvias (y particularmente desagradable) es el volcado de archivos internos para su recuperación pública. Los archivos de contraseñas y los archivos de configuración con credenciales son los más obvios, pero podrían extenderse a cualquier otro archivo del sistema.
De igual manera, el mismo enfoque podría aplicarse para escribir archivos en el sistema. Este es potencialmente el vector de desfiguración de sitios web más fácil que hemos visto, por no hablar de una forma muy sencilla de distribuir malware
Oh, qué tal esto: una palabra que sigo viendo mucho es «gusano»:
Cuando hablamos de gusano en un contexto de computación maliciosa, estamos hablando de un ataque de auto-replicación donde un actor malicioso crea un código que es capaz de propagarse a través de objetivos. Por ejemplo, vimos una implementación muy efectiva de esto con el Gusano XSS de MySpace de Samy, donde un JavaScript cuidadosamente elaborado logró «infectar» un millón de páginas de víctimas en menos de un día.
La preocupación con Shellshock es que un ataque de esta naturaleza podría replicarse a un ritmo alarmante, particularmente al principio mientras la mayoría de las máquinas siguen en riesgo. En teoría, esto podría tomar la forma de una máquina infectada que busca otros objetivos y propaga el ataque a ellos. Esto no se limitaría en absoluto a las máquinas de cara al público; si se consigue detrás del cortafuegos corporativo, el cielo es el límite.
La gente está trabajando en explotar esto ahora mismo. Esto es lo que hace que estos primeros días sean tan interesantes, ya que la carrera armamentística entre los que se apresuran a parchear y los que se apresuran a atacar se calienta.
¿Qué versiones de Bash están afectadas?
Los titulares dicen que todo hasta la 4.3 o, en otras palabras, unos 25 años de versiones de Bash. Dado que todo el mundo sigue comparando esto con Heartbleed, considere que las versiones afectadas de OpenSSL abarcaron apenas dos años, lo cual es una gota en el océano comparado con Shellshock. Sí, la gente actualiza sus versiones, pero no lo hacen de manera consistente y de cualquier manera, la amplitud de las máquinas en riesgo va a ser significativamente mayor con Shellshock de lo que era con Heartbleed.
Pero el riesgo bien puede extenderse más allá de 4.3 también. Ya estamos viendo informes de parches que no son del todo efectivos y, dada la velocidad con la que se están desplegando, no es tan sorprendente. Este es el tipo de cosas que los afectados quieren vigilar muy de cerca, no sólo «parchear y olvidar».
¿Cuándo nos enteramos por primera vez y cuánto tiempo hemos estado en riesgo?
La primera mención que he encontrado en las ondas públicas fue este resumen muy breve en seclists.org que funciona alrededor de las 14:00 GMT del miércoles (alrededor de la medianoche de hoy para aquellos de nosotros en el extremo oriental de Australia). El detalle llegó en el aviso que mencioné antes una hora más tarde, así que se acerca a la media tarde del miércoles en Europa o a la mañana en los Estados Unidos. Todavía es una noticia muy reciente con toda la especulación habitual de la prensa y las predicciones de Chicken Little; es demasiado pronto para observar cualquier explotación generalizada en la naturaleza, pero eso también podría llegar muy pronto si el riesgo está a la altura de su potencial.
Regresa más allá de lo que se ha revelado públicamente y el fallo fue aparentemente descubierto la semana pasada por Stéphane Chazelas, un tipo «especialista en Unix/Linux, redes y telecomunicaciones» en el Reino Unido. Dicho esto, en el post de Akamai sobre el fallo, hablan de que ha estado presente durante «un largo periodo de tiempo» y, por supuesto, las versiones vulnerables de Bash se remontan a hace dos décadas y media. La pregunta, al igual que con Heartbleed, será si los actores maliciosos eran conscientes de esto antes de ahora y, de hecho, si estaban explotándolo activamente.
¿Están nuestras «cosas» afectadas?
Aquí es donde se pone interesante – tenemos un montón de «cosas» que potencialmente ejecutan Bash. Por supuesto, cuando utilizo este término me refiero a la «Internet de las cosas» (IoT), que es la creciente prevalencia de la introducción de una dirección IP y un adaptador inalámbrico en todo, desde los cubiertos hasta las cerraduras de las puertas y los globos de luz.
Muchos dispositivos IoT ejecutan distribuciones de Linux integradas con Bash. Estos mismos dispositivos ya han mostrado serias vulnerabilidades de seguridad en otras áreas, por ejemplo, hace un par de meses se descubrió que los globos de luz LIFX filtraban las credenciales del wifi. Aunque no es una vulnerabilidad de Bash como Shellshock, nos muestra que al conectar nuestras cosas estamos entrando en un nuevo mundo de vulnerabilidades en lugares que nunca estuvieron en riesgo antes.
Edición: Algunas personas se han referido a la prevalencia de BusyBox ejecutando el shell Ash en los dispositivos móviles. Los dispositivos que lo ejecutan no parecen estar en riesgo de Shellshock. La dificultad para un consumidor es que no sabe lo que está ejecutando en sus dispositivos, y eso incluye también «cosas» más tradicionales como los routers. La larga historia de este fallo significa que tenemos más de un par de décadas de dispositivos por ahí que han pasado por varias evoluciones de diferentes sistemas operativos integrados y ahora tenemos un paisaje muy diverso de máquinas y conchas que abarcan un largo período de tiempo.
Esto trae consigo muchos nuevos desafíos; por ejemplo, ¿quién está pensando activamente que debe parchear regularmente sus bombillas? También hay que tener en cuenta la longevidad de los dispositivos en los que aparece este software y si realmente reciben un mantenimiento activo. En un caso como el de las cámaras vulnerables de Trendnet de hace un par de años, no cabe duda de que hay un gran número de ellas que siguen en la red porque, en términos de parches, son más bien una propuesta de «establecer y olvidar». De hecho, en ese caso hay toda una cuenta de Twitter dedicada a difundir las imágenes que ha capturado de los incautos propietarios de las versiones vulnerables. Es un gran problema que no tiene una solución fácil y que nos va a acompañar durante mucho tiempo.
Pero las cáscaras de Bash también están presentes en muchos dispositivos más comunes, por ejemplo, nuestros routers domésticos que generalmente están orientados a Internet. ¿Recuerdas cuándo fue la última vez que parcheaste el firmware de tu router? Ok, si estás leyendo esto entonces quizás seas el tipo de persona técnica que realmente parchea su router, pero ponte en la piel del consumidor medio y pregúntate eso de nuevo. Exactamente.
Todas nuestras cosas están en la pila de Microsoft, ¿estamos en riesgo?
Respuesta corta «no», respuesta larga «sí». Primero abordaré la más fácil: Bash no se encuentra de forma nativa en Windows y, aunque hay implementaciones de Bash para Windows, ciertamente no es común y no se va a encontrar en los PC de consumo. Tampoco está claro si productos como win-bash son realmente vulnerables a Shellshock en primer lugar.
La respuesta más larga es que sólo porque operas en un entorno predominantemente centrado en Microsoft no significa que no tengas Bash ejecutándose en máquinas que sirven a otros propósitos discretos dentro de ese entorno. Cuando escribí sobre Heartbleed, me referí al post de Nick Craver sobre el movimiento de Stack Overflow hacia SSL y me referí a este diagrama de su infraestructura:
Hay componentes que no son de Microsoft sentados delante de su pila de aplicaciones de Microsoft, componentes por los que el tráfico necesita pasar antes de llegar a los servidores web. Estos son también componentes que pueden tener privilegios elevados detrás del firewall – ¿cuál es el impacto si Shellshock es explotado en ellos? Podría ser significativo y ese es el punto que estoy haciendo aquí; Shellshock tiene el potencial de impactar en los activos más allá de las implementaciones de Bash en riesgo cuando existe en un ecosistema más amplio de otras máquinas.
Soy un administrador de sistemas – ¿qué puedo hacer?
En primer lugar, descubrir si estás en riesgo es trivial ya que es un riesgo tan fácilmente reproducible. Hay una prueba muy sencilla que sugiere The Register, que consiste en ejecutar este comando dentro de tu shell:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Si te «revientan» con un eco, habrás explotado el fallo con éxito.
Por supuesto, la prioridad aquí va a ser parchear los sistemas de riesgo y el parche se reduce esencialmente a asegurar que no se pueda ejecutar ningún código después del final de una función de Bash. Las distribuciones de Linux, como Red Hat, están publicando una guía para parchear el riesgo, por lo que es una cuestión prioritaria.
Invitablemente, también veremos definiciones para los sistemas de detección de intrusos y ciertamente habrá patrones comunes que buscar aquí. Esto puede ser una buena aplicación inmediata para muchas organizaciones, sobre todo cuando hay requisitos de prueba onerosos antes de desplegar los parches en los sistemas de riesgo. Qualys pretende tener una definición para detectar el ataque con bastante rapidez e, inevitablemente, otros proveedores de IDS están trabajando en esto sin descanso también.
Otras opciones más drásticas incluyen la sustitución de Bash por una implementación de shell alternativa o el acordonamiento de los sistemas en riesgo, ambos podrían tener ramificaciones de gran alcance y es poco probable que sean decisiones tomadas a la ligera. Pero esa es probablemente la naturaleza de este fallo para mucha gente: decisiones difíciles que podrían tener un impacto tangible en el negocio con el fin de evitar ramificaciones potencialmente mucho más significativas.
La otra cuestión que ahora comenzará a surgir mucho es la cuestión de si Shellshock ya ha sido explotado en un entorno. Esto puede ser difícil de determinar si no hay registro de los vectores de ataque (a menudo no lo habrá si se pasa por la cabecera de la solicitud HTTP o el cuerpo POST), pero es más probable que se detecte que con Heartbleed cuando, a falta de pcaps completos, las cargas útiles del latido del corazón normalmente no se habrían registrado en ninguna parte. Pero aún así, la respuesta más común a «¿Fuimos atacados vía Shellshock?» va a ser esta:
Desafortunadamente, esto no es «No, tenemos evidencia de que no hubo compromisos»; más bien, «no tenemos evidencia que abarque el tiempo de vida de esta vulnerabilidad». Dudamos que mucha gente las tenga – y esto deja a los propietarios de los sistemas en la incómoda posición de no saber qué, si es que hubo algún compromiso.
Que comiencen las especulaciones sobre si la NSA estaba en esto…
Soy un consumidor – ¿qué puedo hacer?
Depende. Shellshock afecta a los Macs, así que si usted está ejecutando OS X, en esta etapa que parece estar en riesgo, que por un lado es malo debido a la prevalencia de OS X, pero por otro lado será fácilmente (y espero que rápidamente) remediado debido a un mecanismo de actualización bastante bien probado (es decir, Apple puede empujar remotamente las actualizaciones a la máquina).
Si estás en un Mac, el riesgo es fácil de probar como se describe en esta respuesta de Stack Exchange:
Es una prueba fácil, aunque dudo que el usuario medio de Mac se sienta cómodo con la solución sugerida que implica volver a compilar Bash.
La mayor preocupación son los dispositivos que no tienen una ruta de parcheo fácil, por ejemplo su router. Si no se comprueba la actualización del firmware en el sitio web del fabricante, esto va a ser un hueso duro de roer. A menudo, los routers proporcionados por los proveedores de servicios de Internet están bloqueados para que los consumidores no cambien aleatoriamente la configuración o el firmware y no siempre hay una ruta de actualización remota que puedan activar. Si esto se combina con la enorme variedad de dispositivos y edades que existen, puede resultar especialmente complicado. Por supuesto, tampoco es el tipo de cosa que el consumidor medio se sienta cómodo haciendo por sí mismo.
En resumen, el consejo para los consumidores es el siguiente: estén atentos a las actualizaciones de seguridad, especialmente en OS X. Además, manténgase atento a cualquier consejo que pueda recibir de su ISP o de otros proveedores de dispositivos que tenga que ejecuten software integrado. Tenga cuidado con los mensajes de correo electrónico que solicitan información o le indican que ejecute un software, ya que este tipo de eventos suelen ir seguidos de ataques de phishing que se aprovechan de los temores de los consumidores. En la actualidad, los bulos hacen que la gente meta sus iPhones en el microondas, así que no pienses ni por un momento que no ejecutarán una pieza de software aleatoria enviada por correo electrónico como «solución» para Shellshock.
Resumen
Con toda probabilidad, ni siquiera hemos empezado a comprender la amplitud de esta vulnerabilidad. Por supuesto, se están haciendo muchas comparaciones con Heartbleed y hay una serie de cosas que aprendimos de ese ejercicio. Una de ellas es que tardamos un poco en asimilarlo al darnos cuenta de hasta qué punto dependíamos de OpenSSL. La otra es que tenía una cola muy larga: meses después de su aparición todavía había cientos de miles de hosts conocidos que eran vulnerables.
Pero en un sentido, la comparación con Heartbleed no es justa: esto es potencialmente mucho peor. Heartbleed permitía el acceso remoto a pequeñas cantidades de datos en la memoria de las máquinas afectadas. Shellshock permite la inyección remota de código de comandos arbitrarios antes de la autorización, lo que es potencialmente mucho más grave. En este sentido, tengo que estar de acuerdo con Robert:
Es muy, muy pronto todavía – sólo medio día desde que llegó a las ondas en el momento de escribir esto – y sospecho que hasta ahora sólo estamos arañando la superficie de lo que está por venir.
Seguridad