Shellshock es un fallo en el shell de la interfaz de línea de comandos Bash que existe desde hace 30 años y que fue descubierto como una amenaza importante en 2014. Hoy en día, Shellshock sigue siendo una amenaza para las empresas.
La amenaza es ciertamente menos arriesgada que en el año de su descubrimiento. Sin embargo, en un año en el que las prioridades de seguridad se han recalibrado para estar a la altura del caótico panorama, es un buen momento para echar un vistazo a esta amenaza y a los factores subyacentes que mantienen vivos estos ataques en la actualidad.
¿Por qué Shellshock es relevante en 2020?
Shellshock es una vulnerabilidad crítica debido a la escalada de privilegios que otorga a los atacantes, que les permite comprometer los sistemas a voluntad. Aunque la vulnerabilidad ShellShock, CVE-2014-6271, se descubrió en 2014, se sabe que sigue existiendo en un gran número de servidores en el mundo. La vulnerabilidad se actualizó (CVE-2014-7169) poco después y se ha modificado hasta 2018.
La razón principal por la que Shellshock sigue vigente no es ninguna sorpresa. Esta vulnerabilidad es un ataque sencillo y barato que los malos actores pueden desplegar contra un objetivo desconocido. Los parches han estado disponibles desde la entrada del CVE, pero cualquier organización que no cuente con sistemas de gestión de parches adecuados puede seguir siendo vulnerable.
Shellshock seguía siendo prominente en 2017. Cuando todo lo que los atacantes necesitan son algunos conocimientos básicos de programación, un servidor y acceso al malware, no es de extrañar. Además, el coste para llevar a cabo un ataque no es mucho más que unos pocos dólares al mes. Las matemáticas están a favor de los atacantes. Conocimiento mínimo, poco esfuerzo y bajo coste es igual a una estrategia de hacking fácil.
A pesar de toda la amplia cobertura de los medios de comunicación sobre ciberseguridad e incluso de una alerta del Departamento de Seguridad Nacional, algunos sistemas siguen sin parchear. En un ejemplo, los funcionarios del Centro de Sistemas Electorales no aplicaron un parche que comprometió los sistemas electorales de Georgia.
¿Cómo funciona Shellshock?
En términos sencillos, Shellshock es una vulnerabilidad que permite que los sistemas que contienen una versión vulnerable de Bash sean explotados para ejecutar comandos con mayores privilegios. Esto permite a los atacantes tomar potencialmente el control de ese sistema.
Aprovechando la técnica, Shellshock es un fallo de seguridad en el shell Bash (GNU Bash hasta la versión 4.3) que hace que Bash ejecute comandos bash no intencionados desde variables de entorno. Los actores de amenazas que explotan la vulnerabilidad pueden emitir comandos de forma remota en el host objetivo. Aunque Bash no está intrínsecamente orientado a Internet, muchos servicios internos y externos, como los servidores web, utilizan variables de entorno para comunicarse con el sistema operativo del servidor.
Si esas entradas de datos no se desinfectan -el proceso estándar de codificación que garantiza que el código no forma parte de la entrada- antes de su ejecución, los atacantes pueden lanzar comandos de petición HTTP ejecutados a través del shell de Bash.
Vulnerabilidad en detalle
Los servidores web no son los únicos recursos de red vulnerables. Los servidores de correo electrónico y los servidores DNS que utilizan BASH para comunicarse con el sistema operativo también podrían verse afectados. Aunque BASH se encuentra normalmente en sistemas basados en Unix, las organizaciones que utilizan sistemas basados en Windows no son inmunes. Es probable que estén aprovechando dispositivos o hardware que son vulnerables. Recordemos que BASH puede formar parte de routers domésticos, muchos dispositivos IoT y sistemas embebidos.
Shellshock puede incluso utilizarse para lanzar ataques de denegación de servicio (DOS).
Aquí está la línea de código (una declaración de función Bash seguida de un punto y coma y el comando ‘sleep’ ejecutado desde tres posibles caminos para asegurar que se ejecute):
nueva_función() { :;} ; /bin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20
Este comando «sleep» obliga al servidor a esperar veinte segundos antes de responder. Al hacerlo, los recursos de la máquina son esencialmente rehenes porque la máquina no puede hacer nada más durante veinte segundos.
Un comando «sleep» puede ser inofensivo, pero un atacante puede ser capaz de reemplazar esto con un código malicioso. Entonces, ese código puede esposar al servidor o al recurso para que sea incapaz de atender ninguna petición.
El riesgo de permitir a los usuarios dañinos de Internet ejecutar comandos de su elección de forma remota es alto. Al utilizar la apertura, los malos actores pueden lanzar programas en el sistema, crear conexiones salientes a sus propios sistemas y ejecutar software malicioso.
Quizás lo más grave es que la vulnerabilidad puede ser aprovechada para robar datos confidenciales e información almacenada en el sistema como detalles de tarjetas de crédito, contraseñas e información personal identificable (PII).
¿Sigue Shellshock haciendo estragos?
Shellshock ya no es tan frecuente como cuando se descubrió en 2014. Imagina el reto de tener que parchear todos los servidores vulnerables de tu empresa (y, eran muchos en ese momento).
Dicho esto, Shellshock sigue siendo un problema.
Por ejemplo, hay una campaña de ciberamenazas y vulnerabilidades en curso llamada «Sea Turtle» que aprovecha los registros DNS para acceder a sistemas sensibles. Para que los ataques tengan éxito, se requiere una serie de vulnerabilidades comunes de hardware y software, siendo Shellshock una de ellas.
Aunque no está tan extendido como antes, todas las empresas deberían asegurarse de que todo el hardware y el software están parcheados y actualizados.
Cómo saber si está afectado
Debido a que Shellshock tiene seis años de antigüedad, hay muchos escáneres de vulnerabilidad disponibles. Algunos de ellos son gratuitos. Uno, bashcheck, puede descargarse a través de Github.
Para aquellos técnicos, escribir un simple comando en el prompt de Bash también servirá:
env X=»() { :;} ; echo Bash is Infected» /bin/sh -c «echo completed»
env X=»() { :;} ; echo Bash is Infected» `que bash` -c «echo completed»
env VAR='() { :;}; echo Bash is Infected’ bash -c «echo completed»
Si el prompt devuelve un mensaje «Bash is Infected», es hora de actualizar y arreglar. Si su salida no devuelve «Bash está infectado», responderá con algo como:
bash: warning: VAR: ignorando intento de definición de función
bash: error importando definición de función para `VAR’
Prueba de Bash
Si quieres probar la vulnerabilidad de sitios web o scripts CGI específicos, la siguiente herramienta puede ayudarte: Herramienta de prueba de la vulnerabilidad Bash ‘ShellShock’ CVE-2014-6271. En cualquiera de los dos campos de entrada, introduzca la URL del sitio web o del script CGI que le gustaría probar y haga clic en los botones azules.
Lo que podemos aprender sobre las amenazas a la ciberseguridad
La mayor lección para la empresa aquí -y vale la pena repetirla- es parchear sus sistemas.
Los equipos que pueden reducir los tiempos de parcheo están en mejor posición para destinar esos recursos a problemas de seguridad más urgentes. Aunque algunas empresas consideran que la gestión de parches es más una responsabilidad de TI que de seguridad, la gestión de parches debe ser siempre prioritaria para los departamentos de seguridad, ya que es fundamental para la postura de seguridad de una empresa.
Si sus sistemas siguen siendo vulnerables hoy en día, es probable que haya algunos problemas operativos subyacentes que deben ser abordados. Shellshock es una vulnerabilidad muy antigua con parches disponibles para casi cualquier sistema. La mejor manera de protegerse contra este tipo de vulnerabilidad es mantener sus sistemas actualizados, aplicando todas las correcciones publicadas para este exploit.
Cuando se parchean los activos, normalmente un proceso sencillo, debe adoptar un enfoque estratégico.
Los parches probados a fondo son una gran manera de minimizar el impacto en el negocio – como un servidor de misión crítica que ejecuta un sistema operativo antiguo, por ejemplo. Si un sistema no puede ser parcheado inmediatamente, debe sopesarse el riesgo potencial de la vulnerabilidad frente al impacto en el negocio.
Shellshock es sólo una de una larga lista de vulnerabilidades con las que la empresa debe lidiar. Gestionar el aparentemente interminable flujo de vulnerabilidades es y será siempre una estrategia crítica que sustenta la ciberseguridad.
Lista de control para una organización segura
Para una gestión exitosa de las vulnerabilidades, las empresas deben tener la capacidad de tener éxito en estas tres áreas:
- Identificar rápidamente las vulnerabilidades potencialmente impactantes: La velocidad lo es todo aquí. Tener a todos en la misma página con un plan sólido debería promover tiempos de reacción más rápidos.
- Determinar el nivel de gravedad de la vulnerabilidad: Conocer la tolerancia al riesgo de su organización será de gran ayuda para determinar la gravedad de una vulnerabilidad. Dependiendo de su infraestructura de red, algunas vulnerabilidades son más dañinas que otras.
- Tener un plan de acción que equilibre la urgencia de la seguridad con el impacto potencial en los entornos de producción: Equilibrar la seguridad con la producción y la productividad es un obstáculo constante, pero las organizaciones con los planes mejor definidos para la gestión de vulnerabilidades suelen encontrar el mejor equilibrio.
Para el investigador de seguridad independiente Rod Soto, la mayor lección aprendida de Shellshock fue que Internet se basa en muchas aplicaciones vulnerables y siempre conlleva el potencial de comprometer una gran parte de sus segmentos.
«La forma de gestionar estas potenciales vulnerabilidades en el futuro es mantener una comunicación abierta y transparente entre los desarrolladores, los mantenedores y los profesionales de la seguridad», dice Soto. «Así, si se encuentra una vulnerabilidad tan extensa y significativa, se puede utilizar la coordinación entre todas las partes afectadas para parchear o mitigar los sistemas afectados».
Incluso en los casos en los que su empresa consiga mitigar el riesgo ante Shellshock o cualquier otra vulnerabilidad, no puede asumir que su plan de respuesta es perfecto. El plan de respuesta debe ser un documento vivo, que respire, y debe ser revisado con frecuencia para que su organización pueda responder a las amenazas rápidamente.
Por último, como en cualquier escenario posterior a un ataque, hay preguntas que debe hacerse al revisar cada fase del plan.
- ¿Qué partes del plan tuvieron éxito?
- ¿Qué partes del plan no tuvieron éxito?
- ¿Qué no hicimos que ahora nos damos cuenta de que teníamos que hacer?
- ¿Qué aprendimos que nos permite estar más preparados para la próxima vulnerabilidad que se nos presente?
Shellshock puede ser un ataque antiguo, pero para un atacante, marca todas las casillas para explotar a las víctimas que carecen de una higiene de seguridad adecuada.