[Post actualizado al 8 de Julio de 2020 con nuevas referencias] Hasta hace algunos años utilizaba un mecanismo para almacenar contraseñas que, a mi criterio, era infalible. Pero la tecnología evolucionó, y con ella los riesgos asociados a utilizar contraseñas…
Han pasado casi 20 años (19 para ser precisos) desde que se publicara la versión 1 de SHA, el algoritmo de cifrado más utilizado en el mundo y con el que operan la gran parte de los certificados SSL de la web.
SHA-1 es un método de cifrado desarrollado por la Agencia Nacional de Seguridad de los Estados Unidos (NSA, por sus siglas en inglés) y es considerado un estándar federal en el procesamiento de la información para el gobierno de aquel país. El método de salida de SHA-1 produce un valor de hash seguro de 160 bits (20 bytes), equivalente a un número hexadecimal de 40 dígitos de longitud.
En el año 2005 fueron publicadas dos investigaciones en las que se demostraron grandes debilidades en este mecanismo. Sucede que los hashes tienen un enemigo natural llamado “colisiones”. Las colisiones son la posibilidad de encontrar mediante ataques de fuerza bruta un identificador que no sea único, es decir, que un mismo SHA-1 represente a dos flujos de datos entrantes diferentes.
Por definición podríamos decir que existe 1 posibilidad en 1208925819614629174706176 (280) de generar colisiones en SHA-1. Sin embargo, a principios de 2005 un grupo de investigadores chinos redujo la cantidad de intentos a 269. Tiempo más tarde se avanzó hasta 263 y, finalmente, en la Universidad de Macquarie (Australia) lograron reducirlo hasta 252 (cerca de 2000 veces más rápido de lo esperado).
Como consecuencia de esto, el CA/Browser Forum recomendó en el año 2011 comenzar a abandonar SHA-1 tan pronto como sea posible. De hecho, el gobierno de los Estados Unidos dejó de utilizar este mecanismo en el 2010.
Por supuesto que sí. Y eso es lo que reclama Level 3, compañía estadounidense que provee servicios de internet del tipo Tier 1. Level 3 es, como se conoce en la jerga, un proveedor de proveedores. Básicamente ofrece servicios de interconexión a los ISP (proveedores de internet, por sus siglas en inglés) de casi todo el mundo.
Esta interconexión, conocida como peering, permite a los ISPs intercambiar tráfico (datos) entre ellos. Existen acuerdos de peering del tipo libre (en los que dos o más proveedores “dejan pasar” el tráfico que se intercambia entre sus redes) o pagos (en los que un proveedor compra ancho de banda a otro del mismo nivel o de nivel superior). Por ej. un ISP local o nacional contrata a uno regional para permitir a sus usuarios acceder a contenido alojado fuera del país. Internet es, en esencia, una red de redes interconectadas.
Hace algunas semanas Michael Mooney, General Counsel de la firma, escribió un artículo donde denunciaba públicamente que proveedores que hacen peering con Level 3 estaban saturando el ancho de banda acordado, reduciendo la calidad del servicio que brindan a sus clientes y de la red en general. Mooney, además, asegura que estos proveedores no están interesados en negociar sus contratos, lo que implicaría una degradación cada vez mayor de los servicios que ofrecen.
Quizá en los últimos días hayan oído mencionar mucho las palabras Heartbleed y OpenSSL. Pero… ¿De qué se trata todo esto?
Heartbleed es el nombre que se le dió a un agujero de seguridad (bug o vulnerabiliad) que afecta a los servidores web como Apache y Nginx que utilizan tecnología OpenSSL para procesar sus transacciones seguras.
OpenSSL, hermano de OpenSSH, es un paquete de herramientas y librerías de código abierto que permite a los administradores de sitios web encriptar las comunicaciones cliente <–> servidor mediante certificados de seguridad (el famoso HTTPS), entre otras funcionalidades. Está basado en la librería SSLeay desarrollada por Eric Young y Tim Hudson y permite su uso con propósitos comerciales y no comerciales. Es, por esto último, que se estima que dos tercios de los sitios web de Internet podrían estar o haber estado afectados por esta vulnerabilidad.
Un poco de historia
La vulnerabilidad fue introducida en Diciembre de 2011 y distribuida junto con la versión 1.0.1 y posteriores de OpenSSL, publicada a partir del 14 de Marzo de 2012.
El pasado 3 de Diciembre de 2013, Neel Mehta, del equipo de Seguridad de Google, reportó la existencia de un bug en el código de las versiones 1.0.1, 1.0.1f y 1.0.2 beta-1 que podría permitir que las comunicaciones cifradas sean interceptadas utilizando el método man-in-the-middle, en el que un atacante es capaz de leer y modificar la información intercambiada entre dos equipos sin generar ninguna sospecha. Además, la vulnerabilidad pone en riesgo las claves SSL privadas de los servidores, por lo que los sitios afectados debieron re-generar sus certificados de seguridad luego de corregir el fallo.
El nombre heartbleed (sangrado del corazón) fue elegido por un ingeniero de la firma de seguridad informática Codenomicon, quien también diseñó el logo y puso en línea el sitio oficial de la vulnerabilidad. Según información proporcionada por Codenomicon, Mehta reportó el fallo primero aunque ambos lo hicieron de manera independiente.
La vulnerabilidad quedó registrada bajo el CVE (Common Vulnerabilities and Exposures, por sus siglas en inglés) CVE-2014-0160. Considerando que fue introducida al código de OpenSSL en la versión 1.0.1, veriones anteriores también se encuentran seguras (1.0.0 y 0.9.8). Mediante el sitio oficial del proyecto, el pasado 7 de abril se publicó la versión 1.0.1g de OpenSSL que elimina la vulnerabilidad y se espera que en las próximas semanas se publique la 1.0.2-beta2 con la misma modificación.
Recomendaciones para usuarios
Queridos lectores,
Muchos de ustedes sabrán a que me refiero, otros quizá recién ahora escuchen nombrar el Efecto año 2000, Y2K o Error del milenio, entre tantos otros nombres que ha recibido este bug.
Adentrándonos en la historia, meses antes de comenzado el año 1999 se descubrió un bug o error de programación que afectaría a todos los equipos informáticos del mundo. Inmediatamente se generó una alarma social inmensa, que en pocas horas recorrió el mundo entero.
Este error de programación sacó a la luz una importante falla en cuanto a los sistemas informáticos y aplicaciones ejecutables en ellos. Hasta ese momento, los sistemas almacenaban internamente las fechas con lo últimos dos dígitos del año; tal es así, que el año 1999 era interpretado como 99. Esto tendría como consecuencia principal que después del 31 de diciembre de 1999, sería el 1 de enero de 1900 en vez de 1 de enero de 2000.
Por qué sucedería esto? Pues bien, si para los sistemas informáticos, 1999 era interpretado como 99, el año 2000 sería interpretado como 00, es decir, 1900. Otras herramientas, que permitían contar tres dígitos, tomarían la continuidad del 99 como 100, es decir, el año 19100.
Acciones a tener en cuenta
Cuántas veces les ha sucedido que envian un SMS y nunca llega a destino, o llega unas horas más tarde? O cuántas veces les ha ocurrido que intentan enviar un mensaje de texto y reciben una y otra vez el error “Mensaje no enviado” o similar? Y quién no está todavía creyendo que los SMS se almacenan en servidores de cada operador, y que pueden ser leídos por cualquier empleado? O cuántas veces se han preguntado cómo se envía un SMS? Ok, esa última pregunta quizá solo se me ocurra a mi, pero si alguien se siente identificado, aquí va la explicación, en claras palabras.
MT-SM y MO-SM
