Las lecciones de un corazón sangrante

Heartbleed. Habrás visto esta palabra en los días pasados. Se trata de una falla de seguridad informática potencialmente catastrófica de OpenSSL, una de las implementaciones del protocolo que garantiza conexiones seguras; por ejemplo, cuando hacés home banking o comprás algo online. Afectó a más o menos un 17% de los sitios Web que ofrecen conexiones HTTPS y a muchos programas que requieren cifrado; por ejemplo, las redes privadas virtuales (o VPN). Se originó en un error de programación, un error simple y accidental que está a años luz de las psicodélicas teorías conspirativas que oí estos días, pero que podría haberse evitado.

Todo lo anterior es verdad. Pero sólo una parte de la verdad, que se usó para estigmatizar a OpenSSL y al software de código abierto en general. Antes de entrar en los detalles técnicos, me gustaría mostrar la otra cara de esta cuestión.

OpenSSL es un proyecto de código fuente abierto que se distribuye sin cargo y depende de donaciones para funcionar. Es usado por centenares de miles de sitios, incluidos los de algunas de las compañías más poderosas del planeta. No obstante, el equipo permanente de OpenSSL está compuesto por (sentate, de ser posible) 4 voluntarios, tres ingleses y un alemán, más 11 desarrolladores. Robin Seggelmann, un colaborador asiduo que había "corregido docenas de errores en OpenSSL", según me contó uno de mis entrevistados, incorporó, en la víspera del año nuevo de 2011, el error que ahora llamamos Heartbleed. ¿Lo hizo adrede?

De ningún modo. Errores como el Heartbleed se producen todo el tiempo en programación. Fue uno de esos deslices que cualquiera de nosotros comete muchas veces en la vida, de posibles consecuencias catastróficas, pero de factura grosera. Basta ver el código donde reside la falla para descubrir que si Seggelmann hubiera querido hacer daño, hubiera introducido algo mucho más sutil.

Lo que ocurrió es que nadie vio el error. ¿Por qué? Porque el software de OpenSSL tiene unas 430.000 líneas de código. Líneas que no están en español o en inglés, sino en C, un lenguaje de programación cuya lectura es mucho menos intuitiva que la de los idiomas naturales. Una coma mal puesta puede hacer que todo ande mal

Así que lejos de acusar al equipo de OpenSSL deberíamos asombrarnos de que no haya ocurrido algo así antes. Por su parte, las compañías que usan OpenSSL con fines comerciales se harían un favor donando dinero al proyecto. Sería mucho más económico que lo que podría haberles costado el Heartbleed.

Es más, la depuración del código de OpenSSL suele recaer en los miembros principales. Son sólo cuatro, como dije, así que cada uno debería revisar más de 100.000 líneas de código. Si acaso –y la comparación es caprichosa, pero no disparatada– una línea de código equivaliese a una línea en una página de un libro, estamos hablando de repasar 6 millones de caracteres. El equivalente a 2 Biblias completas. Cada uno.

Sí, por supuesto, existen herramientas para verificar de forma automática la presencia fallas como el Heartbleed. ¿Por qué no usaron algo así? Posiblemente porque Seggelmann escogió un pésimo momento para enviar su código: las 8 de la noche del 31 de diciembre de 2011. Ser pocos no sólo significa mucho trabajo para cada uno, sino también que muchas decisiones se toman sin supervisión. Ésta fue una de ésas.

Por añadidura, como señala John Levine en su artículo para CircleID , escribir y depurar software de cifrado es mucho más arduo que hacerlo con programas convencionales. En una aplicación convencional sólo hay que verificar que haga lo que debe hacer y que reaccione de manera controlada ante los errores humanos más comunes (por ejemplo, que pongas letras en un campo que alimenta una variable numérica). En el peor de los casos, una falla hará que el programa se cuelgue.

Con el software criptográfico hay que probar que haga bien su tarea y, además, corroborar que todos los posibles escenarios anómalos no revelen lo que se intenta cifrar.

Una cosa más. El Heartbleed no sólo es un error muy grave, sino también muy insidioso: explotarlo no deja rastros (o son muy sutiles e indirectos). Pero entre que se lo detectó, salió el parche y se corrigieron los sistemas más relevantes pasó poco más de una semana. Es un récord, pero un récord al que el open source está habituado. Nadie dijo nunca que el código fuente abierto previniera los errores, sino que los corrige a una velocidad que el código cerrado sólo puede soñar.

Cuando te conectás al banco o a un sitio de comercio electrónico o entrás en Facebook, Twitter o Gmail, la dirección Web cambia del HTTP normal a HTTPS. La S es por secure, seguro en inglés. Esto significa que se ha puesto en marcha un protocolo llamado TLS (cuyo antecesor se llamaba SSL; de allí OpenSSL), que cifrará el tráfico de datos entre tu dispositivo y el servicio Web. TLS viene de Transport Layer Security y OpenSSL es una de las varias implementaciones que existen de este protocolo. Es también la más popular, y por un motivo muy sencillo: es gratis, incluso para fines comerciales.

Si tu máquina y el servidor Web pasan un rato largo sin intercambiar datos, la sesión segura caduca. Para evitar esta clase de situaciones, Michael Glenn Williams propuso hace dos años la extensión conocida como Heartbeat (latido, en inglés), mediante la RFC 6520 .

Heartbeat hace algo conceptualmente muy sencillo: durante la sesión envía regularmente pequeños paquetes de datos al servidor seguro, que responde con los mismos paquetes. De este modo ambas partes mantienen abierta la sesión. Adicionalmente, Heartbeat informa al servidor el tamaño del paquete que le está enviando. Por ejemplo, 8 bytes (8 caracteres).

¿Dónde estuvo el error? Las versiones 1.0.1 a 1.0.1f de OpenSSL no verificaban que se informara correctamente el tamaño del paquete enviado. Así, un atacante podría enviar un paquete de 8 bytes pero informar un tamaño de hasta 65.536 bytes (un entero de 16 bits). La respuesta del servidor contendría, entonces, no sólo los 8 bytes enviados por el atacante, sino otros 65.528. ¿De dónde saldrían esos caracteres adicionales que el servidor, engañado, envía como respuesta? De lo que está en ese momento en la memoria del programa. Como es una sesión segura, es probable es que allí se encuentren contraseñas y claves criptográficas. Digo es probable porque el fragmento de memoria es copiado al azar.

Ya saben lo que se puede hacer con las contraseñas. Bueno, lo de las claves criptográficas es mucho más serio, porque si capturaste tráfico de un sitio, podés decodificarlo con esas claves. Llegado el caso, también pueden secuestrarse sesiones activas en una VPN. Ayer se supo que habían conseguido quebrar la doble autenticación y el control antifraude de una VPN por medio del Heartbleed, según la compañía de seguridad Mandiant .

Hablé esta semana con Michael Williams, que propuso originalmente la extensión Heartbeat, sobre cuya historia me dijo: "Originalmente se llamaba d-mobi y era una modificación de DTLS (Datagram Transport Layer Security). Su función es permitir movilidad punto a punto basada en una identidad segura, en lugar de basarse en una dirección IP. Esto se hizo para ayudar en la transición de celulares a computadoras móviles, eliminando el problema de pasar de un operador a otro, cambiar de Wi-Fi a datos celulares, etcétera. Heartbeat permite que la conexión se mantenga abierta punto a punto incluso si no ha habido datos fluyendo durante un tiempo".

Respecto del error, Williams me dijo: "Uno de los coautores de Heartbeat [Robin Seggelmann] le dio su código [el que contenía el error] a un voluntario muy senior de OpenSSL. Pero esto ocurrió en unos días muy complicados, justo en las vísperas de año nuevo, y el código fue chequeado sin usar las herramientas que prueban si existe esta clase de errores triviales, errores que ocurren todo el tiempo".

También intenté hablar con Robin Seggelmann, pero por toda respuesta llegó un cordial mensaje de Alexia Sailer, encargada de comunicaciones corporativas de Telecom de Alemania, donde ahora trabaja Seggelmann, diciéndome que debido a la cantidad de solicitudes ya no podía dar más reportajes. Antes de eso, Seggelmann había hablado con The Guardian y con The Sidney Morning Herald.

Williams reconoció, además, que Seggelmann había recibido una cantidad de mails hostiles, algo que para él "carece de sentido".

En los papeles, Heartbleed es una pesadilla. Quienes lo calificaron como el peor desastre de seguridad en la historia de Internet no exageraban (el criptógrafo Bruce Schneier, entre otros).

En la práctica ocurrieron varias cosas, al menos hasta ahora. Primero, que explotar el Heartbleed es muy complicado. Es más probable que estén en riesgo los gobiernos y las grandes empresas, con redes gigantescas, que vos en tu casa (más consejos, abajo). Segundo, OpenSSL y los principales actores de Internet –incluidos los bancos, desde luego– respondieron en tiempo y forma.

Leyendo sobre todo esto encontré, en la semana, un artículo menos apocalíptico sobre Heartbleed , cuyo autor, Steven Bellovin, es profesor de Ciencias de la Computación en la Universidad de Columbia, una de las más prestigiosas en el campo de la seguridad informática.

Me puse en contacto con Bellovin para consultarlo sobre cuáles son los riesgos del Heartbleed para el resto de nosotros y qué hacer para mantenernos razonablemente a salvo. Esto es lo que hablamos.

–Tenés una mirada muy realista del Heartbleed, y hasta ahora tuviste razón, no se produjeron grandes incidentes.

–La seguridad es, en el fondo, un asunto práctico. La pregunta que les enseño a mis estudiantes que deben hacer primero es: ¿Qué están tratando de proteger y contra quien? Ésa es la esencia de lo que publiqué acerca del Heartbleed: para la mayoría de las personas no constituye una amenaza seria.

–¿Por qué no?

–Porque se necesita un adversario realmente poderoso para usar las credenciales robadas. Si hacés home banking desde tu casa, probablemente no estás en riesgo. Ahora, si lo hacés desde un hotspot [un Wi-Fi abierto en un aeropuerto, por ejemplo], es un asunto diferente.

–¿Lo que querés decir es que un atacante puede obtener claves criptográficas, pero encontrará mucha dificultad para usarlas?

–Así es. Puesto de otra forma: vos podés tener una copia de la llave de mi casa, pero estás en la Argentina, no te va a servir de mucho. Incluso si estuvieras en el área de Nueva York, donde resido, todavía tendrías que encontrar mi casa. Sí, podrías lograrlo, pero probablemente, no. Probablemente no es lo mismo que definitivamente, pero es una manera de evaluar los riesgos.

–¿Qué debería hacer un usuario normal, sin formación en sistemas o en ingeniería, para protegerse del Heartbleed?

–Primero, si tenés un sistema vulnerable (el Heartbleed puede afectar también a las máquinas cliente, aunque ese es, según entiendo, un problema mayormente de Android), tenés que obtener el parche de parte del fabricante del dispositivo. Segundo, cambiar tus contraseñas críticas: todas las financieras más la del correo electrónico. ¿Por qué la del correo? Porque tu cuenta de correo es la que se usa para recuperar todas las otras contraseñas, cuando las perdés o te las olvidás. El que la tenga puede robarte muchas otras cuentas.

–Decías que los hotspots abiertos son también un problema.

–Sí, porque, por razones técnicas, es mucho más fácil desviar el tráfico de datos allí que hacerlo con el de tu casa.

–¿Pensás que el error que cometió Robin Seggelmann fue accidental?

–Sí, definitivamente. Un backdoor insertado deliberadamente por una agencia de inteligencia habría sido mucho más sutil. Hace muchos años lideré un equipo que auditaba un sistema importante que pensábamos que había sido saboteado. Pues bien, encontré dos errores separados, ninguno era dañino por sí mismo. Pero juntos podían causar problemas bajo ciertas condiciones. Y todavía hoy ignoro si aquellos dos errores fueron deliberados.

–¿Creés, entonces, que no va a haber incidentes graves causados por el Heartbleed?

–No, no creo que vaya a pasar nada grave, y la mayoría de los sitios ya han instalado los parches necesarios. Puede haber problemas –arrestaron a alguien en Canadá que trató de explotar este error, tengo entendido–, pero en general creo que el riesgo era menor desde el principio y que las partes involucradas respondieron rápida y apropiadamente.

–¿Cuál es, en tu experiencia, el error más común que cometemos con nuestras contraseñas?

–El mayor error que comete el público es reutilizar contraseñas. (Para los programadores, la regla número 1 es: No inventes tu propia criptografía. Se trata de un campo realmente sutil, pero ése es el consejo para el personal técnico.) En cuanto a las contraseñas en sí, elegir una que sea robusta y anotarla o usar un administrador de contraseñas, los hay muy buenos. El consejo de no anotarlas en papel es usualmente equivocado. Lo correcto sería No anotes tus contraseñas donde alguien interesado en robártelas podría verlas. Por ejemplo, la clave de tu home banking en un papelito junto a tu computadora es una mala idea. Pero podés anotarla en un cuaderno y guardarlo en un cajón bajo llave. A todos nos han dicho que elijamos contraseñas robustas y que no las anotemos en papel. Pero ese consejo tiene 35 años de antigüedad, cuando pocas personas tenían más de una cuenta. El mundo ha cambiado, ahora tenemos docenas de cuentas, y el consejo debe cambiar también.

***

Así que, administradores de sistemas, a parchar. Creo que durante las próximas semanas aparecerán varios informes de ataques mediante Heartbleed. Y, como me dijo un amigo por Twitter, también es probable que muchos ataques causados por otros motivos sean atribuidos al Heartbleed.

El resto de nosotros, a cambiar contraseñas. Un buen administrador de claves, aqu í. Y evitemos los Wi-Fi abiertos para sesiones HTTPS.

Información adicional y herramientas

* La extensión antiphishing de Netcraft ahora permite, en Chrome y Opera, determinar si el sitio que estás visitando es vulnerable al Heartbleed

* La absolutamente genial (bueno, nos tiene acostumbrados) descripción del Heartbleed de XKCD

* Link al aporte de Seggelmann que contenía el error. Puede verse la fecha y hora en que se subió el código con la falla: 31 de diciembre de 2011 a las 19,59.

* Como habrán notado los especialistas, la explicación que di más arriba sobre el Heartbeat y el Heartbleed deja de lado asuntos importantes, aunque excesivamente técnicos (como la gestión de memoria). Para ellos, dos sitios con análisis más profundos del Heartbleed, incluido el código fuente del error y del parche

lanacionar

---

Conforme a