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