Bashdoor (también en inglés Shellshock [1] ) es una serie de vulnerabilidades de software descubiertas en el programa GNU Bash en septiembre de 2014 y lanzadas públicamente el 24 de septiembre [2] . Muchos servicios de Internet , incluidos los servidores web , pueden usar Bash para procesar ciertas solicitudes, como cuando se ejecutan scripts CGI . La vulnerabilidad permite que un atacante ejecute comandos arbitrarios, obteniendo acceso no autorizado a los sistemas informáticos [3] .
Las vulnerabilidades radican en que Bash, contrario a las capacidades declaradas, ejecuta comandos al recibir algunos valores no estándar de variables de entorno ( entorno ) [1] [4] . Unos días después de la publicación de la vulnerabilidad original, se descubrieron varios errores similares, lo que impidió el lanzamiento rápido de una versión parcheada.
El error original fue descubierto por Stéphane Chazelas [1] ( en francés Stéphane Chazelas ) el 12 de septiembre de 2014 [1] , quien sugirió llamarlo "bashdoor" (consonante con backdoor ) [1] . La vulnerabilidad recibió el número CVE-2014-6271 en la base de datos MITRE y permaneció inédita (fue embargada ) hasta las 14:00 UTC del 24 de septiembre, para que los autores del programa, los creadores de distribuciones y otras organizaciones interesadas pudieran tomar las medidas necesarias. medidas [5] .
Un análisis del código fuente de Bash indica que la vulnerabilidad se introdujo en el código alrededor de la versión 1.13 en 1992 o antes [6] y no ha sido detectada ni declarada por el público en general desde [4] . El equipo de creación de Bash tiene dificultades para determinar la hora exacta en que se introdujo el error debido a un registro de cambios insuficientemente detallado ( registro de cambios ) [1] .
El 25 de septiembre de 2014, en base a la vulnerabilidad, ya se crearon botnets para realizar ataques DoS y DDoS , así como para escanear vulnerabilidades [7] [8] . Se estima que millones de sistemas son vulnerables. El error recibió la calificación máxima en la escala de gravedad y se compara en valor con Heartbleed , un error en OpenSSL (abril de 2014) [9] [10] .
La vulnerabilidad Shellshock (bashdoor) hace referencia al programa bash (desarrollado por el proyecto GNU ) utilizado en muchos sistemas operativos y distribuciones similares a Unix como intérprete de línea de comandos y para ejecutar scripts de shell. A menudo se establece como el intérprete del sistema predeterminado.
En sistemas operativos similares a Unix y otros compatibles con bash, cada programa tiene una lista de pares de nombre y valor llamados variables de entorno . Cuando un programa inicia otro, también se pasa la lista inicial de variables de entorno [11] . Además de las variables de entorno, bash también mantiene una lista interna de funciones, scripts con nombre que se pueden llamar desde un script bash ejecutable [12] . Al iniciar nuevas instancias de bash desde un bash existente, es posible pasar ( exportar ) los valores de las variables de entorno existentes y las definiciones de funciones al proceso generado [13] . Las definiciones de función se exportan codificándolas como nuevas variables de entorno de un formato especial, comenzando con corchetes vacíos "()" seguidos de la definición de función como una cadena. Las nuevas instancias de bash escanean todas las variables de entorno al inicio, detectan el formato dado y lo vuelven a convertir en una definición de función interna [14] . Esta transformación se realiza creando un fragmento de código bash basado en el valor de la variable de entorno y ejecutándolo, es decir, 'sobre la marcha'. Las versiones afectadas de bash no verifican que el ejecutable contenga solo una definición de función [14] . Por lo tanto, si un atacante tiene la capacidad de proporcionar una variable de entorno arbitraria al inicio de bash, entonces es posible ejecutar comandos arbitrarios.
El 27 de septiembre se publicó un parche de calidad que agrega un prefijo especial a todas las funciones exportadas e importadas cuando se convierten a variables de entorno y viceversa [15] .
El mismo día que se publicó la información sobre la vulnerabilidad original y los parches que la solucionan, Tavis Ormandy descubrió un nuevo error relacionado CVE-2014-7169 [3] . Las correcciones actualizadas estuvieron disponibles el 26 de septiembre [3] [16] [17] [18] [19] [20] .
Mientras trabajaba para corregir el error Shellshock original, el investigador de Red Hat, Florian Weimer, descubrió dos errores más: CVE-2014-7186 y CVE-2014-7187 [21] [22] .
El 26 de septiembre de 2014, dos desarrolladores de código abierto, David A. Wheeler y Norihiro Tanaka, notaron que había problemas adicionales que aún no se habían solucionado con los parches disponibles en ese momento. En su correo electrónico a las listas de correo "oss-sec" y "bash bug", Wheeler escribió:
Este parche solo continúa el trabajo de "matar al topo" ( whac-a-mole ) [23] para corregir varios errores de análisis iniciados con el primer parche. El analizador bash, por supuesto, contiene muchas, muchas otras vulnerabilidades.
Texto original (inglés)[ mostrarocultar] Este parche simplemente continúa con el trabajo 'whack-a-mole' de corregir los errores de análisis que comenzaron con el primer parche. Es seguro que el analizador de Bash tiene muchas, muchas, muchas otras vulnerabilidades. — [24]El 27 de septiembre de 2014, Michal Zalewski anunció que había descubierto varios otros errores en bash [25] [26] , uno de los cuales explota el hecho de que bash a menudo se compila sin usar la técnica de protección ASLR ( Address Space Layout Randomization ) [27 ] . Zalewski también pidió un parche urgente de Florian Weimer [25] [26] [27] .
El bashdoor original: un tipo especial de variable de entorno consiste en la definición de una función exportada seguida de comandos arbitrarios. Las versiones vulnerables de Bash ejecutan estos comandos arbitrarios durante el inicio [28] . Ejemplo de error:
entorno x = '() {:;}; echo Vulnerable' bash -c "echo Prueba de impresión"En sistemas vulnerables, esta prueba imprimirá la frase "Vulnerable" ejecutando el comando desde la variable de entorno x [29] .
A partir del 29 de septiembre, los detalles de la vulnerabilidad no se divulgaron públicamente [25] [27] [30] .
A partir del 29 de septiembre, los detalles de la vulnerabilidad no se divulgaron públicamente [25] [31] .
Descubierto por Tavis Ormandy mientras trabajaba en CVE-2014-6271 :
env X='() { (a)=>\' sh -c "echo date"; cat echo
La prueba hace que "eco" se convierta en el nombre de archivo para la redirección de salida y que se ejecute "fecha". El error recibió el número CVE-2014-7169 [3] .
Un ejemplo del error 7169 en un sistema que recibió una solución para el error CVE-2014-6271 pero no para el error CVE-2014-7169 [32] $ X = '() { (a)=>\' bash -c "fecha de eco" bash: X: línea 1 : error de sintaxis cerca del token inesperado ` = ' bash: X: línea 1: `' bash: error al importar la función definición para ` X ' [ root@ ec2-user ] # cat echo Fri Sep 26 01:37:16 UTC 2014Arreglar tanto CVE-2014-6271 como CVE-2014-7169 romperá la prueba:
$ X = '() { (a)=>\' bash -c "fecha de eco" fecha $ gato eco cat: echo: No existe tal archivo o directorioEl error es causado por problemas similares en el código Bash [33] pero se ve afectado por la repetición de "<<EOF"
Prueba bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "Vulnerable por CVE-2014-7186, redir_stack" El sistema afectado mostrará el texto "Vulnerable por CVE-2014-7186, redir_stack".El error es causado por problemas similares en el código Bash [33] , sin embargo, se ve afectado por múltiples repeticiones de "hecho"
Prueba ( for x in { 1 ..200 } ; do echo "for x $x in ; do :" ; done ; for x in { 1 ..200 } ; do echo done ; done ) | golpe || echo "Vulnerable por CVE-2014-7187, word_lineno" El sistema afectado mostrará el texto "Vulnerable por CVE-2014-7187, word_lineno".Una hora después de la publicación de la vulnerabilidad Bash, hubo informes de piratería de sistemas informáticos con su ayuda. El 25 de septiembre, se confirmaron varios ataques 'in the wild', que van desde simples ataques DoS hasta el despliegue de servidores de comando y control a través del sistema malicioso "BASHLITE" [34] [35] . Kaspersky Labs informó que algunas de las computadoras infectadas lanzaron un ataque DDoS contra tres objetivos [8] . El 26 de septiembre, se descubrió una botnet “wopbot”, compuesta por servidores infectados a través de bashdoor, y utilizada en DDoS contra las CDN de Akamai Technologies y para escanear las redes del Departamento de Defensa de EE. UU. [7] .
Hay varias formas potenciales que un atacante puede usar para pasar variables de entorno arbitrarias a bash ejecutándose en el servidor atacado:
Los servidores web que ejecutan scripts de interfaz de puerta de enlace común (CGI) pasan detalles de una solicitud de usuario a través de variables de entorno como HTTP_USER_AGENT. Si la solicitud es procesada por el programa Bash u otro programa que llama a bash internamente, entonces el atacante puede reemplazar la cadena User-Agent transmitida a través de http con un disparador de ataque Shellshock agregando sus propios comandos [36] . Por ejemplo, la instrucción "ping" con la dirección del atacante se puede dar como tal comando. A partir de las solicitudes de ping entrantes, el atacante sabrá si el ataque ha funcionado.
Aunque CGI es una interfaz heredada con otros riesgos de seguridad [37] , todavía está en uso. Por ejemplo, uno de los scripts estándar de cPanel es vulnerable [38] , se estima que el cPanel vulnerable se puede usar en el 2-3% de los sitios web [39] .
El servidor OpenSSH SSH le permite restringir al usuario a un conjunto fijo de comandos disponibles (opción "ForceCommand"). Un comando fijo se ejecuta incluso si el usuario ha solicitado que se ejecute otro comando. El comando solicitado en este caso se almacena en la variable de entorno "SSH_ORIGINAL_COMMAND". Si se ejecuta un comando fijo en un shell Bash (si el intérprete del usuario está configurado en Bash), GNU Bash detectará los valores SSH_ORIGINAL_COMMAND incrustados en el entorno al inicio y, en caso de una vulnerabilidad de Bashdoor, ejecutará el comandos incrustados allí. Por lo tanto, un atacante con acceso solo a un shell restringido obtiene acceso sin restricciones [3] .
Un cliente DHCP generalmente solicita una dirección IP de un servidor DHCP. Sin embargo, el servidor puede enviar varias opciones adicionales, que pueden escribirse en variables de entorno y hacer que Shellshock se explote en una computadora o computadora portátil conectada a la red local [40] [41] .
Un programa con el conjunto de bits setuid puede llamar a bash directamente o indirectamente usando las llamadas del sistema system(3) , popen y otros, sin restablecer las variables de entorno. Un ataque de Shellshock en tales casos permitiría al usuario local elevar sus propios privilegios al propietario del programa similar a setuid, a menudo hasta root (superusuario).
El error podría llegar a los sistemas que no están conectados a Internet durante el procesamiento fuera de línea con bash [42] .