versión para imprimir - envía este articulo por e-mail

Algunas recomendaciones críticas sobre el fallo de OpenSSL (Heartbleed)
Por Fernando Acero - Kriptópolis - Sunday, Apr. 27, 2014 at 8:36 PM

22/04/2014

heartbleed.png, image/png, 341x413

Parece que la comunidad de software libre en particular, y los usuarios de Internet en general, no ganan para sustos y preocupaciones en los últimos días. A fecha de hoy han aparecido problemas en la práctica totalidad de las tecnologías que se usan para hacer que las conexiones sean seguras en Internet y en especial, GnuTLS y OpenSSL. Pero también debemos recordar que hace unos años también hubo serios problemas de seguridad con SSH.

Como ya se ha escrito y hablado mucho sobre el fallo de OpenSSL y llego un poco tarde con mi artículo, solamente resumiré e intentaré aclarar algunas cosas y en la medida de lo posible, aprovecharé para actualizar algo la situación y recomendar algunas acciones prácticas.

 

Un poco de lo que sabemos

En relación al fallo de OpenSSL sabemos, entre otras cosas, lo siguiente:

a) Es un fallo que lleva algo más de dos años en el código de OpenSSL y convierte inseguras desde la versión 1.0.1 a la 1.0.1f, siendo la versión 1.0.1g, la que resuelve el problema en este momento. Por ser un programa ampliamente utilizado para asegurar las conexiones en Internet, ha afectado a una gran cantidad de servidores y conexiones seguras de todo tipo. Entre los servidores que han podido estar afectados, se han incluido en algunas listas los de Google, Yahoo, Facebook o Twitter, etc. Pero dada la marcada polémica suscitada con la publicación de las listas de servidores afectados y pensando en lo que nos puede pasar en el peor de los casos, lo más razonable es pensar que cualquier servidor ha sido afectado, incluido el de nuestro banco y tomar a la mayor brevedad las medidas que recomendaré más adelante.

b) Este fallo permite obtener todo el contenido de la memoria de un servidor en bloques de 64 kB y ello incluye, entre otras cosas jugosas, las claves privadas usadas para identificar el servidor y asegurar las conexiones SSL. Una vez obtenidas, es posible suplantar dicho servidor y actuar como MitM. Pero como he adelantado en la primera frase de este párrafo, también se puede extraer cualquier otra información que esté siendo procesada en el servidor en ese momento. Eso incluye los datos personales de los usuarios, o sus claves de acceso al servidor. Asimismo, es importante saber, que si un servidor afectado ha sido atacado explotando este fallo en SSL, puede que no quede ningún rastro en el mismo que demuestre que ello ha sido así.

Si tenemos en cuenta lo que hemos dicho en el punto anterior y lo que hemos dicho en este, es posible que algunos responsables de servidores que fueron afectados por el fallo, no lo reconozcan abiertamente por problemas de reputación, o simplemente, aunque estuvieron afectados y es un hecho evidente para ellos por la versión de OpenSSL que utilizaban, desconocen si han sido atacados, o las consecuencias del ataque, por lo que no alertan a sus usuarios. Por lo tanto, mi recomendación en este caso, es ponerse siempre en el peor caso posible y actuar en consecuencia.

c) Aunque el fallo afecta principalmente a servidores y conexiones VPN (Redes Privadas Virtuales), lo que incluye infinidad de servicios en la nube, también puede afectar a otros dispositivos de nuestro entorno que pueden usar OpenSSL para asegurar ciertas conexiones. Por ejemplo: smartphones, puntos de acceso WIFI, tablets, routers ADSL, switches configurables, Smart TV's, receptores de satélite, reproductores multimedia o dispositivos de almacenamiento masivo (NAS) con conexión a Internet, etc.

Recordemos que Android se basa en el kernel de Linux y que tanto Android como Linux, están disponibles en varios miles de millones de dispositivos en este momento. Sin embargo, en muchas ocasiones, como meros usuarios de la tecnología, no somos conscientes del software que usa realmente nuestro flamante dispositivo.

Aprovecho para traer a estas líneas, algo que ya se está comentando con cierta preocupación en algunos foros. La llegada del Internet de las cosas provocará que este problema se multiplique de forma exponencial y más, si los fabricantes de hardware no se conciencian de que la seguridad de sus dispositivos debe estar en el ciclo de vida de los mismos como una de sus prioridades fundamentales. El problema para los fabricantes que opten por fabricar equipos que exploten las enormes posibilidades del Internet de las cosas, es que el ciclo de vida para muchos de estos dispositivos de uso común puede ser extremadamente largo en relación a los ciclos de vida del software.

d) Aunque Robin Seggelmann, el desarrollador que introdujo el error en 2012, ha declarado y en varias ocasiones, que no lo hizo de forma deliberada y que la NSA no estaba detrás del fallo, posteriormente, la agencia de noticias Bloomberg ha anunciado que la NSA conocía el fallo desde sus orígenes y que lo estaba explotando activamente. Como no podía ser de otro modo, la NSA ha negado posteriormente que esa noticia fuera cierta, por lo que cada uno puede pensar lo que quiera al respecto.

e) Aunque todos los expertos en seguridad coinciden al decir que el error es muy grave y que Bruce Schneier incluso ha llegado a decir textualmente lo siguiente:"Catastrophic is the right word. On the scale of 1 to 10, this is an 11", lo cierto es que el NIST ha clasificado esta vulnerabilidad como de riesgo medio CVSS v2 Base Score: 5.0 (MEDIUM) (AV:N/AC:L/AU:N/C:P/I:N/A:N), lo que puede llevar a cierta polémica.

f) Después de descubrirse el fallo, aparecieron una serie de noticias relacionadas con la explotación del mismo, como la relacionada con el joven canadiense arrestado por usar dicha vulnerabilidad de forma efectiva con los servidores de Canada Revenue Agency (CRA) o la relacionada con la explotación con éxito de la vulnerabilidad contra los servidores de Yahoo mail. Pero ¿cómo se han podido detectar este tipo de ataques, cuando decimos que no deja rastro en un servidor?. Evidentemente al mismo tiempo que han aparecido los programas que explotan el problema, también han aparecido las contramedidas especializadas para detectarlo y minimizarlo. Por lo que si alguien usa algún exploit relacionado con HeartBleed contra un servidor, debe saber que puede ser cazado en el intento y que igualmente, puede tener que responder por ello.

También se ha comentado, en base a un ataque realizado con éxito poco después de desvelarse la vulnerabilidad, que para explotarla con éxito era necesario que los servidores hubieran sido arrancados inmediatamente antes del ataque, lo que es improbable que ocurra en un sistema en producción. Pero desde mi punto de vista, lo único que se logra si ataca un servidor cuando acaba de ser arrancado, es facilitar la localización en la memoria de la información relevante para el atacante, por ejemplo, la posición en memoria de los certificados digitales del servidor. Si algo está en la memoria del servidor, dadas las características del fallo y con independencia del momento en el que se realice el ataque, siempre estará disponible para un eventual atacante que tenga paciencia para localizarla.

Más recientemente se ha usado dicha vulnerabilidad para saltarse la seguridad de Redes Privadas Virtuales, lo que abre una nueva y preocupante dimensión al problema de Heartbleed.

También se ha comentado algo que es muy preocupante para muchos usuarios de la Red Tor, la existencia de nodos de dicha Red, teóricamente segura, que eran vulnerables a Heartbleed. Dicho descubrimiento ha provocado que los responsables de la Red Tor, comiencen a rechazarlos mediante la creación de una "black list" de los mismos. Sin embargo, ¿cómo se puede tener la seguridad en una red abierta, como es el caso de Tor, de que los nodos que estamos usando en determinado momento no están afectados?. ¿Quién garantiza que en un momento determinado no se introduzca de forma maliciosa un nodo vulnerable en la Red Tor con el objeto de monitorizar el tráfico e la Red Tor?. Ante esta situación, hay algunos que aconsejan alejarse de la Red Tor, o incluso de Internet, durante un tiempo, si es que se necesita de privacidad.

g) El que no se haya actualizado al día de la fecha está en grave riesgo y va con tiempo negativo. En este momento no paran de salir a la luz pruebas de concepto (PoC) y exploits relacionados con esta grave vulnerabilidad del OpenSSL. Esto hace que el riesgo crezca de forma exponencial con el tiempo para los más retrasados. Como están las cosas, un eventual atacante, incluso con pocos conocimientos sobre el tema, dispone de todo lo necesario para tener éxito en un ataque:

1. Sabe que existe una vulnerabilidad.
2. Dispone de herramientas para saber si una determinada página es vulnerable.
3. Dispone de software para atacar de forma efectiva un servidor vulnerable.

 

Qué podemos hacer

Las acciones a tomar para protegernos dependerán de si tenemos un servidor, somos clientes de un servidor seguro (https), o si tenemos hardware afectado, por lo que revisaremos cada caso de forma individual.

a) Si tenemos un servidor seguro, las acciones son cuatro y han de ser inmediatas:

1. Revocar nuestros certificados digitales del servidor.
2. Instalar la nueva versión de OpenSSL, la 1.0.1g o superior.
3. Solicitar e instalar nuevos certificados digitales.
4. Solicitar a todos los usuarios del servidor que cambien sus contraseñas lo antes posible.

b) Si somos usuarios o clientes de servidores seguros, lo que me atrevo a decir que somos todos los que usamos Internet, la acción es única y también ha de ser inmediata. No es otra que cambiar todas las contraseñas que usamos normalmente para conectarnos a servidores seguros a través de Internet. Por ejemplo: redes sociales, correo electrónico, servicios bancarios, administración electrónica, etc.

Los usuarios también deben tener en cuenta dos cosas en relación a la actualización de sus contraseñas:

1. Si quieren saber si un determinado servicio está afectado en la actualidad, pueden usar esta página de McAfee para comprobarlo. Evidentemente si el servidor todavía está afectado, no tiene mucho sentido cambiar nuestra contraseña, por lo que en este caso lo que debemos hacer es enviar un correo a su administrador indicándole que su página es vulnerable y no conectarnos a dicha página, ni cambiar nuestra contraseña, hasta que no lo solucionen adecuadamente. Si usamos nuestras contraseñas, o intentamos actualizar nuestras contraseñas en este momento sobre un servidor que todavía no ha sido actualizado, lo más probable es que sean robadas sin remedio.
2. Si recibimos un correo electrónico indicando que debemos cambiar nuestras contraseña en determinado servicio (red social, banco, etc) y dicho correo viene con un enlace, debemos desconfiar y no usar dicho enlace para cambiar nuestras contraseñas. Lo más probable es que sea un ataque de phishing que usa una URL falsa y su intención es robarnos limpiamente la contraseña que introduzcamos. Si queremos conectarnos a una página segura o cambiar nuestras contraseñas de acceso a las mismas, lo que debemos hacer siempre es acceder directamente a la página escribiendo la URL (https) en el navegador. No debemos usar nunca un enlace recibido mediante un correo electrónico, aunque nos parezca legítimo y la página a la que accedemos a través de él nos parezca la correcta primera vista.
3. También es muy sano, tras conectarnos a una web segura (https), que antes de introducir nuestras credenciales, es decir, nuestro nombre de usuario y contraseña, que comprobemos el certificado digital de dicha página, para ver que se corresponde con la página que esperamos y que es válido.

c) Si tenemos hardware que pueda estar afectado, el problema se complica y mucho por dos motivos principalmente. El primero, es que es difícil saber, sin la ayuda del fabricante del mismo, si nuestro hardware es vulnerable ante un determinado problema de seguridad, como es el caso del OpenSSL. El segundo, es que siempre dependemos para su actualización de nuestro smartphone, tablet, router, etc, y en la mayoría de los casos de forma secuencial en el tiempo, del fabricante del software origen del problema, en este caso OpenSSL, del fabricante del software que lo integra, por ejemplo Google, del fabricante del hardware que lo usa, por ejemplo Samsung, o incluso, del proveedor de servicios de Internet que lo comercializa (por ejemplo, una compañía telefónica, que en ocasiones personalizan el software). Esta absurda cadena alarga los tiempos de actualización de los dispositivos más de lo necesario y hace que una vulnerabilidad, por pequeña que sea, se pueda convertir en una pesadilla para los usuarios, en especial si afecta, como es el caso, a su información sensible, o le provoca molestas denegaciones de servicio.

En estos casos debemos hacer lo siguiente:

1. Consultar al fabricante del dispositivo, o al proveedor de servicios de Internet que lo comercializa, sobre el problema y preguntarle si hay disponible una actualización de seguridad para el mismo en ese momento.
2. Si la hay y está disponible para nosotros, instalarla lo antes posible y siguiendo las indicaciones del fabricante del dispositivo.
3. Si no está disponible, consultar al fabricante o al proveedor de servicios de Internet que lo comercializa, sobre la forma de protegernos hasta que esté disponible la actualización que corrija el problema.

Tanto Microsoft como Apple han manifestado que tanto los dispositivos basados en Windows Mobile, como en iOS y OSx, así como sus servicios web, no están afectados por el problema del OpenSSL.

En el caso de Android, los móviles más vulnerables al fallo de OpenSSL son los que tienen versiones 4.1 de este sistema operativo, aunque también es cierto, que algunas versiones de Android 2.4 Jelly Bean, que han sido personalizadas por fabricantes u operadores, también pueden ser vulnerables.

Incluso móviles que se han actualizado recientemente a Android KitKat 4.4 pueden estar afectadas por este fallo, por usar versiones de OpenSSL tan antiguas como la 1.0.1e. Sin embargo, aunque tengan instalado un OpenSSL afectado en un dispositivo Android, la posibilidad de explotación del fallo también depende de la configuración del móvil, por lo que lo mejor es usar la aplicación indicada anteriormente para comprobarlo.

De todos modos, si nuestro smartphone está afectado por el fallo, lo más recomendable es no usarlo para realizar conexiones seguras, o manejar información sensible, hasta que dispongamos de una actualización adecuada, lo que puede tardar bastante, si además de Google, dependemos del fabricante y/o del operador para hacerlo.

Existen algunas opciones para saber si nuestro smartphone está afectado por problemas con el SSL o con el TLS:

a) Apple (fallo en el TLS por goto fail).
b) Aplicación Android para comprobar el fallo de OpenSSL.

Pero esta seguridad en relación a los sistemas operativos de los smartphones es relativa. Aunque nuestro smartphone no se vea afectado por el problema de OpenSSL y esto es aplicable de forma indistinta a dispositivos Android, iOS, o Windows Mobile, eso no nos garantiza que no se haya utilizado para acceder a un servidor vulnerable. Por lo que debemos estar atentos a todas las actualizaciones de aplicaciones que se produzcan estos días en relación a este fallo de seguridad y si sabemos que una aplicación móvil ha sido afectada, ya sea por usar la librería afectada internamente, o por conectar con un servidor afectado, no debemos utilizarla hasta que se actualice la aplicación y/o el servidor del servicio y cuando todo esté en orden, deberemos cambiar la contraseña de acceso a dicho servicio lo antes posible.

 

"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."

 

www.kriptopolis.com/recomendaciones-heartbleed

agrega un comentario