Un blog de Seguridad Informática, desde un punto de vista tecnológico

Más reciente

Write-up del 2º Reto del CTF de la No cON Name 2013

Buenas a todos!

Vamos a cerrar el fin de semana y ésta cadena de posts exponiendo la solución al segundo reto del CTF de las NoConName 2013 que se celebró el pasado fin de semana.

El juego consistía en una aplicación Android (.APK) que debía ser descargada de la pagina oficial del CTF.

Una vez instalada en el emulador o dispositivo, a nuestro pesar observamos que ésta no se ejecutaba correctamente, dando lugar a un error desconocido de entrada.

Rascando los ficheros de log del dispositivo mediante la aplicación CatLog, pudimos observar que algo no funcionaba correctamente en la aplicación, concretamente se mostraba el mensaje de error que se muestra a continuación:

screenshot-1380333703143

Efectivamente, parecía que había algún tipo de error producido por un fichero Manifest.xml mal generado.

Para obtener el fichero Manifest.xml primero hay que decompilar el código fuente de la aplicación. Para ello se utilizó la herramienta APKTOOL:

Una vez instalada la herramienta en el sistema, obtener el decompilado de la aplicación , y consecuentemente el fichero Manifest.xml, ejecutando lo siguiente:

root@bt:~/Desktop# apktool d level.apk
I: Baksmaling...
I: Loading resource table...
I: Loaded.
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /root/apktool/framework/1.apk
I: Loaded.
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Done.
I: Copying assets and libs...
root@bt:~/Desktop#

A continuación se muestra el fichero Manifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest android:versionCode="1" android:versionName="1.0" package="com.facebook_ctf.challenge"
 xmlns:android="http://schemas.android.com/apk/res/android">
 <application android:theme="@style/AppTheme" android:label="@string/app_name" android:icon="@drawable/ic_launcher">
 <activity android:label="@string/title_activity_main" android:name="com.facebook_ctf.challenge.MainActivity">
 <intent-filter>
 <action android:name="android.intent.action.MAIN" />
 <category android:name="android.intent.category.LAUNCHER" />
 </intent-filter>
 </activity>
 <activity android:label="@string/title_activity_main" android:name="com.facebook_ctf.challenge.MainActivity" />
 </application>
</manifest>

Cómo se puede observar, hay dos MainActivity definidas, lo cual ocasiona un conflicto que evita que la aplicación pueda ser iniciada correctamente. Eliminando una de las dos líneas que definen el MainActivity será suficiente para que la aplicación sea ejecutada correctamente.

Una vez modificado el fichero Manifest.xml, hay que volver a recompilar la aplicación. Para ello volvímos a utilizar la herramienta APKTOOL pero ahora además es necesario el empleo de JARSIGNER para generar la firma:

root@bt:~/Desktop# apktool b level-smali level-modified.apk
I: Checking whether sources has changed...
I: Checking whether resources has changed...
I: Building apk file...
root@bt:~/Desktop# java -jar signapk.jar testkey.x509.pem testkey.pk8 ../level-modified.apk ../level-modified-signed.apk

Al instalar de nuevo la aplicación, ya pudimos ver de que se trataba:

screenshot-1380334377050

La aplicación básicamente funciona de la siguiente forma: Dispone de un botón con la etiqueta “Gimme Gimme!” mediante el cual, cuando se hace TAP sobre él, se muestra una imágen en la aplicación. Concretamente en la aplicación original se muestra de forma aleatória una de las imágenes almacenadas en la carpeta resource de la aplicación:

Screen Shot 2013-10-06 at 8.34.46 PMNo hace falta mucha ingeniería inversa para poder comprobar que las imágenes que se muestran son fragmentos de un código QR que, tal como ya os habréis imaginado, habrá que reconstruir. Así que, Let’s go!

Mediante el proceso de decompilado anteriormente mencionado, también se obtiene el código Dalvik de la aplicación que procederemos a comentar a continuación. No obstante, con la finalidad de poder comprender mejor el funcionamiento de la aplicación, antes de meternos en detalle en el código Smali, primero se procedió a pasar el código almacenado en el fichero classes.dex a Java para sacar un poco de luz al asunto.

Para esta tarea se hizo uso de la herramienta DEX2JAR:

  • DEX2JAR – http://code.google.com/p/dex2jar/

El uso de la herramienta es bastante simple. Solamente es necesario descomprimir el fichero APK (p.ej. con el comando unzip) y posteriormente ejecutar lo siguiente con el fichero classes.dex obtenido:

/dex2jar-0.0.9.15/d2j-dex2jar.sh classes.dex

Mediante la ejecución de dicha herramienta, en conjunto con el uso de JD-GUI, fue posible obtener el código fuente en JAVA, donde se pudo observar cómo en la clase MainActivity se pinta la imágen escogida aleatoriamente. Concretamente se realiza en la función “yaaaay()” mediante la variable “localBitmap17”:

int i = new Random().nextInt(localArrayList.size());
   makeMeHappyAgain(makeMeHappy(localBitmap1, localBitmap2, localBitmap3, localBitmap4), makeMeHappy(localBitmap5, localBitmap6, localBitmap7, localBitmap8), makeMeHappy(localBitmap9, localBitmap10, localBitmap11, localBitmap12), makeMeHappy(localBitmap13, localBitmap14, localBitmap15, localBitmap16));
   Bitmap localBitmap17 = (Bitmap)localArrayList.get(i);
   this.secret.setImageBitmap(localBitmap17);

La función “makeMeHappyAgain”, analizando el código se observó que era la responsable de maquetar el código QR correctamente (bueno casi, pero eso lo veremos más adelante :-P), por lo que por el momento, únicamente había que modificar el código Smali para que en lugar de pintar por pantalla la imagen aleatória almacenada en “localBitmap17”, se pintara el resultado de la llamada a la función “makeMeHappyAgain”:

Screen Shot 2013-09-28 at 4.20.42 AM

En la imágen anterior, se puede apreciar cómo se modificó el código Smali original para que en la última llamada al método virtual “setImageBitmap”, en lugar de utilizar el valor “v1”,  se utilizara el valor “v4” que es la variable resultado de la llamada a la función “makeMeHappyAgain”, definido por la  instrucción “move-result-object v4”.

Aunque a simple vista, una vez recompilado el código y ejecutado de nuevo parece ser que el código QR se genera correctamente, realmente no fue así 😦

Hay  dos imágenes que no están correctamente posicionadas, lo cual no nos permitía escanear correctamente el QR y obtener la clave del reto. Para ello hay que hacer otra modificación del código Smali para hacer swap de las imágenes “c.png” (0x7f040002) y “g.png” (0x7f040006). Para obtener la relación entre las imágenes y sus correspondientes  identificadores Hex hay que consultar el fichero “public.xml” almacenado en la carpeta  de los resources (res) de la aplicación.

A continuación se muestra el código resultante de dicha modificación:

Screen Shot 2013-09-28 at 4.22.51 AM

Finalmente, una vez recompilada, refirmada y reinstalada la aplicación se puede observar el código QR generado correctamente:

welldone

Y posteriormente, una vez escaneado, obtuvimos la SECRET KEY del Reto:

screenshot-1380333471692

Solo nos queda felicitar a los 12 equipos que se han clasificado en la final que se celebrará el día 1 de Noviembre en el congreso NoConName 2013:

Screen Shot 2013-10-06 at 8.16.14 PM

……y decir que logramos clasificarnos en 7º posición 😉

Así que nos vemos en la final!

Reto 1 del CTF de las No cON Name 2013

Hola a todos, hola a tothom!

Mi nombre es Ignasi M. (ny4nyi) y he tenido el placer de ser invitado a participar en este blog. Es todo un honor. Espero que todo lo que pueda aportar os sea útil y disfrutéis!

Sobretodo, dar las gracias a Julian y a todo el equipo por darme esta oportunidad de poder participar con gente tan grande.

Ahora, a por materia.

El primer reto del CTF NoConName 2013 consistía en una página web que solicita una clave secreta para superar el reto.

Paso 1

La primera aproximación fue probar un número aleatorio para estudiar el comportamiento normal de la página. Obviamente, se produce un error de “Clave incorrecta” y se sigue en la misma página inicial (ya hubiera sido la ostia acertar a la primera ).

Una vez se conoce el comportamiento estándar de la página, se realizó un estudio del código fuente de la misma, y se encuentra lo siguiente:

   <head>

    <title>NcN 2013 Registration Quals</title>

    <link rel=”stylesheet” href=”../res/main.css” type=”text/css” media=”screen”/>

    <link href=’../res/UbuntuMono.css’ rel=’stylesheet’ type=’text/css’>

    <meta content=”Javier Marcos @javutin” name=”author” />

    <script type=”text/javascript” src=”crypto.js”></script>

  </head>

La página carga un “js” de nombre “crypto.js” que es el responsable de realizar la validación. Resaltar que al tratarse de un “js” se ejecuta en el navegador del cliente, no en servidor. Por lo tanto, el siguiente paso a seguir es realizar un estudio del código del “js” y entender su lógica/funcionamiento para identificar la posible manera de evadir o hallar la clave secreta de forma exitosa.

Se accede al archivo “cryto.js” para obtener su código fuente. Es algo tan bonito como esto:

var_0x52ae=[“\x66\x20\x6F\x28\x38\x29\x7B\x63\x20\x69\x2C\x6A\x3D\x30\x3B\x6B\x28\x69\x3D\x30\x3B\x69\x3C\x38\x2E\x6C\x3B\x69\x2B\x2B\x29\x7B\x6A\x2B\x3D\x28\x38\x5B\x69\x5D\x2E\x73\x28\x29\x2A\x28\x69\x2B\x31\x29\x29\x7D\x67\x20\x74\x2E\x75\x28\x6A\x29\x25\x76\x7D\x66\x20\x70\x28\x68\x29\x7B\x68\x3D\x68\x2E\x71\x28\x30\x29\x3B\x63\x20\x69\x3B\x6B\x28\x69\x3D\x30\x3B\x69\x3C\x77\x3B\x2B\x2B\x69\x29\x7B\x63\x20\x35\x3D\x69\x2E\x78\x28\x79\x29\x3B\x6D\x28\x35\x2E\x6C\x3D\x3D\x31\x29\x35\x3D\x22\x30\x22\x2B\x35\x3B\x35\x3D\x22\x25\x22\x2B\x35\x3B\x35\x3D\x7A\x28\x35\x29\x3B\x6D\x28\x35\x3D\x3D\x68\x29\x41\x7D\x67\x20\x69\x7D\x66\x20\x6E\x28\x38\x29\x7B\x63\x20\x69\x2C\x61\x3D\x30\x2C\x62\x3B\x6B\x28\x69\x3D\x30\x3B\x69\x3C\x38\x2E\x6C\x3B\x2B\x2B\x69\x29\x7B\x62\x3D\x70\x28\x38\x2E\x71\x28\x69\x29\x29\x3B\x61\x2B\x3D\x62\x2A\x28\x69\x2B\x31\x29\x7D\x67\x20\x61\x7D\x66\x20\x42\x28\x39\x29\x7B\x63\x20\x32\x3B\x32\x3D\x6E\x28\x39\x2E\x64\x2E\x65\x29\x3B\x32\x3D\x32\x2A\x28\x33\x2B\x31\x2B\x33\x2B\x33\x2B\x37\x29\x3B\x32\x3D\x32\x3E\x3E\x3E\x36\x3B\x32\x3D\x32\x2F\x34\x3B\x32\x3D\x32\x5E\x43\x3B\x6D\x28\x32\x21\x3D\x30\x29\x7B\x72\x28\x27\x44\x20\x64\x21\x27\x29\x7D\x45\x7B\x72\x28\x27\x46\x20\x64\x20\x3A\x29\x27\x29\x7D\x39\x2E\x47\x2E\x65\x3D\x6E\x28\x39\x2E\x64\x2E\x65\x29\x3B\x39\x2E\x48\x2E\x65\x3D\x22\x49\x22\x2B\x6F\x28\x39\x2E\x64\x2E\x65\x29\x3B\x67\x20\x4A\x7D”,”\x7C”,”\x73\x70\x6C\x69\x74″,”\x7C\x7C\x72\x65\x73\x7C\x7C\x7C\x68\x65\x78\x5F\x69\x7C\x7C\x7C\x73\x74\x72\x7C\x66\x6F\x72\x6D\x7C\x7C\x7C\x76\x61\x72\x7C\x70\x61\x73\x73\x77\x6F\x72\x64\x7C\x76\x61\x6C\x75\x65\x7C\x66\x75\x6E\x63\x74\x69\x6F\x6E\x7C\x72\x65\x74\x75\x72\x6E\x7C\x66\x6F\x6F\x7C\x7C\x68\x61\x73\x68\x7C\x66\x6F\x72\x7C\x6C\x65\x6E\x67\x74\x68\x7C\x69\x66\x7C\x6E\x75\x6D\x65\x72\x69\x63\x61\x6C\x5F\x76\x61\x6C\x75\x65\x7C\x73\x69\x6D\x70\x6C\x65\x48\x61\x73\x68\x7C\x61\x73\x63\x69\x69\x5F\x6F\x6E\x65\x7C\x63\x68\x61\x72\x41\x74\x7C\x61\x6C\x65\x72\x74\x7C\x63\x68\x61\x72\x43\x6F\x64\x65\x41\x74\x7C\x4D\x61\x74\x68\x7C\x61\x62\x73\x7C\x33\x31\x33\x33\x37\x7C\x32\x35\x36\x7C\x74\x6F\x53\x74\x72\x69\x6E\x67\x7C\x31\x36\x7C\x75\x6E\x65\x73\x63\x61\x70\x65\x7C\x62\x72\x65\x61\x6B\x7C\x65\x6E\x63\x72\x79\x70\x74\x7C\x34\x31\x35\x33\x7C\x49\x6E\x76\x61\x6C\x69\x64\x7C\x65\x6C\x73\x65\x7C\x43\x6F\x72\x72\x65\x63\x74\x7C\x6B\x65\x79\x7C\x76\x65\x72\x69\x66\x69\x63\x61\x74\x69\x6F\x6E\x7C\x79\x65\x73\x7C\x74\x72\x75\x65″,””,”\x66\x72\x6F\x6D\x43\x68\x61\x72\x43\x6F\x64\x65″,”\x72\x65\x70\x6C\x61\x63\x65″,”\x5C\x77\x2B”,”\x5C\x62″,”\x67″];eval(function (_0x7038x1,_0x7038x2,_0x7038x3,_0x7038x4,_0x7038x5,_0x7038x6){_0x7038x5=function (_0x7038x3){return (_0x7038x3<_0x7038x2?_0x52ae[4]:_0x7038x5(parseInt(_0x7038x3/_0x7038x2)))+((_0x7038x3=_0x7038x3%_0x7038x2)>35?String[_0x52ae[5]](_0x7038x3+29):_0x7038x3.toString(36));};if(!_0x52ae[4][_0x52ae[6]](/^/,String)){while(_0x7038x3-)_0x7038x6[_0x7038x5(_0x7038x3)]=_0x7038x4[_0x7038x3]||_0x7038x5(_0x7038x3);} ;_0x7038x4=[function (_0x7038x5){return _0x7038x6[_0x7038x5];} ];_0x7038x5=function (){return _0x52ae[7];} ;_0x7038x3=1;} ;while(_0x7038x3–){if(_0x7038x4[_0x7038x3]){_0x7038x1=_0x7038x1[_0x52ae[6]]( new RegExp(_0x52ae[8]+_0x7038x5(_0x7038x3)+_0x52ae[8],_0x52ae[9]),_0x7038x4[_0x7038x3]);} ;} ;return _0x7038x1;} (_0x52ae[0],46,46,_0x52ae[3][_0x52ae[2]](_0x52ae[1]),0,{}));

Como se puede ver, el código del “js” esta ofuscado (lastima, habrá que currar más). Ha de quedar claro que esta ofuscado, NO cifrado.

Si se disecciona el código, a grandes rasgos se puede detectar lo siguiente:

  • Una variable de nombre “var_0x52ae” : Parece ser un vector donde el valor de cada posición está representado en código hexadecimal. Recordar que si un valor se escribe como “\x” significa que se representa en sistema hexa.
  • Una función eval: Definición purista, “Si el argumento es una expresión, eval () evalúa la expresión. Si el argumento es una o más sentencias JavaScript, eval () ejecuta las sentencias.”
  • La definición de funciones: Por ejemplo, “function (_0x7038x1,…)”
  • La llamada de funciones: Por ejemplo, “(_0x52ae[0],46,46,_0x52ae[3])”

Aclarar que en las definiciones de las funciones se ven nombres de parámetros tal que “_0x_7038x1” pero se desconoce su valor. Esto es porque en una declaración de función se puede dar cualquier nombre al parámetro, que luego éste recibirá el valor del parámetro usado en la llamada. En resumen, cuando se llame a la función, el valor del parámetro será el siguiente:

_0x7038x1=_0x52AE[0]=”\x66…..\7D”.

Paso 2

Para desofuscar el código js se pueden utilizar diferentes recursos online en la red, o simplemente, modificar la función “eval” por una función “alert” que se encargara de imprimir en una ventana la representación del código sin ofuscar, ya que interpretara todos los valores hexadecimales posibles como caracteres.

El resultado es el siguiente:

Imagen

El código sin ofuscar es:

Function simpleHash(str) {

var i, hash = 0;

for (i = 0; i < str.length; i++) {

hash += (str[i].charCodeAt() * (i + 1))

}

return Math.abs(hash) % 31337

}

 function ascii_one(foo) {

foo = foo.charAt(0);

var i;                              

for (i = 0; i < 256; ++i) {

var hex_i = i.toString(16);

if (hex_i.length == 1) hex_i = “0” + hex_i;

hex_i = “%” + hex_i;

hex_i = unescape(hex_i);

if (hex_i == foo) break

}

return i

}

 function numerical_value(str) {

var i, a = 0,

b;

for (i = 0; i < str.length; ++i) {

b = ascii_one(str.charAt(i));

a += b * (i + 1)

}

return a

}

function encrypt(form) {

var res;

res = numerical_value(form.password.value);

res = res * (3 + 1 + 3 + 3 + 7);

res = res >>> 6;

res = res / 4;

res = res ^ 4153;

if (res != 0) {

alert(‘Invalid password!’)

} else {

alert(‘Correct password :)’)

}

form.key.value = numerical_value(form.password.value);

form.verification.value = “yes” + simpleHash(form.password.value);

return true}

Paso 3

La lógica general de este código es la siguiente:

  1. La función “numerical_value” recibe el valor o cadena “X” que introduce el usuario en la página web y retorna un valor resultado que es la suma de cada carácter de la cadena X en su correspondiente valor decimal ASCII multiplicado por el resultado de la suma del valor de la posición del carácter en la cadena X +1
  2. La función “encryp” se encarga primero de aplicar varias operaciones sobre el valor retornado por la función “numerical_value” y después compara este valor “final” con 0. Si la comparación es cierta, el password (cadena “X”) introducida por el usuario es correcta.
  3. Estudiando con más detalle la función “encrypt” se determina que el valor “final” ha de estar entre el siguiente rango de valores :62540-62554.

Ya con esta información clara el último paso es introducir, mediante técnicas de “brute forcing”, una cadena de valores/caracteres que después de ser tratada por la función “numerical_value” de un valor que pertenezca al rango deseado.

En este caso se encontró la siguiente cadena:

ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZNR

Se introdujo esta cadena en la página web y tachan!:

Congrats! you passed the level! Here is the key:

23f8d1cea8d60c5816700892284809a94bd00fe7347645b96a99559749c7b7b8

Twitter: @Ny4nyi

Bypassing iOS 7 lockscreen with Siri

Hola a todos,

mi nombre es Álex Soler y he tenido el placer que ser invitado a aportar todo lo que pueda y más a la comunidad de (in)seguridad a través de este blog. Así que espero no decepcionaros 🙂

A raíz de las múltiples vulnerabilidades de bypass del lock screen que tanta fama han ganado en las distintas versiones de iOS publicadas, se nos ocurrió estudiar este fenómeno más en detalle y comprobar qué grados de libertad ofrece una vulnerabilidad de este tipo.

Para empezar a calentar, procedimos a analizar las últimas vulnerabilidades de bypass publicadas en la primera release de iOS 7, concretamente las que hacen referencia a los identificadores CVE-2013-5160 y CVE-2013-5161.

La primera vulnerabilidad (CVE-2013-5160) permite que cualquier persona con acceso al dispositivo pueda realizar llamadas sin conocer el código de desbloqueo del mismo. mediante el uso de la funcionalidad de llamadas de emergencia.

La segunda vulnerabilidad (CVE-2013-5161) permite acceder a las fotos realizadas mediante una combinación de teclas realizada en la vista “Temporizador”. Concretamente consiste en habilitar la vista en la que aparece la opción “Apagar” y posteriormente cancelarlo a la vez que se presiona dos veces el botón “Home”, cómo si quisiéramos abrir el listado de aplicaciones abiertas en el dispositivo. A continuación se abrirá la vista del listado de aplicaciones abiertas y se permitirá acceder a información personal del teléfono cómo por ejemplo las fotos o los contactos.

Vamos a centrarnos en la segunda para lo que realmente precede en la presente entrada de blog. En el siguiente vídeo puede observarse cómo se explota la vulnerabilidad mencionada:

En el anterior vídeo se puede observar cómo es posible acceder tanto a las fotos como a los contactos como bien prometía la descripción de la vulnerabilidad, no obstante, cabe destacar tal como se observa en el vídeo que aunque sí se dispone de acceso a la agenda de contactos, no es posible acceder a los respectivos números de teléfono.

Pero esto no nos supone un problema, en este caso podremos recurrir a nuestra gran amiga/amante en el mundo iOS: SIRI.

 siri

Curiosamente muchos usuarios de iPhone hacen uso de esta magnífica funcionalidad que permite hacer uso de nuestro dispositivo sin ni siquiera tocar una tecla. Algunos ejemplos indicados en la propia ayuda son los siguientes:

  • Abre Fotos
  • Abrir aplicación Contactos
  • Abre Fotos
  • Llamar
  • Etc…

Algunas funcionalidades del Siri, como por ejemplo acceder a la aplicación contactos o ver los correos, te piden el correspondiente código PIN. No obstante, como es de suponer, otras no.

En el siguiente vídeo, se puede observar cómo es posible acceder a la agenda (incluídos los números de teléfono) a través de Siri. El truco consiste en nombrar una cadena de texto que se encuentre dentro de un contacto existente en la agenda. (por ejemplo, la cadena “No Se” haría referencia a contactos como “Sergio”):

En la versión de iOS 6, el acceso a los contactos se rige al puro estilo “Brute Force”, probando cadenas que estén contenidas en los contactos e ir llamándoles para obtener sus números. En cambio en la versión de iOS 7 la tarea es mucho más simple, dado que a través del botón “Otros” podremos acceder a la agenda al completo.

Recientemente ya se ha reproducido el mismo problema mediante otras técnicas de Bypass combinadas con el uso de Facetime:

http://thehackernews.com/2013/09/another-iphone-lockscreen-bypass.html

Cómo solución a este tipo de problemas, lo más sensato es deshabilitar el uso de Siri en el screen lock como se muestra a continuación, algo que personalmente pienso debería estar deshabilitado por defecto:

photo

Así que, ¿Seguís confiando en Siri?

CTF de la No cON Name 2013 (write-up)

Buenas a todos,

después de algún tiempo sin nuevas entradas en el blog, hemos pensado que una buena forma de regresar sería publicando nuestras soluciones a los retos de la ronda clasificatoria del primer CTF que se organiza en las conferencias No cON Name, en este año 2013.

Esta ronda de clasificación ha consistido en la resolución de un juego de estilo “Jeopardy”, consistente en 3 niveles. El primero de ellos relacionado con Web, el segundo con Android y el tercero con reversing de binarios.

Imagen

 

En este post describiremos cómo solucionamos el nivel 3, en el que se entregaba un binario de tipo ELF de 64 bits. Al ejecutarlo mostraba lo siguiente:

De forma que al escribir, el programa finalizaba indicando el siguiente mensaje:

Para resolver el desafío hicimos un desensamblado del binario, y analizamos su comportamiento. En primer lugar el programa imprimía por pantalla el texto que hemos podido ver anteriormente:

Imagen

 

A continuación entraba en un bucle de 10 iteraciones, en el que se van leyendo los caracteres introducidos por el usuario y se comparan con el contenido de la variable “facebookctf_rocks”. Esta variable es un array de DWORDs, en las que el byte más significativo de cada DWORD contiene el valor que va a comparar con el carácter introducido por el usuario, y los otros 3 bytes de la DWORD son ceros.

Imagen

 

El contenido de la variable “facebookctf_rocks” es el siguiente:

20 00 00 00

53 00 00 00

55 00 00 00

52 00 00 00

50 00 00 00

52 00 00 00

49 00 00 00

53 00 00 00

45 00 00 00

21 00 00 00

Y teniendo en cuenta lo explicado anteriormente, se corresponde con la cadena “\x20\x53\x55\x52\x50\x52\x49\x53\x45\x21”, o lo que es lo mismo ” SURPRISE!” (con un espacio al principio). 

Si introducimos esa cadena, el programa muestra el siguiente mensaje:

 

Una forma alternativa de obtener la clave (sin introducir el texto), es analizar la parte final del binario, en la que se aprecian tres caminos diferentes: que se haya presionado la tecla de salida (call seeyaaaa), que se haya introducido un carácter que no es el esperado (call game_over), o que se haya introducido la cadena esperada (call success).

Imagen

 

Por lo que si debugueamos el programa y modificamos el EIP por la dirección de memoria donde se llama a la función “success” (0x000000000040117B), obtendremos el mismo resultado. 

En breve publicaremos la solución de los otros 2 niveles 🙂

Saludos!!

SOURCE Barcelona 2011 – Parte 2

Continuando con lo explicado por Juan, os cuento acerca de las charlas en las que estuve presente:

Wfuzz para Penetration Testers

Christian Martorella y Xavier Mendez, de Verizon Bussiness (y de edge-security), nos explicaron ejemplos prácticos de uso de la herramienta Wfuzz: básicamente una herramienta para realizar bruteforcing en aplicaciones Web. Probablemente a muchos de vosotros ya os suene esta herramienta (de hecho no es nueva), que lleva formando parte del arsenal de herramientas de Backtrack desde hace ya algunas ediciones.

La charla se orientó a las mejoras que han incluido recientemente en la herramienta (y que presentaron en el Blackhat Arsenal USA de este año), entre las que destaca la inclusión de un framework para scripting y mejoras en el rendimiento de la herramienta (hablaron de un 60% de mejora, llegando a rates de 900 peticiones por segundo).

Algunas indicaciones básicas acerca de la herramienta:

  • Permite bruteforcing en diferentes puntos de entrada de la aplicación Web, tales como parámetros, cabeceras, recursos, formularios, etc.
  • Se basa en el uso de Payloads (fuentes de datos como ficheros, la entrada estándar, rangos, nombres, etc.), Encoders (codificación de los Payloads en múltiples formatos como URL encoding, URL encoding doble, etc.), Iteradores (controlan la estrategia de fuzzing a utilizar), Printers (formatos para la salida de resultados) y, como novedad, los Plugins.
  • Permite la creación de baselines, para luego poder esconder valores que formen parte de la misma y así detectar anomalías más rápidamente.

Y ahora las partes que más me gustaron o que me parecieron más relevantes en la presentación:

  • Es una herramienta “artesanal”, potente y útil en la realización de pentesting, pero que requiere de conocimiento por parte de quien la esté utilizando. NO es un escáner de vulnerabilidades Web.
  • Se puede integrar con la herramienta Magictree (lectura de página y vídeo de ejemplo recomendados), permitiendo retroalimentar resultados. Es decir, los resultados que tengamos cargados en Magictree (que pueden provenir de otras herramientas) pueden ser nuevos objetivos para Wfuzz, quien además puede exportar los resultados de nuevo a Magictree.
  • Permite realizar password guessing siguiendo diferentes aproximaciones: Scan Vertical, Horizontal, Diagonal, Tres y Cuatro Dimensiones, etc. (terminología empleado por Robert “Rsnake” Hanson en su libro).
  • Existen plugins ya disponibles para, por ejemplo, algo tan útil como tomar screenshots de las Webs que cumplan con las condiciones que establezcamos para el fuzzing.

Para profundizar más podéis ver las slides de la presentación, y trastear con la herramienta 😉

Advanced (Persistent) Binary Planting

Esta charla impartida por Mitja Kolsek, personalmente me gustó mucho. En ella se habló acerca del Binary Planting, que para los que no conozcáis el término, comentaros que hace referencia a una vulnerabilidad que ya tiene algo de tiempo y que se reavivó a mediados del 2010 por algunos nuevos vectores de explotación de la misma. Básicamente reside en el mecanismo de carga de librerías de forma dinámica por parte de aplicaciones.

Uno de los puntos fuertes de la charla es que fue muy práctica, y se mostró que encontrar aplicaciones vulnerables aun es factible a día de hoy. Mitja nos mostró como utilizando el Proccess Explorer de las Sysinternals, encontrar bugs de este tipo era una tarea casi para todos los públicos :).

Y qué comenta la charla acerca de la persistencia? Pues una estrategia bastante original:

  • Los navegadores Web más utilizados en plataformas Windows, por defecto descargan los archivos a la carpeta de “Descargas”
  • Si nos bajamos un instalador (pe. el instalador de la Java Virtual Machine) a la carpeta de descargas, esta carpeta será considerada por el SSOO como su carpeta de instalación, por lo que cualquier librería que quiera cargar el binario de forma dinámica será buscada primero en este directorio (independientemente del current working directory)
  • Algunos navegadores (pe. Chrome) son vulnerables a ataques de clickjacking para la descarga de archivos! Es decir, podríamos engañar a la víctima (usuaria de Chrome) mediante algún juego, consiguiendo que sin darse cuenta se descargase algún archivo .dll o .exe a la carpeta de “Descargas”, que pudiera ser utilizado en un futuro por algún instalador que cargase una librería con ese nombre.

Hown NOT to do a Penetration Test

Esta charla, de carácter más teórico, fue impartida por Stefan Friedli, impulsor del Penetration Testing Execution Standard (PTES). Una metodología para planificar, gestionar y ejecutar un Pentest.

Stefan Friedli en Sourceconference Barcelona 2011

Algunos de los comentarios de Stefan fueron:

  • “una compañía que no realiza ninguna tareas de seguridad no realiza un pentest, necesita primero arreglar su situación”
  • “una forma para discriminar un buen pentester de un no tan buen pentester puede ser el hecho de que utilice alguna metodología, como PTES”
  • “es importante la definición de un correcto alcance en un pentest, pues a una compañía le importarán más aquellas cosas que puedan afectar a su negocio”
  • “es importante que los pentesters no se centren únicamente en la explotación de vulnerabilidades, existen otras tareas importantes en la ejecución de un pentest.

Una charla interesante que generó algo de debate, acerca de los umbrales de calidad y lo que al final los clientes finales suelen valorar más (el precio).

La verdad es que las conferencias estuvieron muy bien, el lugar en el que se celebran excelente, y como siempre el ambiente muy agradable. Esperemos poder repetir para el año que viene 😉

Un saludo!

SOURCE Barcelona 2011 – Parte 1

Después de haber podido pasar un rato en las SOURCE de Barcelona, tengo que decir que  ha sido una experiencia muy muy recomendable, charlas de buena calidad, en un entorno relajado y donde las horas se pasan rápido! Un entorno ideal para disfrutar de la seguridad y aprovechar para compartir un momento con buena gente!

Y ahora si, repaso de algunas de las charlas, pertenecientes a la tarde del miércoles 16 de noviembre.

Metasploit: Hacker’s Swiss Army Knife

Charla super dinámica, de Jonathan Cran (Rapid7) y Joshua Smith (JHUAPL), en la que se hizo un repaso de la arquitectura de metasploit y, posteriormente, se vieron toda una serie de casos prácticos para sacarle el máximo partido a Metasploit!

Se vieron desde las diferentes posibilidades que ofrecen los “resource files” para la automatización de tareas hasta la creación de un bot para IRC para controlar metasploit vía RPC!

Una charla super entretenida, y muy muy valiente, en la que se se prepararon diferentes demostraciones para enseñar en directo! Por cierto, en el siguiente repositorio de jcran podéis encontrar algo de los materials de la conferencia, muy recomendable echarle un ojo: https://github.com/jcran/source_barcelona_2011/

RESTful Services, the Web Security Blind Spot

Ofer Shezaf (Hewlett Packard) repasa los servicios RESTful, sus características y peculiaridades, así como las consideraciones a tener en cuenta a la hora de revisar la seguridad de este tipo de servicios Web, y algunas ideas para automatizar (fuzzing) la revisión de éstos.

Charla esta vez más teórica, donde, eso sí, los contenidos se explicaron de una manera muy clara.

Security Goodness with Ruby on Rails

Desde el “spanish track”, Daniel Pélaez (Gotham Digital Science) hizo un repaso (mucho más que un repaso!!!) de la tecnología Rails, repasando el paradigma MVC para el desarrollo de aplicaciones Web, algunos detalles de la implementación concreta de Rails y después, seguridad seguridad y seguridad en Rails 🙂

Se explicaron desde vulnerabilidades más específicas de estos entornos, por ejemplo, “mass-assignments” hasta como afectan vulnerabilidades más tradicionales en entornos Web como Cross-Site Scripting o SQL Injection.

Un punto muy fuerte de la charla es que no se conformó con ver como romper aplicaciones Rails, sino que también se repasaron las salvaguardas que ofrece el entorno Rails para evitar diferentes tipos de vulnerabilidades, así como plug-ins de terceros para implementar características relacionadas con la seguridad como la autenticación o la autorización de la aplicación . Lo dicho, una charla muy muy completa!

Configurar Huawei HG556a de Vodafone como punto de acceso (AP)

Antes de nada disculparme porque os debo un post acerca de la configuración de un laboratorio casero, pero como apliqué bastantes cambios a la configuración que tenía estoy esperando a tener algo definitivo para contároslo ;). Para ir haciendo boca, os comento un problema que he tenido y cómo lo he solucionado:

Mi conexión a Internet es por cable (OÑO), y mi conexión vino con un “fantástico” router WiFi WebStar EPR 2320. Como veréis si hacéis algunas búsquedas por Internet, no tiene muy buena reputación. A mí, como a mucha gente, me daba problemas con la tabla de NAT (PAT), de modo que cuando abría varias pestañas del navegador que accedían a páginas con Ads (que suelen tener múltiples enlaces), el cacharro se desbordaba y la conexión a Internet dejaba de funcionar correctamente (probablemente por saturación de la tabla de traducción de red/puertos).

Más adelante os explicaré con más precisión el problema, porque la topología utilizada también contribuía en el problema (utilizaba la funcionalidad de DMZ Host) y contribuyó en la elección de la solución: poner el router en modo Bridge, dejar que gestionase el NAT un dispositivo más potente y colocar un Access Point para conectarme a la WiFi.

Simplificando, imaginaos que tenéis una conexión a Internet con un router que no tiene WiFi, y que por los motivos que sean no queréis suprimirlo. En ese caso podéis añadir un Access Point en la LAN cableada del router y así dar acceso a clientes WiFi. Pues bien, en mi caso no tenía un punto de acceso, pero sí un router WiFi de Vodafone Huawei HG556a.

En este post quiero explicaros como configurar en HG556a como Access Point, en una topología como la mencionada.

Topología de ejemplo

En primer lugar habréis de acceder al HG556a (en adelante AP) con privilegios de administración (encontraréis información de como hacerlo por Internet).

Después configurar la LAN del AP con el mismo direccionamiento que tenéis en vuestra red cableada (en el ejemplo 172.X.X.0/24) y, importante,  deshabilitar el DHCP del AP. ¿Por qué? Pues porque sino tendréis problemas porque se pondrá a sí mismo como Default Gateway (el AP con dirección 172.X.X.2) y cuando intentemos acceder a una página con el navegador, el AP la reemplazará por una en la que muestra un error por no estar en funcionamiento el ADSL.

Configuración de LAN

LAN AP

Después activamos como puerta de enlace el router conectado a Internet.

Configuración de routing para LAN

Configuración routing

Y acto seguido hemos de configurar la interfaz WAN para que actúe como modo bridge, que habrá de quedar de la siguiente forma:

Única conexión WAN

Conexión WAN

Para ello seguimos los pasos mostrados a continuación:

Datos configuración WAN

Configuración parámetros ADSL

Selección modo puente

Configuración en modo puente

Activación servicio de puente

Activación del servicio de puente para datos

Configuración WAN como puente en LAN

Configuración WAN como puente en LAN

Y ya está casi todo hecho. El siguiente paso es conseguir que los usuarios que se conecten por WiFi al AP reciban una dirección IP y, para ello, vamos a utilizar el router que está conectado a Internet (que probablemente ya tenía un servidor DHCP activado). Este router habrá de responder a las solicitudes DHCP identificándose a sí mismo como el Default Gateway para los clientes WiFi (en la topología de ejemplo esto significa que el Default Gateway para los clientes WiFi habría de ser la dirección 172.X.X.1).

El problema es que el AP no hace relay de las solicitudes y respuestas DHCP entre la red cableada y la inálámbrica, y tampoco dispone de ninguna funcionalidad para activarlo.

En este punto podemos realizar el siguiente truquillo: primero descargamos el fichero de configuración del router

Hacer backup de la configuración del AP

Funcionalidad de backup del AP

Lo abrimos con un editor de texto y buscamos la cadena “dhcpRelay”, que por defecto tomará un valor de “0”. Cambiando el valor por “1”, ya tendremos la posibilidad de que el router conectado a Internet haga de servidor DHCP para los clientes WiFi conectados al AP.

Modificación de dhcpRelay en fichero de configuración

Fichero de configuración

Para ello subimos el fichero de configuración modificado

Subida de fichero de configuración modificado

Funcionalidad de actualizar configuración

Y ya debería funcionar nuestro router WiFi convertido en AP!

Espero que os sea de utilidad 😉

SOURCE Barcelona 2011

En primer lugar disculparnos por esta temporada de sequía de posts, pero ya sabéis, con la que está cayendo ahí fuera a veces el trabajo no te deja demasiado tiempo para más.

Volvemos con ilusión renovada para informaros de que la próxima semana tendrán lugar las SOURCE Barcelona 2011, y que Testpurposes.net estaremos allí! 😉

El schedule comienza con trainings los días 14 y 15, y las ponencias el 16 y 17 de Noviembre. Este año con la novedad de disponer de un track totalmente en castellano con excelentes ponentes, a los que queremos apoyar a tope!

SOURCE

Os animamos encarecidamente a que vayáis ya que, según nuestra experiencia en ediciones anteriores, podréis disfrutar de una organización excelente, unas charlas de calidad y, en general, un ambiente excepcional. Para los que no podáis ir, desde Testpurposes.net haremos seguimiento de las diferentes charlas.

Podéis informaros de los horarios y demás en la página oficial:

Recordad que si sois estudiantes, o si sólo estáis interesados en asistir al track en castellano, disponéis de opciones de registro con un coste más asequible. Asimismo desde la comunidad DragonJAR se ofrece un suculento descuento del 25% si no tenéis aun la entrada comprada.

Esperamos veros allí!

BlackHat Europe 2011 – Resumen de Charlas (Parte III)

Buenas gente,

mi turno! 🙂

antes de nada me gustaría hacer una valoración general del evento: ha sido muy positivo, pero con muy poca presencia nacional! No sabemos si ha sido porque las Rooted CON fueron hace muy poquito, si es porque este año ya no ha sido novedad que se celebrasen en nuestro pais o simple casualidad, pero se podían contar con las manos a los paisanos 😦

También me gustaría enviar un fuerte abrazo a nuevos amigos de Argentina que tuvimos la oportunidad de conocer: Sebastian y Alfredo de Groundworks Technologies (que como ya ha comentado Pau dieron una brillante charla) y unos cuantos amigos más de Core (tenía una foto con Federico Muttis y la chica “anonymous” 😉 pero no la encuentro :P). Grandísimos!

Y ahora sí vamos a las charlas:

Día 1

[Application Dissection] The ABAP Underverse – Risky ABAP to Kernel communication and ABAP-tunneled buffer overflows / Andreas Wiegenstein

Personalmente esta charla me gustó mucho, ya que toca una temática que llevo un tiempo investigando: la seguridad en SAP. En concreto trató de vulnerabilidades en el lenguaje de programación utilizado en este sistema, conocido como ABAP.

Acerca de ABAP (Advanced Bussiness Application Programming):

  • Es un lenguaje propietario, y sus especificaciones completas no están disponibles
  • Es independiente de la plataforma (bytecode sobre ABAP Runtime)
  • La comunicación entre sistemas SAP se realiza mediante RFC (Remote Function Call)
  • El control de versiones y el sistema de transporte (entre entornos de desarrollo, QA, Producción) están integrados
  • Utiliza OpenSQL para el acceso a back-end (independiente del back-end utilizado)

Cosas muy interesantes explicadas durante la charla:

  • ABAP es un lenguaje susceptible a vulnerabilidades de tipo inyección SQL
  • En ABAP se puede inyectar código estático y ejecutarlo posteriormente
  • En ABAP se puede inyectar código dinámico y ecutarlo posteriormente (además este código se ejecuta on-the-fly y no quedan trazas)
  • El código ABAP customizado puede evadir restricciones de seguridad del estándar de SAP (p.e. el sistema de autorizaciones está disponible para su uso pero no es implícito)
  • ABAP es vulnerable a desbordamientos de buffer

Durante la charla se mostraron DEMOS de una inyección SQL que consultaba información en todos los mandantes, de inyección de código y de ruptura del servicio mediante la explotación de un desbordamiento de buffer.

[Keynote] Cyberwar/ Bruce Schneier

El archi-conocido Bruce Schneier nos habló de su visión y reflexiones acerca de la ciberguerra, así de cómo está afectando el creciente uso de este término en los gobiernos de las grandes potencias.

Os dejo los conceptos que más me gustaron:

  • El principal problema de la ciberguerra es que es un término que no está claramente definido
  • En la guerra tradicional, los gobiernos de las naciones tienen el control. La ciberguerra puede ser iniciada por ciudadanos
  • Es difícil saber quién te ataca y cómo, por eso es difícil protegerse
  • En la ciberguerra, el principal objetivo es controlar (por ejemplo como hace un APT), y el peor objetivo es destruir
  • Las tecnologías actuales dificultan la interceptación de las comunicaciones para los gobiernos, y por tanto para las labore de inteligencia. Es más fácil pinchar un teléfono que controlar todas las comunicaciones que puedan realizarse vía Internet (p.e. Skype, el chat de Second Life, etc.)
  • Un país es tan vulnerable en la ciberguerra como dependiente es del ciberespacio. Evidentemente los países más desarrollados suelen ser los más vulnerables.

Ya podéis ver el vídeo y comentar lo que queráis 😉

BlackHat Europe 2011 – Resumen de Charlas (Parte II)

Ya se ha acabado la experiencia BlackHat Europa 2011. Si tengo que resumir mi experiencia, que además es parcial, solo puedo decir: ¡muy recomendable! Sin duda, para repetir. Tanto por la exposición de contenidos de las charlas como por la gente que se tiene la oportunidad de conocer! Increíble 🙂

Tuve la oportunidad de asistir a dos charlas que me parecieron super interesantes a nivel de contenidos y muy bien llevadas a nivel de exposición:

  • “Escaping from Microsoft Windows Sandboxes” de Tom Keetch
  • “Building Custom Disassemblers” de Felix ‘FX’ Lindner

A continuación un resumen de ambas, y lo dicho, muy recomendable la lectura de los materiales a medida que se vayan publicando en el site de blackhat!

Escaping from Microsoft Windows Sandboxes

Interesante charla en la que se han repasado las opciones que ofrece el sistema operativo Windows para ofrecer sandboxing en espacio de usuario:

  • Restricted access tokens
    • Deny-Only SIDs (Discretionary)
    • Low Integrity (Mandatory)
    • Privilege Stripping (Capability)
  • Job Ojbect Restrictions
  • Windows Station Isolation
  • Desktop Isolation

A continuación, se han repasado y comparado las sandboxes de diferentes productos, concretamente:

  • Protected Mode Internet Explorer: Basado en el uso de “Low Integrity Levels”
  • Adobe Reader X: Un subconjunto del framework de sandboxing proporiconado por Google Chromium
  • Google Chromium: Ofrece la implementación más completa de las tres, ofreciendo un framework para proporcionar sandboxing con las diferentes técnicas ofrecidas por el sistema operativo Windows.

Y, finalmente, no podía haber sido de otra manera, Tom ha repasado algunas de las técnicas existentes para saltarse el sandboxing proporcionado por las facilities de Windows:

  • BNO Namespace Squatting
  • NPAPI Interface Exploits (Explotación de vulnerabilidades en plug-ins para saltarse el sandbox)
  • Handle Leaks
  • Clipboard Attacks

Building Custom Disassemblers

Gran trabajo presentado por Felix ‘FX’ Lindner, en el que repasa diferentes aspectos sobre el diseño e implementación de un desensamblador, en este caso para “S7”, aunque utilizando un enfoque genérico y discutiendo técnicas a tener en cuenta a la hora de desarrollar un desensamblador para un bytecode.

Durante la charla además, se presenta la API que IDA para el desarrollo de un módulo que permita soportar un nuevo bytecode, y se repasa algunas “particularidades” 🙂 que se han encontrado durante el desarrollo del modulo para soportar el desensamblado de S7.

Además del proceso de desarrollo del mencionado desensamblador, durante la charla también se comentan aspectos interesantes acerca del análisis de las rutinas utilizadas por Stuxnet, a partir del desensamblador construido para S7. En definitiva, una presentación super completa y una exposición, en mi opinión muy acertada!