25 noviembre 2009

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:

Primero un servidor NO vulnerable:

$ openssl s_client -connect www.packetstormsecurity.org:443

(después de la negociación inicial SSL que no pego porque es inmensa ...)

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 1A00CCF15199B45D635CDC16D16409BE2773D6DED40C9D0
Session-ID-ctx:
Master-Key: 0D3D9F8122EE66B171EACC1C2826FD58AE323D10A5C4953
Key-Arg : None
Krb5 Principal: None
Start Time: 1259108074
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)

Le pedimos que haga la renegociación pulsando R

---

R
RENEGOTIATING
2655:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:

Como se puede apreciar, el servidor da un error y no permite la acción

Probemos ahora con, por ejemplo, la FNMT

$ openssl s_client -connect www.cert.fnmt.es:443

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: D25849BCD4A0FCC76F5864DD90B47931E7289B19F5487FD11B8
Key-Arg : None
Krb5 Principal: None
Start Time: 1259108343
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
R
RENEGOTIATING
depth=0 /C=ES/O=FNMT/OU=FNMT Clase 2 CA/OU=Publicos/OU=500070015/CN=WWW.CERT.FNMT.ES
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=ES/O=FNMT/OU=FNMT Clase 2 CA/OU=Publicos/OU=500070015/CN=WWW.CERT.FNMT.ES
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=ES/O=FNMT/OU=FNMT Clase 2 CA/OU=Publicos/OU=500070015/CN=WWW.CERT.FNMT.ES
verify error:num=21:unable to verify the first certificate
verify return:1

---

Como podemos ver parece que la renegociación ha sido exitosa.

Probemos ahora con una entidad financiera (elegida totalmente al azar)

$ openssl s_client -connect www.cajaespana.net:443

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 445C49E1F35D5A3A8FDDC3402852210CFAA72F5040
Session-ID-ctx:
Master-Key: EC92D166291DE3EBEAB16792DB5B2912A8B8A89234E
Start Time: 1259109105
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
R
RENEGOTIATING
depth=3 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
verify return:1
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
verify return:1
depth=0 /1.3.6.1.4.1.311.60.2.1.3=ES/2.5.4.15=V1.0, Clause 5.(b)/serialNumber=Tomo 340, Folio 1, Hoja/C=ES/ST=leon/L=leon/O=Caja Espa\xC3\xB1a de Inversiones, Caja de Ahorros y Monte de Piedad/OU=Terms of use at www.verisign.com/rpa (c)05/CN=www.cajaespana.net
verify return:1

También parece que admite renegociación

7 comments :

Hocicos dijo...

Al final, lo más seguro va a ser que guardemos los ahorros bajo el colchón...

Anónimo dijo...

Muchas gracias por la explicación tan detallada de este "bug". Una duda.

¿Es posible configurar en un Servidor Apache que no se realice renegociación SSL?

Un saludo.

Yago Jesus dijo...

@Anónimo, Para evitar el bug en un Apache, debes actualizar tu versión de OpenSSL a la que ya contiene el parche, el tema es de OpenSSL mas que de Apache. Un saludo

Anónimo dijo...

good fantantic wow wow wow

Anónimo dijo...

Muy buena explicación! Así que eso era todo lo del bug del SSL... Ayy

Gracias ^^

Newlog

anonimaso dijo...

Disculpame pero esta explicación no es la de renegociación SSL, estás explicando un ataque de MitM con HTTP entre el atacante y la victima y SSL entre la victima y el servidor. No tiene nada que ver con la renegociación SSL. Este ataque se hace con el ssl-strip. El hecho de que exista renegociación no afecta en nada a este ataque.

Yago Jesus dijo...

Gracias Sara