viernes, 18 de febrero de 2011

Rompiendo SSL al estilo gubernamental.

Actualmente SSL es el protocolo utilizado cuando se quiere asegurar las comunicaciones con una web, ya que provee de dos importantes funcionalidades. La primera es el cifrado, impide que los datos que enviamos y recibimos puedan ser legibles por terceros que pudieran estar espiando nuestras comunicaciones. La segunda y no menos importante es el uso de certificados que nos garantizan que en el otro extremo de la comunicación esta quien dice ser. De poco sirve cifrar nuestras comunicaciones con pongamos por ejemplo www.mibanco.com si en realidad estamos hablando con un ciber-ladrón que se hace pasar por el nuestro banco.


Como cualquier protocolo de seguridad pueden existir muchos interesados en romperlo: los ciber-ladrones pueden estar interesados en ver nuestras claves o nuestras transacciones bancarias, un gobierno poco democrático podría querer leer las comunicaciones de los disidentes en Facebook (que ofrece la posibilidad de conectar mediante SSL), un servicio de inteligencia puede necesitar comprometer a un usuario de una VPN SSL corporativa, mientras que las fuerzas y cuerpos de seguridad de los estados pueden necesitar hacer lo equivalente con un webmail SSL utilizado por terroristas o delincuentes organizados.

A lo largo de los últimos años se han ido publicando algunas posibles vulnerabilidades en el uso de SSL, desde la posibilidad de ataque criptográfico si se emplean algoritmos débiles (como el caso de las colisiones MD5) al engaño a los usuarios simplemente eliminado SSL de la ecuación (sslstrip).

Existe un tipo de ataque particularmente eficaz y que estaría en principio solo al alcance de los servicios de inteligencia, policía, etc. lo que se llamaría nivel gubernamental. Se trata de la posibilidad de forzar a las autoridades de certificación a emitir certificados “falsos”, aunque perfectamente validos, que permitan interceptar las comunicaciones en las que sean usados.

En el núcleo de la funcionalidad de autenticación de SSL, está el uso de certificados, esto es la llave pública está firmada digitalmente por un tercero que garantiza la identidad del propietario de la llave. Los encargados de firmar los certificados son las autoridades de certificación, CA, una entidad de confianza, normalmente una empresa responsable de emitir y revocar los certificados digitales. Los navegadores solo aceptan como confiables los certificados que provienen de CA que aparecen en su lista de entidades reconocidas. Un certificado que está firmado por una entidad no reconocida produce un error en el navegador que alerta al usuario, lo que impide teóricamente la suplantación. El problema es que dependiendo del navegador que usemos la cantidad de CA aceptadas se eleva a más de 200, y están repartidas por todo el mundo.



Pongamos como ejemplo a Facebook, como muestra la captura actualmente el su certificado está garantizado por Digicert, una empresa con sede en Utah, EEUU. Pero nada impide que por ejemplo E-TUGRA una CA ubicada en Ankara, Turquía emitir un certificado que sería igual de valido y aceptado por los navegadores.

Si un servicio de inteligencia o fuerza policial de cualquiera de las decenas de países que albergan una CA se ve en la necesidad de capturar una comunicación basada en SSL tendría la opción de obtener un certificado emitido a nombre de la web que desean espiar, ya fuera mediante orden judicial, cooperación voluntaria, etc. Posteriormente solo tendrían que desviar el tráfico de los usuarios que accedieran al web objetivo y suplantarla mediante un ataque man-in-the-middle.

En cuando a la efectividad de esta técnica se puede considerar como muy alta, al fin y al cabo muy pocas personas realizan comprobaciones de seguridad en el uso de SSL más allá de verificar la presencia del famoso icono del candado o de revisar las alertas del navegador si es que este llega a presentar alguna, lo que no ocurre en este tipo de ataques. Porque por ejemplo ¿cuándo fue la última vez que comprobaste que el certificado de Gmail estaba emitido por Thawte y no por el CNNIC (China Internet Network Information Center)?

Hasta abril de 2010 un escenario como este se consideraba una vulnerabilidad teórica, porque no se tenía conocimiento de que pudiera estar empleándose en el mundo real. Fue ese mes cuando Christopher Soghoian y Sid Stammy publicaron un paper sobre el tema en el que además de describir la técnica adjuntaban un folleto de un pequeño fabricante de hardware en EEUU que estaría vendiendo una gama de dispositivos específicamente diseñados para realizar este tipo de interceptación de SSL.

Vamos a centrarnos en el dispositivo en cuestión, se trata de la serie 5 de la empresa Packet Forensics , una “solución de interceptación llave en mano” para la captura de trafico Web, VoIP, etc. que “utilizando la técnica man-in-the-middle intercepta TLS y SSL”. El aparato se oferta al mercado de fuerzas de seguridad y de inteligencia de EEUU y también del extranjero. Para usar este producto en el escenario de captura de SSL el usuario tiene la posibilidad de importar una copia del certificado obtenida legítimamente, por ejemplo mediante orden judicial, o bien cargar un certificado “de apariencia similar” como sería el caso de un falso certificado emitido por una CA confiable.

Según el folleto de Packet Forensics : "Los dispositivos están diseñados para ser insertados y retirados de las redes de los ISP sin causar ninguna interrupción perceptible”. Una vez instalado el dispositivo envía el tráfico interceptado por medio de un canal cifrado hasta sus controladores. Llama especialmente la atención que el folleto se considere al aparato tan económico que puede ser desechable, y que explica que esto supone “una reducción de riesgo para el personal”, el personal que lo instala se entiende, lo que vendría a sugerir un posible uso en operaciones clandestinas.



Y con esto terminamos por hoy, si el tema os ha parecido interesante no podéis perderos nuestra próxima entrada: “Rompiendo SSL a lo pobre”. Os explicaremos como aprovechar un fallo de configuración relativamente común para descifrar comunicaciones SSL previamente interceptadas. Se trata de una técnica sencilla al alcance de cualquiera, y lo mejor, ni siquiera es necesaria la licencia doble-cero del MI6.

Bibliografía

Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL (Christopher Soghoian and Sid Stammy)


4 comentarios:

  1. Merece la pena mencionar que algunos navegadores tienen extensiones (como certificate patrol) diseñadas para alertar de cambios sospechosos en los certificados

    ResponderEliminar
  2. Entiendo lo siguiente: Cuando uso Firefox, el navegador comprueba la veracidad de un certificado. Entiendo que para ello se conecta a una base de datos externa al sistema, envía su huella SHA1 o MD5 y se comprueba en esa base de datos que eso sea correcto. En este caso, se envía la confirmación.

    ¿Es así? En ese caso, ¿podría suplantarse a la entidad certificadora y confirmar cualquier tipo de certificado aunque sea realmente falso?

    ResponderEliminar
  3. No soy un gurú en el tema, pero según tengo entendido, puedes suplantar a la entidad certificadora siempre y cuando sepas su clave privada. Lo cual no debe ser fácil.

    Un saludo

    ResponderEliminar
  4. Vaya, Dario, lo que estaba pensando era más un Man in the Middle. Ahora ya sé lo que es.

    ResponderEliminar