Si recientemente hemos padecido, uno de los mayores agujeros de seguridad existentes, conocido como Heartbleed o Corazón sangrante, la cara que se nos puede quedar al ser conscientes de la nueva vulnerabilidad descubierta hace unos dias, puede ser similar a la del soldado situado en la fotografía inferior izquierda.
Tirando un poco de historia el nombre de ShellShock proviene la reacción de tuvieron algunos soldados de la primera guerra mundial a los traumas ocasionados en la batalla, a las duras imágenes y sensaciones que percibieron durante el combate. Soldado y rostro incapaz de razonar, caminar, hablar, paralizado del horror.
Y aunque este agujero de seguridad no tenga tan poderosos efectos marketing como el logo del corazón sangrante (ver imagen del anexo inferior), ya de entrada les sugiero al menos uno como este, para simplificar en otras publicaciones relacionadas, ya que una imagen vale más que mil palabras:
Sí, esos ojos perdidos reflejan claramente el estado anímico que puede tener un administrador de sistemas al conocer la noticia publicada el 24 de septiembre de este año.
Shellshock es el nombre también de un agujero de seguridad que puede afectar según estadísticas de netcraft al 60% de los servidores existentes en Internet, unos 500 millones de ordenadores.
Según la CVE 2014-6271 del NIST, es decir la “Común lista de vulnerabilidades y exposiciones”, con números de referencia únicos, este fallo de seguridad ha sido clasificado de 10, es decir el más alto.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
Debido a esto, un atacante de forma local o remota puede ejecutar código de forma arbitraria saltándose la seguridad preestablecida. Todo ello, gracias a un fallo que ha existido desde hace 20 años en el Shell Bash, presente en distribuciones Linux, BSD, Mac OS.
Afecta a las versiones Bash no parcheadas desde la 1.14 hasta la 4.3.
Este bug funciona mediante inyección de órdenes o mandatos, y puede ser invocado mediante llamadas a cgis de forma remota y sin necesidad de realiza autenticación. Por lo tanto es necesario actualizar mediante fix los sistemas que tenemos para evitar posibles problemas de seguridad.
Para actualizar es preciso, desde diversas distros o versiones:
Ubuntu/Debian:
Mediante el comando apt-get
sudo apt-get update && sudo apt-get install –only-upgrade bash
Si estas ejecutando una version de Ubunto/Debian que ha sido considerada como sin Soporte, tendras que actualizar mediante commando: sudo do-release-upgrade
CentOs/Red Hat/Fedora:
Mediante el comando:
sudo yum update bash
Otros sistemas como Mac OS mediante la actualización oportuna.
¿Cómo saber si tengo la vulnerabilidad – Prueba de concepto (PoC)?
Si estas ejecutando un sistema que tiene por Shell o interprete de comandos Bash, es necesario ejecutar:
env 'VAR=() { :;}; echo Bash es vulnerable!' 'FUNCTION()=() { :;}; echo Bash es vulnerable!' bash -c "echo Bash Test"
env ‘VAR=() { :;}; echo Bash es vulnerable!‘ ‘FUNCTION()=() { :;}; echo Bash es vulnerable!‘ bash -c «echo Bash Test»
Si al finalizar la ejecución apreciamos un:
Bash es vulnerable
Bash Test
Nuestro sistema necesita ser actualizado.
En esta entrada no explicaré los pasos necesarios para hacer una prueba de ataque, puesto que lo que pretendo es que actualicéis los sistemas cuanto antes. Pero el ataque puede ser efectuado de forma sencilla, y ya existen vídeos pululando por youtube para efectuar sin “muchos conocimientos técnicos” dichas acciones.
Cuando he comentado que el bug funciona bajo inyección, se puede apreciar en las porciones de código que he resaltado de otro color. Un atacante remoto podría ejecutar su código reemplazando el comando echo por una función que él defina.
Existe también una utilidad remota que permite testear websites que son vulnerables:
http://shellshock.brandonpotter.com/
Simplemente es necesario introducir la URL del sitio web o script CGI y enviarla.
El peligro de este ataque con escala total de privilegios en el sistema puede desencadenar una oleada de virus o gusanos tipo script que infecten a Internet en poco tiempo, provocando grandes pérdidas económicas y de disponibilidad para todos.
Aviso: Con una simples líneas remotas mediante por ejemplo cUrl podríamos comprometer la seguridad de un sistema remoto extremadamente rápido.
Además , el ataque parece más sencillo de efectuar que heartbleed, por contra no se ha dado tanta publicidad y el problema principal que vaticino, es que en muchos sistemas la actualización no va a ser tan rápida. Otro aspecto a tener en cuenta son las posibles forks o ramificaciones que tenga este bug, que impidan tapar este fallo.
Me llama la poderosamente la atención que empresas de hosting/housing con alquiler de servidores dedicados, no hayan reaccionado avisando al menos a los administradores de los posibles problemas y de las ténicas necesarias para realizar las actualizaciones oportunas. Es preciso recordar que muchos administradores con menos conocimientos manejan máquinas con paneles como el Cpanel, Plesk ,etc, y sera preciso comprar el alcance de dichas actualizaciones para no comprometer las aplicaciones en producción.
Actuemos.
Al Cesar lo que es del Cesar. El descubridor de este fallo es Stephane Chazelas, un desarrollador de software de código abierto que vive en Gran Bretaña.
Anexo logo HeartBleed:
