Hacía tiempo que quería hacer algunos cambios en el blog, y hoy he encontrado un hueco para hacerlo.
Se han migrado los posts en Inglés a GitHub Pages, pero no los blogs en Español, que quedarán en este blog a modo de consulta.
Los nuevos posts se pondrán solamente en Inglés (en principio) y en el dominio habitual https://www.pentester.es
domingo, 2 de junio de 2019
martes, 14 de noviembre de 2017
Undo Five/Nine (Crypto 300, Lisbon CTF)
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}
$ 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 :)
lunes, 19 de diciembre de 2016
Ataques Evil-Maid con Hibernación
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.
miércoles, 17 de febrero de 2016
Inyección de comodines SQL en búsquedas de tipo LIKE
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:
Que muestra un texto extraído de una BBDD mediante una sentencia SQL como la siguiente:
En vez de usar la forma simple:
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:
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):
Podemos fácilmente hacer lo siguiente para obtener un listado de todos los usuarios disponibles:
…
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:
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:
Si queríamos acceder a alguna sesión en concreto solo teníamos que hacer un barrido:
…
¿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:
Equivale a:
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.
martes, 26 de enero de 2016
Herramientas de ayuda para Delorean
Pégale un vistazo a otros posts de esta serie:
[1] NTP MitM con Delorean
[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.
[1] NTP MitM con Delorean
[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:
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.
lunes, 25 de enero de 2016
Otros ataques usando Delorean
Pégale un vistazo a otros posts de esta serie:
[1] NTP MitM con Delorean
[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.
[1] NTP MitM con Delorean
[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.
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.
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.
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.
miércoles, 4 de noviembre de 2015
Atacando la Infraestructura de Clave Pública
Pégale un vistazo a otros posts de esta serie:
[1] NTP MitM con Delorean
[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.
[1] NTP MitM con Delorean
[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.
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".
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.
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.
¡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...
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.
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:
lunes, 2 de noviembre de 2015
Atacando HTTP Strict Transport Security
Pégale un vistazo a otros posts de esta serie:
[1] NTP MitM con Delorean
[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.
[1] NTP MitM con Delorean
[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.
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.
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 ;)
viernes, 30 de octubre de 2015
Sincronización de tiempos en Microsoft
Pégale un vistazo a otros posts de esta serie:
[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.
[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.
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.
/* 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.
miércoles, 28 de octubre de 2015
Sincronización de tiempos en Fedora / Ubuntu
Pégale un vistazo a otros posts de esta serie:
[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:
[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:
martes, 27 de octubre de 2015
Sincronización de tiempos en Mac OS X
Pega un vistazo a los otros posts de esta serie:
[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,
[4] Sincronización de tiempos en Microsoft
[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 :
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.
miércoles, 21 de octubre de 2015
NTP MitM con Delorean
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.
[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.
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.
martes, 8 de septiembre de 2015
SANS SEC-660: "Advanced Penetration Testing, Exploit Writing and Ethical Hacking" en Madrid
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.
Más información sobre el SEC-660 AQUÍ.
Más información sobre otros cursos y precios AQUÍ.
Suscribirse a:
Entradas
(
Atom
)
.png "English"){kind=small}
Entradas
