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.

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:
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:

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
[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.


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 ;)

viernes, 30 de octubre de 2015

Sincronización de tiempos en Microsoft

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

[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.

miércoles, 28 de octubre de 2015

Sincronización de tiempos en Fedora / Ubuntu

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

[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:

[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 :


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.

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.

$ ./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.

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.

¿Bailamos "Pentesteamos"?

Más información sobre el SEC-660 AQUÍ.
Más información sobre otros cursos y precios AQUÍ.

viernes, 20 de febrero de 2015

De Case-Insensitive a RCE

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.

jueves, 5 de febrero de 2015

An IE Same Origin Policy Bypass story

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.