Buscar
 
 

Resultados por:
 


Rechercher Búsqueda avanzada

Últimos temas
» En casa de Belén, de vacaciones
Dom Abr 03, 2011 2:48 am por Invitado

» CONTINUIDAD
Lun Sep 14, 2009 8:28 pm por alfonso

» Boletín diario de Seguridad de INTECO-CERT
Jue Ago 20, 2009 3:52 pm por son5minutos

» Vulnerabilidad crítica en Flash Player
Dom Jul 26, 2009 2:13 pm por son5minutos

» Adobe conocía su último "0 day" desde 2008
Dom Jul 26, 2009 2:12 pm por son5minutos

» Último Informe del CERT para PYMES y Ciudadanos de Inteco
Dom Jul 26, 2009 2:11 pm por son5minutos

» STILO
Dom Jun 28, 2009 2:45 pm por nenina

» CINE
Dom Jun 28, 2009 2:44 pm por nenina

» VIAJAR
Dom Jun 28, 2009 2:44 pm por nenina

» EMPLEO Y FORMACION
Dom Jun 28, 2009 2:43 pm por nenina

» MOVILES
Dom Jun 28, 2009 2:42 pm por nenina

» VIDEOJUEGOS
Dom Jun 28, 2009 2:41 pm por nenina

» SEGURIDAD
Dom Jun 28, 2009 2:40 pm por nenina

» EMPRENDE
Dom Jun 28, 2009 2:40 pm por nenina

» NOTICIASDOT PRO
Dom Jun 28, 2009 2:39 pm por nenina

» SOFTWARE LIBRE
Dom Jun 28, 2009 2:39 pm por nenina

» GADGETMANIA
Dom Jun 28, 2009 2:37 pm por nenina

» WEB 2.0
Dom Jun 28, 2009 2:37 pm por nenina

» MUNDO DIGITAL
Dom Jun 28, 2009 2:36 pm por nenina

» Averigua quién está conectado a tu ordenador
Dom Jun 21, 2009 12:11 pm por Gaillimh

Flujo RSS


Yahoo! 
MSN 
AOL 
Netvibes 
Bloglines 


Bookmarking social

Bookmarking social Digg  Bookmarking social Delicious  Bookmarking social Reddit  Bookmarking social Stumbleupon  Bookmarking social Slashdot  Bookmarking social Yahoo  Bookmarking social Google  Bookmarking social Blinklist  Bookmarking social Blogmarks  Bookmarking social Technorati  

Conserva y comparte la dirección de Foro en tu sitio de bookmarking social


Investigadores consiguen hacer que cualquier certificado SSL

Ver el tema anterior Ver el tema siguiente Ir abajo

Investigadores consiguen hacer que cualquier certificado SSL parezca válido

Mensaje por Gaillimh el Miér Dic 31, 2008 6:22 pm

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
avatar
Gaillimh
Admin
Admin

Masculino
Cantidad de envíos : 4013
Edad : 52
Localización : Barcelona
Fecha de inscripción : 31/10/2007

Ver perfil de usuario http://www.pruebavihbarcelona.org

Volver arriba Ir abajo

Ver el tema anterior Ver el tema siguiente Volver arriba

- Temas similares

 
Permisos de este foro:
No puedes responder a temas en este foro.