Usuario:Schimal/Shellshock (software bug)

De Wikipedia, la enciclopedia libre

Shellshock, también conocida como Bashdoor,[1]​ es una familia de bugs de seguridad que tienen amplia difusión en la ampliamente usada en Bash de Unix Shell. El primero de estos bugs fue divulgado el 24 de Septiembre de 2014. Varios servicios de internet tal como algunas implementaciones de servidores web usan Bash para ciertos pedidos y procesos, esto le permitía al atacante ejecutar en versiones vulnerables de Bash comandos arbitrarios, de esta forma el atacante podía ganar acceso no autorizado al sistema atacado.[2]​

El 12 de septiembre Stéphane Chazelas contactó al encargado del mantenimiento de Bash, Chet Ramey[1]​ mencionándole acerca de su descubrimiento del error original el cual fue llamado "Bashdoor" . Trabajando en conjunto con expertos en seguridad se obtuvo en poco tiempo un parche que solucionaría el problema.[1]​ El error se identificó mediante el nombre de CVE-2014-6271. Fue anunciado al público el 24 de septiembre del 2014 cuando las actualizaciones de Batch ya incluían los parches hechos para la versión que se distribuiría en la actualización correspondiente.[3]​

El primer error ocasionaba que Bash sin previa autorización ejecutará comandos cuando los comandos están concatenados al final de una definición de función guardada en los valores de las variables de ambiente.[1]​[4]​ A días de la publicación del error, el intenso escrutinio de los defectos de diseño subyacentes descubrieron una amplia gama de nueva vulnerabilidades (CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, and CVE-2014-7187); para las cuales Ramey creó nuevos parches al software de Batch.[5]​[6]​

Atacantes explotaron Shellshock apenas habían pasado unas horas de la revelación inicial mediante la creación de botnets de computadoras previamente comprometidas para ejecutar ataques de denegación de servicio distribuido y escaneo de vulnerabilidades.[7]​[8]​ Las compañías de seguridad identificaron millones de ataques y pruebas relacionadas con el error en los días siguientes a su descubrimiento.[9]​[10]​

Shellshock pudo comprometer millones de servidores que no tuvieran el parche desarrollado por Ramey. Debido a su gran impacto ha sido comparada con el error Heartbleed debido a la severidad de la falla ocasionada.[2]​[11]​

Apple Inc. comenta que los sistemas OS X están a salvo por default, al menos que los usuarios configuraran servicios avanzados de UNIX. Estos usuarios avanzados pueden apagar los servicios hasta que un parche oficial de OS X está disponible, de igual forma podrían usar Xcode para reemplazar el Bash provisto por default por sistema con una versión personalizada y compilada de Bash que incorporará parches no oficiales.[12]​[13]​[14]​ A pesar de ser notificada de la vulnerabilidad antes de ser publicada, la compañía no sacó una actualización correspondiente de OS X hasta Septiembre 29 de 2014, al tiempo que la actualización de Bash OS X 1.0 fue sacada.[15]​[16]​[17]​

Antecedentes[editar]

Las vulnerabilidades Shellshock afectan a Bash, un programa que varios sistemas basado en Unix usan para ejecutar líneas de comando y scripts que ejecuten instrucciones. Comúnmente se encuentra instalado como la interfaz por defecto de línea de comando. Bash es un programa de Software libre, que fue desarrollado en colaborativamente desde 1992 por Chet Ramey, un arquitecto profesional de software.[1]​ El análisis del historial del código fuente de Bash muestra que las vulnerabilidades han existido desde la versión 1.03 sacada en Septiembre de 1989,[18]​[19]​ que fue introducida por el autor original de Bash, Brian Fox.

En los sistemas operativos basados en Unix y en otros sistemas operativos que Bash soporta, cada programa en curso tiene su propia lista de pares <nombre,valor> llamados variables de ambiente. Cuando un programa empieza otro programa , provee la lista inicial de variables de ambiente para el nuevo programa.[20]​ Independientemente de estas variables de ambiente, Bash también mantiene una lista interna de funciones, las cuales son scripts nombrados que puede ser ejecutados desde el programa.[21]​ Dado que Bash opera tanto como un interpretador de comando como un comando por si mismo, es posible ejecutar Bash desde el mismo. Cuanto esto sucede, la instancia original puede exportar variables de ambiente y definiciones de funciones a la nueva instancia creada de Bash.[22]​ Las definiciones de función son exportadas siendo codificadas dentro de la lista de variables de ambiente como variables cuyos valores empiezan con un paréntesis ("()") seguidas por una definición de función. Esta nueva instancia de Bash, hasta su inicialización, escanea la lista de variables de ambiente en su formato y las convierte de vuelta a funciones internas. Hace esta conversión creando un fragmento de código desde el valor y ejecutándolo, de este modo crea la función dinámicamente, en tiempo de ejecución, pero afecta a las versiones que no verifican que sea un definición función válida.[23]​ Por lo tanto, da la oportunidad de ejecutar Bash con un valor escogido de la lista de variables de ambiente, un atacante puede ejecutar comando arbitrarios o explotar otros errores de software que existan en el interpretador de comando de Bash.

Reporte de ataques[editar]

Apenas una hora después del anuncio de la vulnerabilidad Shellshock, hubo reportes de máquinas que fueron comprometidas por el error de software. En septiembre 25 de 2014, Botnets basados en computadoras comprometidas que fueron usadas gracias a la vulnerabilidad que el error ocasionaba fueron usadas por lo atacantes como máquinas que ejecutaban ataques de denegación de servicio distribuidos (DDoS) y hacían escaneos de vulnerabilidades.[7]​[8]​[24]​ Laboratorios Kaspersky reportaron que las máquinas comprometidas en el ataque, apodado "Thanks-Rob", conducían ataques DDoS hacia tres objetivos, los cuales no pudieron ser identificados.[7]​ En septiembre 26 de 2014, un botnet apodado "wopbot" fue reportado, el cual estaba siendo usado como botnet el cual atacaba a Akamai Technologies y a la vez escaneaba al Departamento de Defensa de los Estados Unidos. [8]​

El 26 de Septiembre, la firma de seguridad Incapsula noto 17,400 ataques, más de 1,800 en dominions web que se originaron desde 400 direcciones IP, en las 24 horas previas, 55% de los ataques provenían de China y de los Estados Unidos.[9]​ Para el 30 de septiembre, el sitio de la firma CloudFare dijo que estaba rastreando y siguiendo aproximadamente 1.5 millones de ataques y pruebas relacionadas con el error Shellshock.[10]​

El 6 de octubre fue ampliamente reportado que los servidores Yahoo! habían sido comprometidos en un ataque relacionado con el error ShellShock .[25]​[26]​ Aunque al día siguiente fue negado que únicamente el error Shellshock hubiera sido el causante de estos ataques.[27]​

Vectores vulnerables[editar]

Servidor Web CGI
Cuando un servidor web usa la Interfaz de entrada común para manejar una petición de documento, pasa varios detalles de la petición a un programa manejador en la lista de variables de ambiente. Por ejemplo, la variable HTTP_USER_AGENT tiene un valor, que en un uso normal, identifica al programa que manda la petición. Si la petición es un script de Bash o si se ejecuta usando la llamada a sistema, Bash recibirá las variables de entorno que fueron pasadas por el servidor y se procesarán como se describió más arriba. Eso provee medio para que un atacante desencadene la vulnerabilidad ShellShock con una petición hecha especialmente para este propósito.[4]​La documentación de seguridad que es ampliamente usada en los servidores Apache cita "Los scripts de CGI son extremadamente peligrosos si no son adecuadamente revisados"[28]​ Otros métodos para manejar peticiones de servidores web son usadas usualmente para evitar esta situación. Hay un número de servicios de internet que son usados para probar las vulnerabilidades a las que son expuestas los servidores.
Servidor OpenSSH
OpenSSH tiene un "Comando de Fuerza" la cual es una característica donde un comando fijo es ejecutado cuando el usuario entra con sus credenciales a su sesión respectiva, en lugar del comando por default de la shell. El comando fijo es ejecutado aún cuando el usuario dicta que el cualquier otro comando debería ser ejecutado, en ese caso lo que sucede es que el comando original es puesto dentro de la variables de ambiente "SSH_ORIGINAL_COMMAND". Cuando el comando es forzado a correr en un shell de Bash, esta misma haré un parseo de la variable de ambiente "SSH_ORIGINAL_COMMAND" al inicio de sesión y se correrá embebida en ella. El usuario a través de esto tendrá acceso sin restricciones a la shell, usando el error de software ShellShock.[29]​
Clientes DHCP
Varios clientes DHCP también pueden pasar comando de Bash, un sistema vulnerable puede ser atacado cuando se conecta a una red abierta Wi-Fi. Un cliente DHCP típicamente solicita y recibe direcciones IP de un servidor DHCP, pero también puede proveer una serie de opciones adicionales. Un servidor DHCP infectado puede proveer, en una de estas opciones un string hecho de tal forma que ejecute un código malicioso en una computadora de trabajo.[11]​
Servidor QMail
Cuando se usa Bash para procesar mensajes de correo electrónico, ya sea para reenviar o enviar, el servidor Qmail pasa datos de entrada externo que pueden ser usados como una vulnerabilidad de la versión respectiva de Bash.[30]​[31]​
Shell restringida IBM HMC
Este error de softaware puede ser aprovechado de tal forma que se gane acceso a Bash a través de la Shell restringida de IBM y su consola de Manejo de Hardware[32]​, una pequeña versión de Linux para administradores de sistema. IBM ya lazó una actualización que soluciona este error.[33]​

Reported vulnerabilities[editar]

Vista General[editar]

El encargado de Bash fue advertido sobe el descubrimiento del primer bug el 9 de Diciembre de 2014, y fue solucionado rápidamente.[1]​ Unas pocas compañías y distribuidores fuero informados de este asunto antes de que el asunto fuer público el 24 de Diciembre de 2014 con el identificador VE-2014-6271[34]​[3]​ Sin embargo después de la salida del bug hubieron reportes subsecuentes relacionados a más vulnerabilidades.

El 26 de septiembre de 2014 dos distribuidores de código abierto, David A. Wheeler y Norihiro Tanaka se dieron cuenta de que había problemas adicionales, aún después de la salida de los parches. En un correo electrónico dirigido a oss-sec, Wheeler escribió "Este parche solo es un intento de solucionar errores de parseo que comienzan con el primer parche. El parser de Bash tiene muchas más vulnerabilidades".[35]​ Sin embargo, este fue un razonamiento general sin prestar general atención en el posible aprovechamiento que pudo haber tenido Bash.

En septiembre 27 de 2014, Michal Zalewski de Google anunció el descubrimiento de mas vulnerabilidades de Bash[5]​ una estaba basada en que Bash típicamente compila sin aleatorización en el espacio de direcciones.[36]​ En Octubre 1, Zalewski publico los detalles de los bugs finales y ocnfirmo que un parche desarrollado por Florian Weimer de Red HatOque fue publicado el 25 de septiembre lo podría prevenir. Esto fue logrado usando una técnica difusa para nasí crear una técnica de ayuda de software conocida como "American Fuzzy Loop".[37]​

Reporte Inicial (CVE-2014-6271)[editar]

Esta forma original de vulnerabilidad involucra un ambiente variable especialmente diseñado para exportar la definición de una función seguida por comandos arbitrarios. Bash ejecuta incorrectamente la secuencia de comandos cuando importa la función.[38]​ La vulnerabilidad puede ser revisada con el siguiente comando

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

En los sistemas afectados por la vulnerabilidad, los comandos desplegados arriba desplegarían la palabra "vulnerable" como resultado de la ejecución de Bash corriendo el comando "echo vulnerable" que está embebido en otra variable especial llamada X.[6]​[39]​

CVE-2014-6277[editar]

Descubierto por Michal Zelwski[5]​[36]​[40]​ esta vulnerabilidad se relaciona a parsear definiciones de funciones en el ambiente de Bash, debido a que pueden ocasionar segfault.[41]​

CVE-2014-6278[editar]

También descubierto por Michał Zalewski.[41]​[42]​ se relaciona con el parseo de las definiciones de funciones de variables en Bash.

CVE-2014-7169[editar]

De la misma forma que la vulnerabilidad original fue publicada, Tavis Ormandy discovered this related bug[29]​ el cual puede ser demostrado por el siguiente código: 

env X='() { (a)=>\' bash -c "echo date"; cat echo

En un sistema vulnerable esto desplegaría el comando "date" no intencionalmente.[29]​

Aquí hay un ejemplo de un sistema que tiene el parche para el bug CVE-2014-6271 pero no para el CVE-2014-7169:

$ X='() { (a)=>\' bash -c "echo date"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
$ cat echo
Fri Sep 26 01:37:16 UTC 2014

El sistema despliega los errores de sintaxis, notificando al usuario que CVE-2014-6271fue prevenida, pero aún escribe un archivo llamado "echo", en el directorio de trabajo, conteniendo la fecha de creación como resultado del bug.

Un sistema publicado para el parche de CVE-2014-6271 y CVE-2014-7169 simplemente haría echo a la palabra "date" y el archivo "echo" no sería creado como se muestra debajo. 

$ X='() { (a)=>\' bash -c "echo date"
date
$ cat echo
cat: echo: No such file or directory

CVE-2014-7186[editar]

Florian Weimer y Todd Sabin encontraron este bug [6]​[37]​ el cual está relacionado con Desbordamiento de búferen el parser de Bash.[43]​

Un ejemplo de tal vulnerabilidad que se aprovecha de los múltiples usos de declaraciones "<<EOF": 

(for x in {1..200}; do echo "foex$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

Un sistema vulnerable haría echo sobre el texto "CVE-2014-7187 vulnerable, word_lineno". Este test requiere una shell que soporte expansion de corchetes.[44]​

Parches[editar]

Hasta Septiembre 24 de 2014, el encargado de Bash Chet Ramey proveyó de una versión del parche bash43-025 de la dirección de Bash 4.3 CVE-2014-6271[45]​ la cual ya esta empaquetada y distribuida por los encargados de las distribuciones. En Septiembre 24 fue empaquetada finalmente por los administradores de las versiones . El 24 de Septiembre, bash43.026 seguido de la dirección CVE-2014-7169 fue descubierta. Florian Weimer de Red Hat publico cierto código útil para un parche no oficial en septiembre 25,[46]​ El cual Ramaney incorporó a Bash como bash43-027.[47]​Estos parches solo proveían código que supieran como recompilar una nueva distribución ejecutable de Bash a partir de archivos proveídos de forma externa.

El día siguiente, Red Hat sacó oficialmente de acuerdo a las actualizaciones de Red Hat Linux [48]​[49]​ solo un día después que Fera 21[50]​ Canonical presentomejoras ya actualizaciones para Ubuntu y sus versiones a largo plazo presentadas para la versión de Unix[51]​ El domingo las actualizaciones hubieron actualizaciones para SUSE Linux[52]​El siguiente lunes y martes y finales de mes las actualizaciones para Apple Os X por fin salieron.[53]​[54]​

  1. ↑ a b c d e f Perlroth, Nicole (25 September 2014). «Security Experts Expect ‘Shellshock’ Software Bug in Bash to Be Significant». New York Times. Consultado el 25 September 2014. 
  2. ↑ a b Seltzer, Larry (29 September 2014). «Shellshock makes Heartbleed look insignificant». ZDNet. Consultado el 29 September 2014. 
  3. ↑ a b Florian Weimer (24 September 2014). «oss-sec: Re: CVE-2014-6271: remote code execution through bash». Seclists.org. Consultado el 1 November 2014. 
  4. ↑ a b Leyden, John (24 September 2014). «Patch Bash NOW: 'Shell Shock' bug blasts OS X, Linux systems wide open». The Register. Consultado el 25 September 2014. 
  5. ↑ a b c Saarinen, Juha (29 September 2014). «Further flaws render Shellshock patch ineffective». iTnews. Consultado el 29 September 2014. 
  6. ↑ a b c Vaughan-Nichols, Steven (27 September 2014). «Shellshock: Better 'bash' patches now available». ZDNet. Consultado el 29 September 2014. 
  7. ↑ a b c Greenberg, Andy (25 September 2014). «Hackers Are Already Using the Shellshock Bug to Launch Botnet Attacks». Wired. Consultado el 28 September 2014. 
  8. ↑ a b c Saarinen, Juha (26 September 2014). «First Shellshock botnet attacks Akamai, US DoD networks». iTnews. Consultado el 26 September 2014. 
  9. ↑ a b Perlroth, Nicole (26 September 2014). «Companies Rush to Fix Shellshock Software Bug as Hackers Launch Thousands of Attacks». New York Times. Consultado el 29 September 2014. 
  10. ↑ a b Strohm, Chris; Robertson, Jordan (30 September 2014). «Shellshock Draws Hacker Attacks, Sparks Race to Patch Bug». Businessweek. Consultado el 1 October 2014. 
  11. ↑ a b Cerrudo, Cesar (30 September 2014). «Why the Shellshock Bug Is Worse than Heartbleed». MIT Technology Review. Consultado el 1 October 2014. 
  12. ↑ Chacos, Brad (26 September 2014). «Apple Says Users Safe». Mac World. Consultado el 26 September 2014. 
  13. ↑ «Apple Working Quickly». iMore. 26 September 2014. Consultado el 26 September 2014. 
  14. ↑ TJ Luoma (25 September 2014). «How to patch OS X for the bash/Shellshock vulnerability». Engadget. Consultado el 11 August 2015. 
  15. ↑ Gallagher, Sean. «Apple working on "Shellshock" fix, says most users not at risk». Consultado el 29 September 2014. 
  16. ↑ Ragan, Steve (30 September 2014). «Apple's Shellshock patch is incomplete experts say». CSO Online. Consultado el 9 October 2014. 
  17. ↑ «About OS X bash Update 1.0». 
  18. ↑ Fox, Brian (21 March 1990). «Bash 1.05 ChangeLog». Consultado el 14 October 2014. 
  19. ↑ Chazelas, Stéphane (10 October 2014). «when was shellshock introduced». Stéphane Chazelas and Chet Ramey confirm the vulnerability introduction date on Bash official communication channel. Consultado el 14 October 2014. 
  20. ↑ «Open Group Base Specification: exec». Consultado el 2 October 2014. 
  21. ↑ «Bash Reference Manual: Shell Functions». Consultado el 2 October 2014. 
  22. ↑ «Bash Reference Manual: Bourne Shell Builtins». Consultado el 2 October 2014. 
  23. ↑ «Bash 4.3 source code, file variables.c, lines 315-388». Consultado el 2 October 2014. 
  24. ↑ Various (26 September 2014). «Web attacks build on Shellshock bug». BBC. Consultado el 26 September 2014. 
  25. ↑ Boren, Zachary (6 October 2014). «Shellshock: Romanian hackers are accessing Yahoo servers, claims security expert». Independent. Consultado el 7 October 2014. 
  26. ↑ «Yahoo! Shellshocked Like Ninja Turtles!». Consultado el 7 October 2014. 
  27. ↑ Hanno Böck (7 October 2014). «Yahoo durch Shellshock angegriffen». Golem - IT-News für Profis (en alemán). Consultado el 30 de octubre de 2014. 
  28. ↑ «Apache HTTP Server 2.2 Documentation: Security Tips». Consultado el 2 October 2014. 
  29. ↑ a b c Wolfgang Kandek (24 September 2014). «The Laws of Vulnerabilities». Qualys.com. Consultado el 26 September 2014. 
  30. ↑ "qmail is a vector for CVE-2014-6271 (bash shellshock)", Sep 27, 2014, Kyle George, qmail mailing list
  31. ↑ "Further flaws render Shellshock patch ineffective", Sep 29, 2014, Juha Saarinen, itnews.com.au
  32. ↑ "IBM HMC is a vector for CVE-2014-6271 (bash "shellshock")
  33. ↑ «Security Bulletin: Vulnerabilities in Bash affect DS8000 HMC (CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278)». IBM. 3 October 2014. Consultado el 2 November 2014. 
  34. ↑ Error en la cita: Etiqueta <ref> no válida; no se ha definido el contenido de las referencias llamadas seclist-q3-650
  35. ↑ Gallagher, Sean (26 September 2014). «Still more vulnerabilities in bash? Shellshock becomes whack-a-mole». Arstechnica. Consultado el 26 September 2014. 
  36. ↑ a b Staff (28 September 2014). «Shellshock, Part 3: Three more security problems in Bash (in german)». Heise Online. Consultado el 28 September 2014. 
  37. ↑ a b «Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)». lcamtuf blog. 1 October 2014. Consultado el 8 October 2014. 
  38. ↑ «Vulnerability Summary for CVE-2014-6271». NIST. 4 October 2014. Consultado el 8 October 2014. 
  39. ↑ «Bash specially-crafted environment variables code injection attack». Red Hat Security. Consultado el 2 October 2014. 
  40. ↑ Staff (27 September 2014). «National Cyber Awareness System Vulnerability Summary for CVE-2014-6277». National Institute of Standards and Technology. Consultado el 28 September 2014. 
  41. ↑ a b Constatin, Lucian (29 September 2014). «Improved patch tackles new Shellshock Bash bug attack vectors». PC World. Consultado el 1 October 2014. 
  42. ↑ Staff (30 September 2014). «National Cyber Awareness System Vulnerability Summary for CVE-2014-6278». National Institute of Standards and Technology. Consultado el 1 October 2014. 
  43. ↑ Staff (29 September 2014). «National Cyber Awareness System Vulnerability Summary for CVE-2014-7186». National Institute of Standards and Technology. Consultado el 1 October 2014. 
  44. ↑ Ramey, Chet. «Re: CVE-2014-7187». lists.gnu.org. 
  45. ↑ «BASH PATCH REPORT». GNU.org. 12 September 2014. Consultado el 2 November 2014. 
  46. ↑ Weimer, Florian (25 September 2014). «Re: CVE-2014-6271: remote code execution through bash». Openwall Project. Consultado el 2 November 2014. 
  47. ↑ Gallagher, Sean (26 September 2014). «New “Shellshock” patch rushed out to resolve gaps in first fix [Updated]». Consultado el 2 November 2014. 
  48. ↑ «Important: bash security update». Red Hat. 30 September 2014. Consultado el 2 November 2014. 
  49. ↑ «Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)». Red Hat. 2 October 2014. Consultado el 2 November 2014. 
  50. ↑ «[SECURITY] Fedora 21 Update: bash-4.3.25-2.fc21». FedoraProject.org. 27 September 2014. Consultado el 2 November 2014. 
  51. ↑ «USN-2364-1: Bash vulnerabilities». Canonical Ltd. 27 September 2014. Consultado el 2 November 2014. 
  52. ↑ «SUSE Security Update: Security update for bash». OpenSUSE. 28 September 2014. Consultado el 2 November 2014. 
  53. ↑ Clover, Juli (29 September 2014). «Apple Releases OS X Bash Update to Fix 'Shellshock' Security Flaw in Mavericks, Mountain Lion, and Lion». MacRumors.com. Consultado el 2 October 2014. 
  54. ↑ Slivka, Eric (30 September 2014). «Apple Releases OS X Yosemite Golden Master Candidate to Developers [Update: Also Public Beta]». MacRumors.com. Consultado el 2 October 2014. 
Obtenido de «https://es.wikipedia.org/w/index.php?title=Usuario:Schimal/Shellshock_(software_bug)&oldid=125249903»