La muerte social de SSL en la banca

Moxie Marlinkspike, con SSLtrip demostró al mundo entero que era muy sencillo engañar a casi cualquier usuario que confía en https. No hacía falta ni a día de hoy la hace, que el exista un fallo en la evaluación de los certificados con un /0 tal y como presentó en la BlackHat del 2009, basta con utilizar algunas de las debilidades sociales del mismo.

¿Dónde está el cifrado?

Moxie presentaba muchos casos en los que el usuario debía confiar en que, tras pulsar un link que lleva a un javascript, se lanzase una conexión SSL. Vamos todo un salto de confianza al más puro Indiana Jones en “La última cruzada”. Es fácil encontrar casos así en la banca, pero, para llevarnos todos bien, sólo lo he puesto con un banco extranjero.


Figura 1: Salto de Fe con HSBC
Como se puede ver, la conexión es HTTP, cuando haces clic en logon salta un javascript que, posteriormente, llama a un Https. Vamos, que hay que hacer una auditoría a la web antes de jugársela. Algo que no hará, como dice Sergio de los Santos en el Curso de Verano, su madre.

¿Por qué este fallo es malo y el otro no?

La alerta de seguridad que se recibe cuando falla una de las tres comprobaciones del certificado de seguridad está pensada para técnicos pero no para mamás. Sergio nos hizo una sencilla demo, basta con pedir en algún banco legítimo la conexión https://mibanco.com. Lo curioso es que, aunque la mayoría de los bancos atienden cuando se solicita http://mibanco.com – sin poner un www - cuando recibe la petición por https generan un error. Esto es porque el certificado que están usando no soporta el wildcard.


Figura 2: Bank of America sin soporte para el dominio principal
El mensaje de error que se recibe es “Este certificado no está emitido para este nombre”. Un mensaje de error que no debería salir y que confunde a los usuarios, que recibirán la misma alerta, pero con el mensaje “este certificado está emitido por una entidad en la que no se confía”.

Las relaciones de confianza

Dan Kaminsky, el año pasado, hablaba del problema de la confianza. ¿Qué pasa si el certificado raíz de confianza es inseguro y puede suplantarse? Esto lo hizo Alex Sotirov con un certificado que estaba en MD5 y el mismo Dan mostraba como uno de los certificados de una de las entidades raíz de confianza permanecía en MD2.

La segunda pregunta es ¿qué le impide a una entidad de confianza intermedia firmar un dominio? La pregunta viene a colación de la censura en ciertos países. ¿Y si una entidad de confianza del gobierno chino firma www.gooogle.com/? Pues que el usuario no recibirá ninguna alerta pese a que el gobierno chino estuviera haciendo un man in the middle, ya que ellos tienen el certificado. Así que si te conectas a tu correo podrían leerlo. ¿Quién se sabe cuál es la entidad de certificación que eligió Google sin mirar el certificado ahora mismo?


Figura 3: Certificado sin validación extendida en American Bank
Y la última es, ¿y si un malware te instala un certificado de una entidad de confianza raíz en tu sistema? A partir de ese momento tus comunicaciones son texto plano. Enrique Rando se ha currado esta demo y os la pondré por aquí en breve.

El uso de certificados de validación extendida ayudaría un poco, sólo un poco más, a dar información al usuario para reconocer mejor si está en la conexión adecuada o no. Sin embargo aun no es masiva la proliferación de certificados de validación extendida en el mundo de la banca.

Sé que es difícil solventar todos estos problemas pero algunos bancos conocidos por casi todos, no se toman en serio esto de la seguridad y lo arreglan, en algunos casos, cargándoselo al usuario por “descuidado”, al mismo tiempo que algunos de ellos aun no tienen ni el registro SPF. Échale un ojo a tu banco, a ver que encuentras.

Todo esto, como decía Sergio de los Santos, le da ventaja al malware contra los usuarios.

Saludos Malignos!

PD: Os recuerdo que en Valencia todavía continuan las acciones hasta la semana que viene.