Atacando la Infraestructura de Clave Pública

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

[1] NTP MitM con Delorean

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

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

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

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

[7] Otros ataques
[8] Herramientas de ayuda

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

$ generate.sh
#!/bin/bash

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

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


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