Leviathan Level 5 → Level 6

Definitivamente, el grueso de estos niveles está en el uso y abuso del bit suid.

Como de costumbre, los datos de conexión son:

- Host: leviathan.labs.overthewire.org 

- User: leviathan5

- Pass: Tith4cokei

Y la misma información que la del nivel anterior nada de nada.

En este caso, tenemos un binario llamado levithan5 con el bit suid activo para leviathan6. Lo que éste hace a groso modo, es leer el contenido de un fichero /tmp/file.log, imprimir su contenido por pantalla y borrarlo después.

En la siguiente captura, se puede apreciar su comportamiento:

Aquí está claro que lo que hay que hacer es que file.log sea un enlace simbólico a /etc/levithan_pass/leviathan6 puesto que el binario tiene los permisos necesarios para leer su contenido:

Esto todo por el momento. ¡Hasta el próximo nivel!

Bandit Level 16 → Level 17

Continuamos con un nuevo nivel, el cual promete y mucho.

Como siempre, los datos de conexión son:

- Host: bandit.labs.overthewire.org 

- User: bandit16

- Pass: cluFn7wTiGryunymYOu4RcffSxQluehd

Los objetivos son claros:

Según la información que nos dan, este nivel es muy similar al anterior con la diferencias de que ahora nos dan un rango de puertos [31000, 32000]. Además nos dictaminan los pasos a seguir.

Por tanto, comenzamos por escanear el rango de puertos para determinar cuales de ellos está activos haciendo uso del comando 'nmap':

Observamos que existen cinco puertos con servicios habilitados, así que el siguiente paso será determinar cual de ellos usa SSL:

Ya sabemos que los puertos 31518 y 31790 utilizan SSL, Por prueba y error (solo son dos) determinamos cual de ellos y le enviamos la password actual:

Es fácil darse cuenta que lo que nos han dado es la clave privada con la que hacer una conexión SSH a bandit17, por tanto, la guardamos en un fichero para darle persistencia y así poder usarla posteriormente:

Ahora establecemos la conexión SSH:

Y obtenemos un error más que evidente. Los permisos que le dimos al fichero que almacena la clave son demasiado poco restrictivos, por tanto, modificamos los permisos y repetimos:

Ahora sí. Ya solo nos queda obtener la password:

Parece que nivel a nivel se va aumentando la motivación de estos y se van utilizando nuevas herramientas muy usadas en entornos reales.

Esto es todos por ahora. ¡Hasta el próximo nivel!

Leviathan Level 4 → Level 5

Parece que este WarGame va de bits suid. Vamos a ver que nos tiene preparado este nivel.

Como ya viene siendo habitual, los datos de conexión SSH son:

- Host: leviathan.labs.overthewire.org 

- User: leviathan4

- Pass: vuH0coox6m

Y la misma información que la del nivel anterior nada de nada.

Esta vez tenemos esto:

Muy sencillo este nivel. A simple vista se ve que nos estan dado el valor ASCII de cada letra en binario. Por tanto, hacemos la conversión y obtenemos la password:

01010100 = 0x54 = T
01101001 = 0x69 = i 
01110100 = 0x74 = t
01101000 = 0x68 = h
00110100 = 0x34 = 4
01100011 = 0x63 = c
01101111 = 0x6F = o
01101011 = 0x6B = k
01100101 = 0x65 = e
01101001 = 0x69 = i

00001010 = 0x0A = \n

El último carácter no hay que tenerlo en cuenta pues es el de 'nueva línea'.

¡Nos vemos en la próxima entrada!

Leviathan Level 3 → Level 4

Parece que este WarGame va de bits suid. Vamos a ver que nos tiene preparado este nive.

Como ya viene siendo habitual, los datos de conexión SSH son:

- Host: leviathan.labs.overthewire.org 

- User: leviathan3

- Pass: Ahdiemoo1j

Y la misma información que la del nivel anterior nada de nada.

Esta vez el fichero es este:

Ahora le hacemos un ltrace a ver que se cuece:

No nos dice demasiado. Nos pide un password y como no ha sido correcto nos muestra un mensaje de error.

Analicemos más en profundidad su diagrama de bloques:

Nos pide el password, y después invoca a la función do_stuff, la cual es:

De ella podemos asegurar que si el password es correcto, nos dará un shell con permisos elevados a leviathan3, en caso contrario mostrará un error como se ha visto anteriormente.

La comprobación del password se hace a través de la instrucción repe cmpsb, es decir byte a byte sobre los registros ESI, EDI y vemos rápidamente que la cadena que contiene el registro EDI es 'snlprintf\n'. Pero si nos fiamos en la captura del ltrace, el carácter de control '\n' lo añade la función _fgets.

Vamos a comprobarlo:

et voilà!

Ahora vamos a repetir el proceso, debido a que en la conexión remota no disponemos de IDA Pro para verlo tan eficientemente, pero si podremos llegar al mismo sitio usando gdb.

Cargamos el binario en el depurador:

Nos informamos de sobre que funciones tiene:

Y por último, desensamblamos la función do_stuff y mostramos el contenido que tendrá el registro EDI:

Y ahora es cuando viene lo mejor. Con un simple comando ¡podríamos habernos evitado todo esto! Pero los que me conocen saben que me gusta ir a las hojas para ver el bosque:

Esto es todo por ahora. ¡Hasta pronto!

Leviathan Level 2 → Level 3

Tengo que reconocer que aunque estos niveles son beginners, este en concreto me ha costado lo suyo hasta que vi como resolverlo.

Comenzamos pues y para ello, los datos de conexión son:

- Host: leviathan.labs.overthewire.org 

- User: leviathan2

- Pass: ougahZi8Ta

Y la misma información que la del nivel anterior nada de nada.

Nos encontramos con otro nivel en donde nos ofrecen un binario con el bit suid activado con permisos de propietario leviathan3.

Si nos fijamos un poco, lo que este binario hace es recibir el nombre de un fichero y hacerle un cat de su contenido. La primera comprobación que se hace es que se tengan permisos de lectura sobre el fichero argumentado y la segunda se ejecuta un comando cat sobre es fichero pero aquí está lo interesante, con elevación de permisos, debido al bit suid.

Pasamos un comando ltrace al binario, argumentándolo con cualquier fichero que tengamos permisos de lectura, para comprobar las suposiciones anteriores:

Con todo ello, estaría bien poder pasar como argumento el fichero que contiene la password buscada en /etc/leviathan_pass/leviathan3, sin embargo esto no es posible puesto que no tenemos permiso de lectura. 

Lo primero que uno piensa es que se podría hacer un enlace simbólico al fichero, pero seguiríamos sin tener permisos, por tanto, toca darle un poco más a la cabeza y entender que el foco de este retos está en esta función:

snprintf("/bin/cat /etc/leviathan_pass/lev"..., 
         511, 
         "/bin/cat %s", 
         "/etc/leviathan_pass/leviathan2")

especialmente en la parte que está agrandada y resaltada en negrita.

Haciendo una búsqueda en Google de 'problemas que existan con el carácter de control %s' pronto descubriremos que los espacios no sientan demasiado bien. hagamos una prueba:




Como se puede observar se gestiona bien el texto hasta que se encuentra un espacio, por tanto, para poder resolver este nivel

necesitamos crear dos ficheros, uno que será el enlace simbólico mencionado anteriormente y otro con el mismo nombre que el enlace, pero añadiéndole algún espacio. De esta manera, se pasará la primera comprobación que se hace referente a tener permisos de lectura, pues la función _access no formatea el nombre del fichero, después la función _snprintf formateará el nombre del fichero al nombre del enlace, pues se quedará con el texto que hay justo antes del primer espacio. De esta manera, al llegar al cat, este nos mostrará la password.

Veamos este proceso en la próxima captura: 

Espero que se entienda bien la idea. ¡Hasta el próximo nivel!