martes, julio 13, 2010

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.

4 comentarios:

  1. Muy interesante.

    "La segunda pregunta es ¿qué le impide a una entidad de confianza intermedia firmar un dominio?"

    Esto es algo que siempre me he preguntado. ¿Puedo yo comprar un certificado de cualquier URL?

    Mi respuesta es "en principio no". Las CA te piden que demuestres que tienes control sobre el dominio.

    Nunca que me lo he propuesto, por falta de tiempo y dinero. Además no tengo idea si sería un delito, pero estaría bien probar si es efectivo el sistema de verificación que tienen.

    Hombre, ya no digo que consigas los datos que piden, normalmente son semi-públicos o totalmente fáciles de conseguir. Creo que sería posible obtener un certificado de otra entidad.

    El caso que propones de los Chinos, no estoy de acuerdo, a no ser que tengas la CA raíz en tú biblioteca de certificados.

    En ese caso, la cagada es tuya por instalar el certificado, o de la CA, que perdería valor como notaria.

    Oye, te propongo que hagas un estudio sobre esto, podría ser interesante, ¿qué dices?

    ResponderEliminar
  2. @David, no sé exactamente el número de entidades intermedias que hay por el mundo autorizadas por las CA raiz e intermedias que viene por defecto en Windows o en el repositorio de FF, pero son ingentes... La charla de Dan Kaminsky sobre Black Ops en PKI de la BH 2009 fue impresionante.

    Saludos!

    ResponderEliminar
  3. @David en SecurityByDefault publicaron un post sobre lo que preguntas: http://bit.ly/9MM2N9

    ResponderEliminar
  4. Solo una cosilla, aunque tengas el certificado wildcard instalado y pagando un pastizal estos no soportan el dominio primario (no se si lo digo bien sino es así tarjeta roja) es decir, https://mibanco.com y salta un error de que no confio ya que los certificados wildcard (o por lo menos los que yo he manejado) son del tipo *.mibanco.com con lo que el dominio primario queda excluído

    ResponderEliminar