---------------------------FELICITACION-------------------------

El equipo de Hispasec Sistemas desea a todos los lectores
de una-al-día un feliz y próspero año 2009

Hispasec Sistemas
http://www.hispasec.com

---------------------------FELICITACION-------------------------

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-------------------------------------------------------------------
Hispasec - una-al-día 31/12/2008
Todos los días una noticia de seguridad www.hispasec.com
-------------------------------------------------------------------

Investigadores consiguen hacer que cualquier certificado SSL parezca válido
---------------------------------------------------------------------------


Antes de que termine este año de catástrofes en la Red, un grupo
de investigadores consiguen asestar otro golpe a una de las
infraestructuras de Internet en la que se confía: la PKI
(infraestructura de claves públicas). Aunque el impacto real será
mínimo, se ha conseguido demostrar empíricamente que es posible
falsificar cualquier certificado SSL y por tanto, que los navegadores
den como válidos certificados falsos que harían aparecer páginas
fraudulentas como legítimas.

Esta es una de esas noticias que se presta a cierta exageración en los
medios, al igual que pasó con la supuesta ruptura del WPA con TKIP o con
el ataque sockstress, ambas de solo hace unas semanas. En realidad solo
se ha demostrado algo que se suponía teórico (que no es poco). El SSL
no está roto, el problema real reside en cómo lo utilizan algunas
autoridades certificadoras "anticuadas", o sea, en un modelo de PKI
concreto. Por último, destacar que el hecho de que los investigadores
hayan usado la potencia de 200 consolas PlayStation3 para conseguir su objetivo, es irrelevante, solo desvía la atención del problema aunque
añada cierto "glamour".

En realidad, las raíces reales del problema son dos: las conocidas
colisiones del algoritmo MD5, y que ciertas autoridades certificadores
todavía lo usen. Vamos a realizar una pequeña introducción sobre los certificados y luego explicar cómo lo han conseguido exactamente y las consecuencias.

SSL y los certificados

SSL es un protocolo que sirve para cifrar las comunicaciones punto a
punto, por ejemplo entre un navegador y un servidor web o una conexión
SSH. En una conexión SSH no es necesario autenticar al servidor remoto habitualmente, pero sí cuando un usuario se conecta a una página web.
¿Estoy realmente en la web de mi banco? Para eso se inventaron los certificados, que son una especie de "documentos de identidad", DNI, del servidor. Ahí aparecen (respetando el estándar X.509) datos como el
nombre de dominio para el que está emitido, fechas de validez, clave
pública del sitio y sobre todo, qué autoridad le da validez a ese
certificado. Si en el caso de los carnés de identidad la validez la
certifica el Estado, en Internet existen un buen número de autoridades certificadores (CA) que validan esa información. Cuando se crea una
clave pública que va a servir para certificar un sitio web, el dueño del
sitio debe enviar esa clave junto con sus datos a una autoridad para que
todo junto se convierta en un certificado y se garantice que pertenece a
esa persona o entidad.

Los certificados y "las firmas"

Las CA calculan el hash (una especie de firma-resumen) de todo el
certificado (recordemos: nombre de dominio, fechas, clave pública...), y
este valor se añade al propio certificado. Sería como su número personal
e intransferible que lo incluye todo. Si se altera algún valor, este
dato cambia por completo. Luego además "firman" este hash (y solo el
hash) con su propia clave privada, de forma que ahora el certificado,
tiene un "número de identificación", firmado por alguien de confianza y supuestamente único, además asociado de forma indivisible a sus datos.
Este paso sería como "lacrar" el certificado en un sitio oficial. Como
veremos, aquí es donde las CA cometen el error técnico.

Como existen muchas CA, los navegadores por defecto traen ya por defecto
una lista de certificados raíz que sirven para comprobar de forma
automática que la ruta de validez del certificado es válida, o sea, que
está firmado por alguien en quien se confía y la firma es válida.

Si existe algún fallo durante esta comprobación automática, si por
ejemplo se crea un certificado que dice ser de un sitio pero no lo es y
no está validado, el hash no casará y el navegador se quejará mostrando
una alerta. Confiamos en los hashes firmados porque se supone que es muy complejo que dos hashes coincidan si son creados a partir de datos
diferentes, esto es, que colisionen.

"Las firmas" y el MD5

Cuando hablamos de hash o firma criptográfica, todavía se acude al MD5
como referente, aunque esté obsoleto y desaconsejado. Muchas CA han
usado y están usando MD5 para calcular el hash del certificado y firmar
esto con su clave privada. Otras muchas autoridades, la mayoría, están
ya valiéndose de SHA1, un algoritmo de hash mucho más robusto y al que
todavía no se le han encontrado serios problemas. MD5 por el contrario,
es rechazado porque la potencia de computación actual hace que sea
sencillo encontrar colisiones.

Esto es precisamente lo que han expuesto varios investigadores
internacionales en Berlín el día 30 de diciembre. Han creado
certificados con identidades usurpadas, pero validados por CA. Lo han conseguido con fuerza bruta, forzando la colisión de la firma MD5. Esto
puede permitir crear sitios falsos con certificados que sean válidos, o
de forma práctica: phishings perfectos.

Cómo lo han hecho

Alegóricamente, lo que han conseguido es recortar un sello del Estado
que da validez a un carné cualquiera y pegarlo en un carné falsificado
de otro individuo al que se pretende imitar. El mérito del
descubrimiento es que parezca real aunque los sellos son único y están
creados a partir de los datos de todo el carné, además de lacrados por
una autoridad.

Por ejemplo, si se quiere falsificar el certificado de hispasec.com, los investigadores crearían dos certificados, uno que falsificase los datos
de Hispasec y otro real con cualquier información. El truco es que han conseguido con fuerza bruta, que ambos resulten en un mismo hash
criptográfíco, en el mismo MD5. Entonces enviarían el real (con
cualquier información no necesariamente relacionada con Hispasec) a una
CA que todavía use MD5 para validar certificados. La CA lo firmaría y lo validaría con total normalidad. Luego los atacantes dan el cambiazo: les bastaría con modificar el hash del certificado que falsifica los datos
de Hispasec con el hash del otro certificado, validado ya por una CA.
Como ambos resultan en el mismo hash aunque contengan distintos datos,
todo encaja, y el certificado falso seguiría siendo matemáticamente
válido a todos los efectos.

Qué pasa ahora

No mucho. La tecnología SSL es muy útil, y ahora se le ha encontrado
un pequeño hueco que hace que en teoría, podamos dudar de todos los certificados de autoridades certificadoras que se basen en MD5, pero son
las que menos. En cualquier caso, el problema de base es que el usuario
medio no sabe qué es SSL, ni qué significa un certificado, y mucho menos interpretarlo. Como mucho, sabe que si está en un sitio https, o el
candado del navegador está activo, entonces el sitio es "bueno". Pero ya sabemos que para conseguir un candado en el navegador o incluso un
certificado no válido (aunque el navegador se queje, el usuario no
entenderá la advertencia y dirá que "sí") no es necesaria tanta
complejidad. Un atacante puede comprar certificados baratos que validen
un nombre falso (banc0.com), el navegador ni se quejará y el usuario
tampoco entenderá qué está pasando.

SSL es técnicamente genial pero está resultado una tecnología
"socialmente" fallida. No es entendida por el usuario y ese es el mayor
de sus problemas. Con este golpe técnico la infraestructura de PKI se ha demostrado que incluso a los expertos se les podría engañar con los certificados, pero también es cierto que los que entienden la tecnología
pocas veces se detienen a cuestionarse un certificado, comprobando la
ruta de certificación y demás información proporcionada por el sitio supuestamente seguro. SSL arrastra la lacra del desconocimiento por
parte de la mayoría de los usuarios. Si por ejemplo el DNI es aceptado nacionalmente como documento que valida una identidad, un certificado
SSL está lejos de ser aceptado por el usuario medio de Internet como
documento que garantice nada.

También hay que tener en cuenta que pocas CA usan hoy día MD5, y que
tras esta llamada de atención es de esperar que sean todavía menos en el futuro. Para los que posean certificados, es aconsejable que comprueben
que la CA que les ha dado validez usa o no MD5.

En definitiva, esto es grave sobre todo para https, pero nada
catastrófico va a pasar a efectos prácticos para el usuario medio. Al
menos no más grave de lo que ya está ocurriendo, teniendo en cuenta la credibilidad de la que todavía gozan burdas copias de páginas web que
simulan ser bancos.

Todos los grandes fabricantes (que usen VPN basadas en SSL o implementen navegadores) han publicado avisos explicando el problema.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3721/comentar

Más información:

MD5 considered harmful today
http://www.win.tue.nl/hashclash/rogue-ca/

17/06/2008 Mitos y leyendas: "Compruebe el candadito del navegador para
estar seguro" II (Troyanos)
http://www.hispasec.com/unaaldia/3524

03/06/2008 Mitos y leyendas: "Compruebe el candadito del navegador para
estar seguro" I (Phishing)
http://www.hispasec.com/unaaldia/3510


Sergio de los Santos
ssantos@hispasec.com


Tal día como hoy:
-----------------

31/12/2007: Resumen de seguridad de 2007 (y III)
http://www.hispasec.com/unaaldia/3355

31/12/2006: Resumen de seguridad de 2006 (y III)
http://www.hispasec.com/unaaldia/2990

31/12/2005: Desbordamiento de búfer y escalada de privilegios en Gentoo Linux
http://www.hispasec.com/unaaldia/2625

31/12/2004: Vulnerabilidades en Moodle
http://www.hispasec.com/unaaldia/2260

31/12/2003: Parche de actualización de Microsoft Exchange 5.5 CDO
http://www.hispasec.com/unaaldia/1893

31/12/2002: Problemas de denegación de servicio en diversos productos Cisco
http://www.hispasec.com/unaaldia/1528

31/12/2001: Diversos problemas de denegación de servicio en Oracle9iAS Web Cache
http://www.hispasec.com/unaaldia/1163

31/12/2000: Creación insegura de ficheros temporales en el "patchadd" de Solaris
http://www.hispasec.com/unaaldia/798

31/12/1999: Grave error de diseño en el modelo de seguridad SCO UnixWare 7
http://www.hispasec.com/unaaldia/430

31/12/1998: Adios 1998, Feliz 1999
http://www.hispasec.com/unaaldia/65


-------------------------------------------------------------------
Claves PGP en http://www.hispasec.com/directorio/hispasec
-------------------------------------------------------------------
Bajas: mailto:unaaldia-request@hispasec.com?subject=unsubscribe
Altas: mailto:unaaldia-request@hispasec.com?subject=subscribe
-------------------------------------------------------------------
(c) 2008 Hispasec http://www.hispasec.com/copyright
-------------------------------------------------------------------

--- SoupGate-DOS v1.05
* Origin: Pasarela FTN-INet telnet://pucelabbs.dyndns.org:4000 (2:341/201.99)