• Botón Web Micronet
  • Botón Facebook
  • Botón Google Plus
  • Botón Twitter
  • Botón Youtube
  • Botón RSS
    • Un fallo de seguridad en OpenSSL compromete certificados y credenciales que, hasta ahora, considerábamos seguras

      espiaQuienes me conocen saben que me tengo por una persona mesurada y que evita el amarillismo. Más bien al contrario, así que escribir un titular como el que tiene esta noticia… bueno, te aseguro que no me ha resultado fácil. Pero es que el problema, detectado de manera casi simultánea por dos equipos distintos de investigadores, ha comprometido dos tercios de las comunicaciones supuestamente seguras que hemos efectuado durante los últimos dos años. Sí, has leído bien, precisamente las que parecían seguras. El fallo de seguridad, denominado Heartbleed, y cuya referencia oficial es CVE-2014-0160, ataca precisamente las conexiones supuestamente seguras. Pero, ¿en qué consiste esta amenaza? En primer lugar hay que tener en cuenta algunos conceptos técnico. El fundamental, en este caso, es que cuando se establece una conexión segura entre un servidor web y tu navegador, son varios los elementos que intervienen. Uno de ellos es la biblioteca (un conjunto de recursos reutilizables) que emplea el servidor para el cifrado de la conexión. Por otra parte están los certificados de seguridad, y finalmente las claves de acceso a servicios y demás. El problema es que, según han descubierto los investigadores, las últimas versiones de la biblioteca OpenSSL, que es la más empleada para dichos fines, tiene un problema de seguridad, que compromete la seguridad tanto del servidor como de los clientes que se conectan al mismo. Y, hacer uso del mismo, permitiría a un atacante acceder a todos los datos que se van a transmitir de forma segura antes de que sean cifrados.

      ¿Cómo funciona?

      open sslComo ya te comentábamos anteriormente, aprovecha una vulnerabilidad de las últimas versiones de la biblioteca OpenSSL (desde 1.0.1 hasta 1.0.1f), concretamente una función llamada Heartbeat, que se activa (o no) en la conexión durante la fase inicial de la misma, cuando servidor y cliente realizan el llamado handshake, momento en el que establece la conexión y se negocian diversos parámetros de cómo se efectuará la conexión. El problema es que, de una manera no demasiado compleja, un atacante puede aprovechar dicha función para acceder a toda la información que se almacena en la memoria del cliente, antes de que esta sea cifrada para transmitirse a través de Internet.

      Para que la información se transmita de manera segura a través de Internet, antes de ser enviada es cifrada en el ordenador de origen, empleando para ello la clave pública del destinatario. Los datos se envían cifrados a través de Internet y, una vez que llegan al destinatario, este los descifra con su clave privada. El problema es que, para ser cifrados, los datos primero se cargan en memoria y, desde ahí, son procesados. Así que si alguien tiene acceso a la memoria del sistema, verá precisamente toda esa información que va a ser cifrada, antes de que se lleve a cabo este proceso. Y lo mismo, claro, ocurre “al otro lado”, es decir, una vez que los datos llegan al servidor. Entonces, se carga en memoria la clave privada, los datos codificados, y se descifran para poder acceder a su contenido. Y este punto es todavía más peligroso, ya que si alguien se hace con la clave privada del servidor, podrá descifrar todas las comunicaciones que los clientes cifren empleando su clave pública.

      ¿Qué datos se han visto comprometidos?

      Los investigadores que han detectado el problema, dividen la información que se ha visto comprometida en cuatro grandes grupos:

      1. Llave primaria (Primary Key): La joya de la corona, denominan a esta clave los “descubridores” del agujero de seguridad. Se trata de la clave privada del servidor, y con ella (y aviesas intenciones) se pueden descifrar todas las comunicaciones “seguras” remitidas al mismo. Cualquier tipo de protección ofrecida por sistemas de cifrado basada en firmas con certificados de seguridad X.509 puede ser evitado.
      2. Llave secundaria (Secondary Key): Aquí hablamos de las credenciales que se comparten cifradas. Para que nos entendamos, nombres de usuario y contraseñas, direcciones de email… es decir, los datos con los que inicias sesión en servicios online, accedes al correo, etcétera.
      3. Contenido protegido (Protected content): En esta “capa” se encuentra el contenido protegido con dichas claves: datos de tu banca online, correos electrónicos… es decir, todos los datos que, en teoría, estaban seguros gracias al cifrado.
      4. Colateral o secundario (Collateral): Aquí se incluyen datos relativos a la conexión que, por ejemplo, pueden revelar aspectos adicionales de la misma que se pueden emplear con fines malintencionados.

      ¿Cómo puedo saber si me ha afectado?

      Esto es, sin duda, es uno de los aspectos más preocupantes de este agujero de seguridad. Y es que las posibles actividades no dejan rastro alguno en los logs de los sistemas atacados. Esto quiere decir que, potencialmente, cualquier conexión “segura” en la que el servidor tuviera una versión comprometida de OpenSSL puede haberse visto comprometida. Y que no hay manera alguna de saber si esto ha ocurrido o no. Por lo tanto, se puede decir que dos de cada tres operaciones llevadas a cabo a través de conexiones “seguras” han estado expuestas.

      ¿Cómo se soluciona?

      seguridadEn primer lugar, claro, es necesario que los administradores de servicios que empleen OpenSSL, se aseguren de actualizarse a la última versión, pues las anteriores (hasta hace dos años) tienen esa vulnerabilidad. En realidad, el agujero no se ha hecho público hasta que no ha existido una versión que lo corrige. Sin embargo, el plazo entre el lanzamiento de una nueva versión y la actualización a la misma por parte de los administradores puede llevar un tiempo. Aquí, procede que actúen de manera expeditiva, pues de lo contrario, si mantienen versiones antiguas, seguirán comprometiendo la seguridad de sus usuarios. Una vez llevada a cabo esa actualización, hay que volver a proteger los datos.

      1. Llave primaria (Primary Key): Esta parte corresponde a los servicios cuyas claves privadas se hayan podido ver comprometidas, esto es, todos los que empleen o hayan empleado alguna de las versiones inseguras de OpenSSL (las comprendidas entre 1.0.1 y 1.0.1g). Tendrán que volver a generar nuevas claves privadas y públicas, así como a obtener su validación por parte de las entidades certificadoras. Mientras que los servicios online afectados no lleven a cabo este paso, de nada servirán las medidas que puedan tomar los usuarios.
      2. Llave secundaria (Secondary Key): Una vez que un servicio haya asegurado el canal de comunicación con nuevas firmas certificadas, todos sus usuarios tendrán que conectarse al mismo y cambiar sus credenciales de acceso. Sin excepción. Además, a la hora de hacerlo, tendrán que seguir las indicaciones que reciban por parte del proveedor del servicio, para asegurarse de que la conexión se está llevando a cabo de la manera correcta. También será necesario eliminar cookies, contraseñas y demás en tu navegador web.
      3. Contenido protegido (Protected content): Aquí poco se puede hacer. Si en algún momento tus datos se vieron expuestos y alguien accedió a ellos… no hay solución.
      4. Colateral o secundario (Collateral): Estos, como ya comentamos anteriormente, son circunstanciales y, por norma general, sólo están relacionados con la conexión establecida en ese momento. Es decir, que puedes despreocuparte, ya que no tienen mayor importancia a posteriori.

      ¿Es un problema de seguridad de SSL?

      No. SSL, como tal, sigue siendo un sistema seguro. El problema de Heartbleed está en la implementación del mismo en las últimas versiones de la biblioteca OpenSSL. Por lo tanto, si al conectarte a un servicio (que ya se ha actualizado, claro), ves que emplea SSL no temas, el problema está localizado sólo en la biblioteca, no en el sistema.

      Es decir, que una vez restaurada la confianza (actualización de OpenSSL en los servidores, generación de nuevas firmas y certificados, cambio de credenciales de acceso, etcétera), los sistemas deberían volver a ser seguros. No obstante, y por ahora, habrá que ser muy cautos, y esperar a ver cuán rápidos son los principales servicios online, así como los que gestionan información particularmente reservada, en realizar todas las actualizaciones de seguridad necesarias.

       
      FUENTE: Heartbleed