Ha corrido como la pólvora, y no es para menos. Antesdeayer, horario americano, se daba a conocer públicamente un par de vulnerabilidades que afectan a la gestión de variables de entorno de bash (EN), el intérprete de comandos de sistemas Unix.


vulnerable

Dicho así, en una frase, a muchos seguramente les suene a chino, pero tiene connotaciones que pone en riesgo la seguridad de buena parte de Internet, por lo que varios analistas ya lo comparan con el caso Heartbleed.

Comprendiendo el funcionamiento de la brecha

Como decíamos, la vulnerabilidad ataca a una mala implementación de bash, el intérprete de comandos de los sistemas operativos basados en Unix (por lo que afecta por igual a todas las distribuciones de Linux, derivaciones de Linux como Android y OS X, el SO de escritorio de Apple).

A bash se accede normalmente para realizar alguna tarea en la que interfieran procesos del sistema o de las aplicaciones instaladas en él. Lo usamos algunos usuarios para lanzar peticiones específicas (por ejemplo, realizar un ping a otro terminal de la red para asegurarnos que tenemos conexión, o consultar nuestra dirección IP para configurar algún servicio online), pero también lo usan aplicaciones web para procesar solicitudes en el servidor.

Para colmo, la gran mayoría de servidores son Linux, y teniendo en cuenta que en nuestros días los servicios digitales tienen que realizar llamadas a APIs y herramientas de terceros, podríamos decir que afecta directamente a casi todos los servicios de Internet.

Para realizar una llamada a una página web, el navegador tiene que hacer la petición al sistema operativo, y esto lo hace mediante comandos. Estos comandos contienen variables de estado, datos como la información del navegador, cookies disponibles, petición del usuario,…

En principio, el intérprete debería recopilar esas variables de estado, leerlas y actuar en consecuencia (por ejemplo, enviándolas por Internet al dominio pedido), pero al parecer, si dentro de alguna de estas variables, incluimos código malicioso (oculto justo después de la declaración de una función dentro de la variable de entorno), el intérprete no solo lo lee sino que también lo ejecuta, pudiendo realizar en la práctica casi cualquier maldad que se le ocurra.


env soyvariable='() { :;}; echo soyVulnerable' bash -c "echo Pwned"
env soyvariable2='() { (a)=>\' sh -c "echo soyVulnerable"; bash -c "echo Fallo 2 sin parchear"

soyvariable y soyvariable2 son dos variables de entorno, que tiene dentro de sí una función (en este caso una función anónima y nula, por ahorrar caracteres) que no hace nada. El problema radica en que después de la función, el intérprete sigue leyendo y ejecutando lo que encuentre. En este caso, devuelve por pantalla un soyVulnerable y un Pwned, y/o un soyVulnerable y un Fallo 2 sin parchear, según afecte a uno, a otro, o a los dos tipos de llamada.

Denegación de servicio, apagado del servidor, acceso a información, instalación de rootkits, creación de botnets, escalada de privilegios, redirección a otra IP comprometida,… Básicamente cualquier idea puede efectuarse mediante comandos que serán ejecutados en el propio bash, saltándose la mayoría de controles internos.

Afectaría por tanto a los siguientes servicios:

  • Páginas web con CGIs: Una búsqueda rápida en Google (filetype:sh inurl:cgi-bin) devuelve 1.230.000 resultados de servidores vulnerables al ataque. Teniendo un poco más de mala uva y utilizando shodan, seguramente encontremos millones.
  • Ejecución de comandos de forma remota a través de SSH: Tener SSH activo (algo habitual en la mayoría de servidores de servicios online distribuidos) es un vector más de ataque, pudiendo inyectar código desde ahí. Aunque como matiza Rafa Álvarez, es necesario estar autenticado en el canal (bien sea legítimamente o con las técnicas de sombrero negro al alcance), suponiendo que no se encuentre la forma de realizar un bypass.
  • Clientes DHCP: El DHCP es un protocolo utilizado para informar a un nuevo terminal en la red a dónde debe conectarse. Esos datos se pasan por shells mediante variables de estado, por lo que estamos en el caso inicial.
  • Sistemas que hagan uso del shell para determinadas funciones: lo dicho anteriormente.
  • Sistemas operativos móviles que ejecuten scripts de Bash como Android: Hay que dejar claro que una aplicación sencilla, sin permisos Root, seguramente lo tenga muy complicado para acceder a bash. Pero aquí entra en juego la creatividad de los atacantes (quizás algún protocolo que requiera forzar conexiones específicas a elementos internos del dispositivo…). También hay que considerar que al menos versiones 4.4 de Android están basadas en ash, no en bash, por lo que a priori no sería vulnerable.
  • Cualquier dispositivo que haga uso de Linux en segundo plano: El mejor ejemplo que se me ocurre son los routers, aunque podríamos hablar de la mayoría de dispositivos del internet de las cosas, o de videoconsolas como la PlayStation, SmarTVs,…

Cómo saber si soy vulnerable y qué hacer al respecto

Lo primero que hay que considerar es que como en el caso de Heartbleed, la vulnerabilidad afecta a servidores online o en alguna red, por lo que si usted, cliente, es vulnerable, pero no tiene ningún servicio disponible públicamente, no le debería afectar directamente.

Ahora bien, que no le afecte directamente no quiere decir que le pueda afectar indirectamente. Desde ataques que comprometen la información en servidores de servicios que usted utiliza (con la posible liberación de datos personales), pasando por páginas que pueden estar siendo en este momento comprometidas para que muestren contenido  autoejecutable para infectar sus dispositivos, o incluso ataques a su propia red WIFI de casa. En teoría hablamos de una puerta de acceso casi ilimitada.

Si usted es usuario, lo único que puede hacer es esperar a que los administradores de los servicios que utiliza asiduamente apliquen el parche oportuno. Y mantener un ojo abierto en todo momento, ya que la vulnerabilidad de bash puede ser aprovechada para realizar cualquier otro tipo de ataque más habitual que sí afecte a sus datos o sistemas.


Si usted es administrador de un servidor basado en Unix (si todos sus servicios están alojados en servidores Windows, a priori está libre de peligro), lo primero que haría sería probar que el comando superior no devuelve un positivo. En caso de que así sea, intentaría buscar el parche específico para su sistema.

En el momento en el que escribo estas palabras (medio día del jueves 25, aunque iré actualizándolo), se ha liberado un parche temporal para OS X, que no protege del todo, y que puede encontrar en el siguiente enlace (EN). El resto de distribuciones Linux están liberando sus propios parches (por ejemplo, Debian (EN)), por lo que es cuestión de ir mirando los foros y blogs de cada proyecto, así como actualizar los repositorios del SO.

 

Actualización a día 27 de Septiembre de 2014: Por ahora, y que un servidor haya visto o le hayan comentado, hay al menos un malware creado específicamente para aprovecharse de shellshock, llamado ELF_BASHLITE.A, y del que ya he hablado en el artículo del viernes (ES) del CIGTR. Rafa me avisa de otra vulnerabilidad asociada a la inyección de código por bash, definida en este enlace (EN), y el peligro de volcar en un ataque el archivo etc/passwd, que se encarga en distribuciones Linux de guardar credenciales de usuario.

Otros artículos relacionados