Heartbleed Representa un Riesgo para Clientes y el Internet de las Cosas
Si bien la mayor parte de la atención en Heartbleed ha estado en los sitios web públicos vulnerables, este bug afecta más que eso. Si bien la mayoría de los sitios más populares ya no están vulnerables, esto no significa que los usuarios podamos bajar la guardia.
Heartbleed afecta por igual a clientes de software como a clientes web, de correo electrónico, clientes de chat, clientes FTP, aplicaciones móviles, clientes VPN y actualizadores de software, por nombrar algunos. En definitiva, cualquier cliente que se comunica a través de SSL/TLS utilizando la versión afectada de OpenSSL es vulnerable a los ataques externos.
Adicionalmente, Heartbleed afecta a otros servidores además de los servidores Web. Estos incluyen proxies, servidores de medios , servidores de juegos, de bases de datos, de chat y FTP. En este escenario, los dispositivos de hardware no son inmunes a la vulnerabilidad ya que ésta puede afectar a los routers, PBX (sistemas de teléfono empresariales) y probablemente numerosos dispositivos del Internet de las Cosas.
Atacar estos servidores de software y hardware por medio de la vulnerabilidad Heartbleed se realiza de una manera similar a como se hace en los ataques a los sitios web vulnerables. Sin embargo, los ataques a los clientes pueden suceder prácticamente de la manera inversa.
De forma general, la explotación de Heartbleed ha sido descrita como un cliente que envía un mensaje malicioso de Heartbeat a un servidor vulnerable y el servidor expone información privada. Sin embargo, el proceso a la inversa también podría darse. Es decir, un cliente vulnerable puede conectarse a un servidor, y el propio servidor puede enviar un mensaje Heartbeat malicioso para el cliente. Entonces, el cliente responderá con datos adicionales que se encuentran en su memoria, lo que podría exponer credenciales de acceso y otros datos privados.
Figura 1. La forma en que un cliente vulnerable es atacado, es a la inversa de un ataque que se da en un servidor
Afortunadamente , aunque los clientes son vulnerables, en el mundo real este escenario puede ser difícil de explotar. Los dos principales vectores de ataque instruirían al cliente a visitar a un servidor SSL/TLS malicioso o secuestrarían una conexión a través de una debilidad sin relación. Ambas cuestiones presentan al atacante una complicación adicional.
Llevando al cliente a un servidor malicioso
El ejemplo más simple de cómo se puede explotar un cliente es a través de algo como un navegador Web vulnerable. Uno simplemente tiene que convencer a la víctima de visitar una URL maliciosa con el fin de permitir que el servidor atacante tenga acceso a la memoria del navegador Web del cliente. Esto pone en riesgo el contenido como las cookies de sesiones previas, sitios web visitados, datos de formularios y las credenciales de autenticación.
Cabe mencionar que la mayoría de los navegadores Web más populares no utilizan OpenSSL, sino las bibliotecas NSS (Network Security Services) que no son vulnerables a Heartbleed. Sin embargo, muchos clientes Web de línea de comandos hacen uso de OpenSSL (por ejemplo, wget y curl) los cuales son vulnerables.
La necesidad del atacante de engañar a un usuario para que visite un sitio malicioso puede mitigar algunos riesgos, pero no siempre es necesario. Imaginemos un servicio de traducción de idiomas en línea donde proporcionamos a un servicio automatizado una URL de una página en francés y el servicio nos traduce el contenido a español. Detrás de la pantalla, el servicio está buscando el contenido de la página en francés utilizando su propio cliente de backend. Pero, si damos la dirección URL de un servidor malicioso, el cliente backend puede ser explotado y el atacante podría obtener información confidencial, como código o las credenciales de acceso del servicio de traducción.
Secuestrando una conexión
Dirigir a los clientes a un servidor malicioso como se describió anteriormente require instruirlos para visitar servidores arbitrarios. Sin embargo, muchos clientes sólo pueden comunicarse con un dominio codificado preestablecido. Aún en estos casos, el cliente todavía puede ser explotado. En las redes abiertas compartidas como ciertas redes WiFi públicas, el tráfico puede ser visible y alterado por otros, permitiendo a los atacantes redirigir a los clientes vulnerables. Normalmente, SSL/TLS (por ejemplo, HTTPS, navegación web encriptada) es una de las soluciones a este problema, ya que el cifrado evita el espionaje y el redireccionamiento. Sin embargo, uno puede enviar mensajes de Heartbeat maliciosos antes de que la sesión SSL/TLS esté plenamente establecida.
Un atacante puede unirse a una red pública y espiar a las posibles víctimas. Cuando una víctima potencial utiliza un cliente vulnerable al establecer una conexión SSL/TLS con un servidor legítimo, el atacante redirige la conexión con el servidor malicioso. Antes de que la conexión SSL/TLS esté totalmente establecida y tenga la posibilidad de bloquear cualquier redirección, el atacante puede enviar un mensaje Heartbeat malintencionado que extraiga contenidos de la memoria de la computadora de la víctima. Esto puede incluir datos privados, como credenciales de autenticación.
Figura 2. Forma en que un atacante puede secuestrar y redireccionar un cliente vulnerable en una red abierta.
Además de las recomendaciones dadas anteriormente por Symantec, sugerimos lo siguiente:
• Evitar visitar dominios desconocidos con cualquier software de cliente, que acepten mensajes de Heartbeat y utilicen las bibliotecas de OpenSSL vulnerables.
• Dejar de usar los servicios de proxy que no han sido actualizados.
• Actualizar el software y hardware conforme los fabricantes tengan disponibles los parches.
• Utilizar un cliente VPN y un servicio confirmado como no vulnerable ante Heartbleed cuando estemos en redes públicas.
