Heartbleed: ¡estamos condenados!

Cientos de miles de servidores incluyendo el website del FBI fué afectado por este error, ¡esas son palabras mayores!. Cómo bien lo dice C3P0: We are doomed!. Pero ¿por qué tanto alboroto si los reportes de errores de seguridad son tan frecuentes en informática?

El OpenSSL es un software libre para proteger la comunicación entre el navegador que tienes en tu computador o tablet y el servidor que tiene las páginas web que consultas. Estos son propiedad de bancos, gobierno, hospitales, juzgados, empresas, etc.

Este software, en combinación con un certificado emitido por una entidad de certificación (una especie de notaría digital) permiten que se establezcan conexiones codificadas previniendo la interceptación de datos por cuenta de delincuentes informáticos (Crackers).

Al ser libre, OpenSSL, además de poderse conseguir gratuitamente para ser utilizado por cualquier entidad, también lo pueden utilizar los estudiantes de informática para conocer los algoritmos que se utilizan para garantizar la seguridad en comunicaciones por protocolo http. Esto no quiere decir que sea inseguro, por el contrario, al tener cientos de miles de personas estudiando y conociendo el código la detección de errores es mucho más sencilla, esto se conoce como la “ley de Linus”. La seguridad es similar a una chapa, cualquiera puede saber cómo funciona el mecanismo de guardas, pero sin la llave correcta es muy dificil abrirla.

 

¿Cual es el problema?

Lo que actualmente escandaliza a internet es el heartbleed , un error que se filtró en la versión 1.0.1 de OpenSSL, emitida el 3 de enero de 2012, cuyo defecto es que expone las claves de cifrado sin dejar rastros del ataque.

Con estas claves en la mano, los delincuentes pueden chuzar las comunicaciones al servidor atacado y obtener sin inconvenientes: claves de cuentas bancarias, números de tarjetas de crédito, expedientes judiciales, historias clínicas, mensajes por correo electrónico, chats y muchas otras piezas de información.

Técnicamente hablando, la vulnerabilidad expone 64K de la memoria del servidor en un sitio aleatorio de ella, lo cual es poco, pero con mucha suerte y suficientes ataques un cracker podría incluso obtener todo el certificado.  Es decir, no es fácil obtener las claves pero teóricamente si es posible.

Afortunadamente los ingenieros de Google y de Codenomicon detectaron el problema a finales de marzo de 2014 y el 7 de abril de 2014 los integrantes del equipo que gestiona OpenSSL sacaron una nueva versión de OpenSSL, la 1.0.1g, con la corrección del error.  Es decir, que en menos de una semana la comunidad emitió la corrección del error.

La incógnita que nunca se podrá resolver es si existió algún cracker que se haya aprovechado de esta vulnerabilidad en alguna de las entidades que visito y tenga mis datos en sus manos. Lo cual pudo suceder durante los 14 meses en que existieron los bugs.

Quienes utilizaron páginas web con entidades peresozas, que no actualizaban sus servidores desde el 2011, no están expuestos a esta vulnerabilidad (a otras si, pero a esta no) y quienes se comunicaron con entidades con sus servidores actualizados si estuvieron expuestos. El gran problema es que si hoy me comunico con una entidad que, a pesar de la existencia de la versión corregida, no ha actualizado sus servidores: aún estoy expuesto.

 

¿Qué puedo hacer yo?

Es importante que cada vez que vayas a conectarte a una página web de aquellas que “cierran el candado” y “ponen la dirección http con fondo verde”, es decir las páginas protegidas con SSL/TLS hagas primero una prueba del sitio con algún software que permita evaluar la seguridad del servidor, El Tiempo recomienda la página http://www.filippo.io/Heartbleed/ que fácilmente informa si el servidor es vulnerable o no.

Si el servidor es inseguro, escribe una carta a la entidad informandoles del problema que tienen para que el administrador de sistemas actualice el OpenSSL a la última versión. Si, por el contrario, es seguro y deseas estar tranquilo debes cambiar inmediatamente todas las claves de acceso a ese servidor.

De todas formas, siempre es sano cambiar las claves frecuentemente, aprovechemos el desorden y hagamos esta labor.  Les recomiendo el artículo "Contraseñas seguras: deben ser fáciles de recordar pero difíciles de adivinar" 

 

¿Quien se beneficia con este problema?

Comenzando por las entidades de certificación (las notarías digitales de las cuales hablé antes) puesto que hoy cientos de miles de empresas responsables, que utilizaron durante los últimos 14 meses sus sertificados SSL para proteger sus servidores mediante OpenSSL, tienen que comprar un certificado nuevo (y no se imaginan los precios de cada certificado). Continuando por Gobiernos interesados en realizar labores de espionaje. Y finalizando con los hipotéticos delincuentes informáticos que robaron información; y digo hipotéticos, puesto que aún no se ha comprobado que existan, pues la vulnerabilidad no fué detectada por culpa de un robo confirmado y no hay forma de encontrar evidencias de su existencia.

 

¿De quién es la culpa?

Generalmente yo recomiendo no buscar culpables sino implementar soluciones y planes de prevención. Pero esta vez me voy a abstener de mi propia recomendación y voy a emitir un juicio personal. Culpo de este problema a todas las entidades que utilizan software libre para su propio beneficio y no comparten parte de sus ganancias con estos proyectos en forma de donaciones. Los invito a leer este artículo de FabioBaccaglioni el cual me pareció bastante sensato.

El proyecto OpenSSL está siendo utilizado por cientos de miles de empresas, incluyendo bolsas de valores, bancos, fondos de inversión, entidades públicas, entidades de certificación (las notarías digitales de las que hablé) y se lucran con miles de millones de dólares gracias al uso de este software. Pero el proyecto OpenSSL en los últimos años ha estado pasando por una situación económica bien apretada. Así mismo sucede con muchos otros proyectos de software libre.

Y ahora empresas de software privativo, cuyos problemas de seguridad históricamente han sido más grandes y peligrosos y cuyos tiempos de respuesta a la corrección son sustancialmente mayores, intentan aprovecharse de este problema para causar temor entre los usuarios de software libre.

Igualmente estas empresas de software privativo siembran desconcierto frente al hecho de que una vulnerabilidad que en un par de días puede ser arreglada estuvo activa durante dos años, insinuando que el error fue plantado a propósito en el software.

Considero, entonces, importante resaltar que en software libre es normal y natural que los errores de seguridad o de funcionalidades que se encuentran son corregidos en cuestión de horas tras el hallazgo.  Ésa es una de las grandes virtudes del software libre.

Igualmente debe anotarse que la demora de 2 años en detectarse la vulnerabilidad se debió a que el error no es evidente y que la exposición de los 64 KB de datos de la memoria del servidor no garantizan que son exactamente en las claves (cuyo tamaño es muy superior a los 64KB), como dije anteriormente, "teóricamente" es posible que un atacante con "mucha" suerte y "mucho" tiempo logre obtener las claves.

Por supuesto, es necesario también, un jalón de orejas a la comunidad de OpenSSL, como bien lo hace Theo de Raadt quien llama irresponsable al equipo de OpenSSL. Sin embargo, vuelvo e insisto en que si hubiera habido más estímulos económicos para quienes apoyen la detección de errores y los ajustes y mejoras al software, seguro se habría detectado el problema con anterioridad.

 

¿Cómo prevenir problemas similares?

Bueno, el primero que se echó la mano al bolsillo fué Google, quienes están brindando una jugosa recompensa de US$3,133.7 a quienes encuentren y solucionen problemas de seguridad. Espero que iniciativas como estas continúen.

Otra respuesta que nace tres semanas después de la aparición del heartbleed es libreSSL un "fork" de openSSL.  Cuando los proyectos de software libre no van bien se generan discusiones entre la comunidad en donde participan tanto usuarios como desarrolladores.

Si, tras escuchar los argumentos, los desarrolladores no se ponen de acuerdo, una de las grandes maravillas del software libre se evidencia: la posibilidad de estudiar y modificar el software libremente. Para satisfacer las necesidades planteadas, de una forma diferente a la planteada por los líderes del proyecto original, los desarrolladores "disidentes" construyen un nuevo proyecto tomando la mayor parte de las piezas del software original, descartan aquellas con las que no están de acuerdo y bautizan el proyecto con un nuevo nombre con una infraestructura y comunidad independientes.

Generalmente la disidencia permanece al tanto de las modificaciones y mejoras que le hacen al proyecto original para implementarlas en el propio, al igual que la comunidad del proyecto original está pendiente permanentemente de lo que sucede con la disidencia.  Esto genera una sana competencia en donde el gran beneficiado es el usuario final que tendrá para escoger dos, o más proyectos, que satisfacen sus requerimientos desde perspectivas distintas.

No es la primera vez que sucede, es más, en software libre es frecuente esta situación.  Gracias a ello existe OpenOffice y LibreOffice, muy parecidos pero con comunidades de desarrollo con objetivos distintos. LibreOffice es el fork y hoy en día tiene más usuarios que el proyecto original.

¿Quien ganará la competencia OpenSSL o LibreSSL? Solo el tiempo lo dirá, en la medida que las comunidades crezcan alrededor de alguno de los dos proyectos.  Inclusive puede pasar que las necesidades que atienden los proyectos sean tan distintas que se generen dos usos independientes y específicos para cada proyecto, ambas comunidades crezcan y se complementen y, por lo tanto, se evidencie un "empate técnico".

Ing. Ricardo Naranjo Faccini, M.Sc.