A principios de semana se destapó al mundo posiblemente una de las vulnerabilidades más graves de la historia de Internet tanto por importancia como por alcance.
Heartbleed es un agujero de seguridad encontrado en algunas versiones de OpenSSL, concretamente desde la 1.0.1 y la 1.0.1f, que permitiría a un atacante acceder a parte de la memoria del proceso del mismo; algo que se vuelve aún más delicado al tener en cuenta que OpenSSL juega un papel clave en el cifrado de las comunicaciones en Internet.
¿Y esto qué significa? Pues significa tener acceso a datos tan comprometedores como: claves de los servicios, cuentas de usuario y contraseñas, claves privadas, etc.
¿A quién ha afectado todo esto? Algunas fuentes afirman que ha afectado a millones de servidores en todo el mundo. Por supuesto, entre ellos, los servidores de los llamados gigantes de Internet como Google, Yahoo!, Amazon, etc. De ahí la importancia del bug. Heartbleed afecta a muchísimos servidores, muchos de ellos muy importantes y, además, a una parte del sistema de una sensibilidad extrema.
Aquí os dejo un enlace donde poder comprobar si nuestro servidor es vulnerable a Heartbleed: http://filippo.io/Heartbleed/
Solo tenemos que introducir la dirección de nuestro servidor donde aparece el texto “example.com” y pulsar sobre “GO” para que la web nos indique si somos vulnerables o no.
Una vez analizado el bug, vamos a intentar aportar soluciones y centrarnos en cómo enfrentarnos a este problema, orientando a los administradores de sistemas en la reparación del bug y a los usuarios, dándoles una serie de buenas prácticas:
Por el momento existen dos posibles soluciones para reparar la vulnerabilidad de los servidores pero, ¿quién nos asegura que nuestras claves no han sido comprometidas ya?
Empezamos con la parte mas técnica.
Por el momento existen dos métodos para arreglar la vulnerabilidad:
Método 1: Para usuarios que utilizan OpenSSL sobre sistemas Linux – Actualización de OpenSSL
Los chicos de OpenSSL se han apresurado en corregir el grave fallo que tenían en las versiones comprendidas entre 1.0.1 y la 1.0.1f (ambas inclusive) y han lanzado una actualización de versión (1.0.1g) con la que ya no seríamos vulnerables.
Lo tenemos tan fácil como actualizar el software y reiniciar los servicios que lo utilicen.
Como apunte, en los repositorios oficiales de Debian y de RedHat ya está disponible la versión parcheada de la que hablamos con lo que con un simple “apt-get upgrade openssl” en caso de Debian o “yum update openssl” para quien utilice RedHat o CentOS sería suficiente para reparar el agujero.
Método 2: Cortar la conexión vía cortafuegos
Se ha publicado otra posible solución para prevenir las conexiones concretas que aprovechan esta vulnerabilidad mediante cortafuegos. Para los usuarios de Linux que utilicen iptables la línea que detectaría la conexión maliciosa y la cortaría sería la siguiente:
iptables -t filter -A INPUT -p tcp –dport 443 -m u32 –u32 «52=0x18030000:0x1803FFFF» -j DROP
Ya lo tenemos reparado, ¿y ahora qué?
Como no se sabe exactamente desde cuándo está vigente esta vulnerabilidad puede que nuestros datos estén ya comprometidos a pesar de haber reparado la vulnerabilidad. Con lo que tanto por parte de los administradores, como por la de los usuarios, sería recomendable seguir una serie de buenas prácticas:
Primero: cambiar todos los certificados digitales de todos los servidores, no importa el servicio. Lo recomendable sería cambiarlos todos.
Segundo: pedir a todos los usuarios que cambien las contraseñas de todos sus servicios para prevenir sustos posteriores. Este consejo es válido también para los usuarios de servicios de Internet tales como correo electrónico, banca online, e-commerce, etc.