El bug del SSL: Como tirar la piedra y esconder la mano

En estos últimos días se ha escuchado y mucho hablar del término 'renegociación' y no, no tiene que ver con bugs similares que le puede suponer a una familia verdaderos problemas, sino del bug del SSL que tantos ríos de cibertinta ha hecho correr

Hemos tardado un poco en hacer la valoración porque no nos gusta caer en el sensacionalismo o hablar sin tener toda la información.

Para empezar, primer mensaje : calma, el famoso bug no es, salvo alineación planetaria, un bug que debería tener consecuencias importantes, de hecho, lo mas destacable hasta ahora publicado, es un ataque a Twitter

Creo que el documento original cubría los detalles técnicos a muy bajo nivel lo suficientemente como para no emborronar el post haciendo una traducción, creo que interesa mucho mas la interpretación práctica.

¿Se ha roto el protocolo SSL? NO, rotundamente NO, este ataque no permite acceder al contenido de las sesiones cifradas ni interceptar una sesión en tránsito

¿Que significa en el ámbito SSL 'renegociar una sesión'? A grosso modo se puede decir que durante una conversación SSL, por motivos diversos (porque interese cambiar el juego de algoritmos de cifrado o porque intervenga una autenticación con certificados) uno de los extremos puede pedir que se empiece desde cero y re-iniciar la negociación SSL.

¿Como se puede explotar el bug? Para empezar, se requiere una situación MiM, y que el atacante tenga el control de las comunicaciones entre la víctima cliente y el servidor final. Una vez en esa situación, lo que el bug de la renegociación permite es que un atacante inicie una sesión SSL contra un servidor (a nivel SSL), comience a hablar HTTP (que está en otra capa) y, en un momento dado, 'le pase la sesión HTTP' al cliente que nada sabe de lo previamente hablado entre el atacante y el servidor.

¿Por pasos? Ok

1. La victima intenta conectarse vía HTTPs a www.elbanco.net
   
2. El atacante que 've' ese intento y lo deja en espera
3. El atacante se conecta a www.elbanco.net vía SSL
4. Hace una petición HTTP (GET /ordenatransferencia.aspx?dinero=2000&cuenta=00012124455)
5. En ese momento, pide una renegociación a nivel SSL (que actúa en otra capa diferente a HTTP)
6. Cuando comienza a renegociarse la petición SSL, el atacante da vía libre a la primera conexión de la victima y el servidor http, al creer que ambas vienen del mismo sitio, las concatena, con lo que a la víctima le llega la sesión HTTP iniciada por el atacante

Viendo este escenario, y según se ha ido constatando conforme pasaban los días, parece que la única forma de sacar partido a este escenario es tratando de iniciar una petición al servidor HTTP, y que cuando se 'le pasa' a la víctima, esta tenga cookies de sesión que autentiquen la petición HTTP anterior (eso y emplear algunos 'trucos' http para que la petición de la víctima, típicamente un GET, no sea interpretada por el servidor).

Según la gente de IBM-ISS el ataque ha sido catalogado como un CSRF del que se presupone cualquier banco / organismo serio, obligado a cumplir la directriz PCI, estará mas que precavido.

Añadir que, en otros protocolos que usen SSL como capa de cifrado (lease VPNs o servidores de correo) parece que el impacto es aun menor.

Aun así, por mera curiosidad insana vamos a comprobar si algunos servidores https nacionales ya se han parcheado contra este tipo de ataque:




Contenido completo en Security By Default

Suscríbete a nuestro Boletín