Homebanking, correos electrónicos, libros y todos los servicios de pago y transacciones seguras en Internet están comprometidos. ¿Por qué? ¿Cómo funciona?¿Qué hacer? Enterate aquí.
A ver, se ha armado un escandalete importante con el tema de Hearthbleed. Este tipo de cosas se rigen por el miedo, tratá de no dejarte llevar y ser muy cuidadosa. Hay muchísimas lectoras consultándonos qué hacer, y cómo corregir el problema. Ante esto, hacemos esta nota, y aclaramos de arranque: si utilizás las librerías OpenSSL: buscá y aplicá el parche. Si no, seguí leyendo.
OpenSSl es un proyecto libre desarrollado por Eric Young y Tim Hudson. Se trata de un conjunto de herramientas relacionadas con la criptografía, que trabaja en conjunto con otros paquetes como OpenSSH (los famosos accesos shell) y HTTPS (sí, ese que tiene la «s» de secure al final). El fallo es bastante grande. Bah, no es un «fallo», es un agujero de seguridad, un bug, que según cálculos afecta aproximadamente al 60% de las comunicaciones «seguras» que existen en Internet.[pullquote] Igualmente, la idea de que algo en Internet es «seguro», es sólo una idea, sabelo[/pullquote].
Si bien una usuaria doméstica puede establecer servicios de conexiones seguras, por lo general, lo que hará es ser usuaria de las conexiones seguras provistas por alguna empresa (homebanking, webmails como gmails, entre otros servicios), por lo que vos no tenés que hacer nada en tu PC, salvo que utilices estos servicios ejecutándose EN tu máquina. Si no usás OpenSSL en tu máquina, entonces no podés hacer más que esperar hasta que las empresas que administran los servidores que usás (como los de Google), apliquen el parche para resolver el bug.
¿Cómo es el fallo?
El bug encontrado está en una función que gestiona los mensajes «Heartbeat» (de ahí el juego de palabras, heartbeat es el latido del corazón, heartbleed es un corazón sangrante). Lo que hacen estos mensajes es avisarle al servidor que todavía estamos conectadas, para que no cierre la conexión pues tiene un tiempo de inactividad estipulado, algo muy utilizado en algunos servidores para evitar que se sobrecarguen (muchas sesiones abiertas equivalen a mucho consumo de recursos).
Cuando se emite un latido, el servidor te responde con otro de igual longitud. En este último dato está la clave: si le enviás al servidor un mensaje de 1 byte, pero le decís que estás enviando mil, actúa el bug y el servidor te devuelve un mensaje «igual» al que enviaste. Como [pullquote position=»right»]enviaste sólo un byte, pero el servidor cree que enviaste 1000 y debe responderte con un mensaje de igual longitud, entonces completa la información con otros 999 bytes[/pullquote], y allí divulga contraseñas, usuarias y todo tipo de información confidencial.
¿Por qué responde con información confidencial?
Por el lenguaje en que está escrito OpenSSL: C. En este lenguaje la variable «paquete» es una dirección (un lugar), en la memoria RAM. Cuando un paquete llega lo hace a un lugar de la memoria RAM. En esta memoria se almacenan temporalmente diversas informaciones (todo lo que está abierto y funcionando). Suponete que la dirección a la que llega el mensaje es la 1200. El servidor, «acostumbrado» a enviar la misma cantidad que recibe, le «contesta» enviando el mismo mensaje la longitud de caracteres que el paquete le dice que tiene. Si el paquete dice tener 1000 caracteres, y llega a la dirección 1200, entonces ocupará desde 1200 a 1300. Pero OpenSSL no chequea la longitud de un paquete, por lo que si el paquete dice tener 1000 caracteres y tiene 1, el servidor devolverá lo que se le envió, y todo lo que haya en la memoria desde 1201 a 1300. Y ahí está el problema.
Lo bueno es que no se puede saber qué hay en esas direcciones, puede ser cualquier cosa, desde basura hasta virus o spam, pero también puede estar la clave del servidor. Por cada ataque se pueden recuperar 64 Kb de información de la memoria del servidor. Si repetís muchas veces el ataque te vas a llevar muchísima información, como ves, es un fallo muy grave.
No entendí nada… ¿Cómo funciona?
La gente de XKCD publicó un comic bastante simpático explicando el error.
¿Me afecta si no tengo un servidor? Sí.
Por eso te decía más arriba que leyeras la nota. Heartbleed afecta a los servidores, ciertamente, el asunto es que los servidores son utilizados por… ¡usuarias! y si controlamos un servidor, podemos hacer, entre muchas otras cosas, un ataque man in the middle. Esto es simple: es meterse en medio de la conexión entre una usuaria y su servidor. Si tenemos, por ejemplo, la clave de un servidor de (ponele) un banco, entonces nos podemos hacer pasar por un servidor legítimo de ese banco, y hacerte creer que estás conectada al homebanking, pero en realidad estás en mi servidor, dándome toda tu información sin darte cuenta.
Ahora, para sumar un poquito de nerviosismo, te repito que el porcentaje de servidres comprometidos: 60%.
Tal vez estés pensando que basta con cambiar las claves… bueno, no. Porque además de obtener las claves, se puede directamente, robar la sesión de una usuaria. Lo más interesante es que este ataque no deja ningún registro. Se sabe que esta vulnerabilidad tiene unos 2 años, lo que no se sabe es cuánta gente la ha estado explotando en este tiempo. Nos consta que algunas hackers conocen la vulnerabilidad hace un tiempo. Obviamente, no nos lo habían contado sino hasta que se masificó su existencia.
¿Cuándo va a estar arreglado?
Ya lo está. El asunto es que cada servidor tiene que aplicar el parche y hasta que esto suceda no es conveniente realizar operaciones críticas online.
Si tenés alguna urgencia, consultá a quien administre el servdor. Si es un banco, llamá al banco, si es una mega empresa como Gmail, entonces fijate en sus blogs y redes sociales.
¿Querés más información? Aquí hay más.
¡Happy Hacking!