HACKER MEDICINE

Heartbleed についての議論は、そのほとんどが脆弱な公開 Web サイトに集中していますが、このバグの影響はそれ以上の範囲に及んでいます。利用者の多いサイトのほとんどはすでに対応済みですが、だからといってエンドユーザーが警戒を緩めていいわけではありません。

Heartbleed の影響は、クライアントソフトウェアにも等しく及びます。いくつか例を挙げるだけでも、Web クライアントや電子メールクライアント、チャットクライアント、FTP クライアント、モバイルアプリ、VPN クライアント、そしてソフトウェアアップデータなどが該当します。要するに、脆弱なバージョンの OpenSSL を使って SSL/TLS 通信を行うクライアントであれば、どれも攻撃を受ける恐れがあるのです。

しかも、Heartbleed は Web サーバー以外のさまざまなサーバーにも影響します。プロキシ、メディアサーバー、ゲームサーバー、データベースサーバー、チャットサーバー、FTP サーバーなどです。それどころか、ハードウェアデバイスでさえ Heartbleed 脆弱性の影響は免れず、ルーター、PBX（ビジネス電話システム）、そしておそらくは IoT（モノのインターネット）に分類される無数のデバイスにも影響は及びます。

Heartbleed 脆弱性を悪用してこうしたソフトウェアやハードウェアサーバーに攻撃を仕掛ける手口は、脆弱な Web サイトに対する攻撃に似ています。ただし、クライアントに対する攻撃は実質上、逆の方向でも起きることもあります。

Heartbleed の悪用については、攻撃側のクライアントが脆弱なサーバーに悪質な Heartbleed メッセージを送り付けることで、サーバーが個人データを漏えいしてしまうと説明されています。しかし、その逆方向でも攻撃は成り立ちます。脆弱なクライアントがサーバーに接続し、サーバー自身が悪質な Heartbleed メッセージをクライアントに送信すれば、クライアントはそのメモリ上にある別のデータを伴って応答するため、資格情報や個人データが公開される可能性があるからです。

図 1. 脆弱なクライアントに対する攻撃方法は、基本的にサーバーに対する攻撃方法の逆

幸い、クライアントに脆弱性があるとしても、現実的にはそれを悪用することは難しいと考えられます。この攻撃の主な経路は、悪質な SSL/TLS サーバーにアクセスするようクライアントに指示するか、別の脆弱性を悪用して接続を乗っ取るかの 2 つですが、攻撃者にとって複雑さが増すという点では同じです。

クライアントから悪質なサーバーへの誘導
クライアントを悪用できる最も単純な例は、脆弱な Web ブラウザを介した攻撃です。被害者を欺いて悪質な URL にアクセスさせるだけで、攻撃側のサーバーはクライアント Web ブラウザのメモリにアクセスできるようになります。そうなると、以前のセッションの cookie、アクセスしたことのある Web サイト、フォームデータ、認証資格情報といったコンテンツもリスクにさらされることになります。

広く利用されているブラウザのほとんどは OpenSSL ではなく NSS（Network Security Services）のライブラリを使っています。NSS は Heartbleed に対して脆弱ではありませんが、Web クライアントも多くのコマンドラインでは OpenSSL を使っており（wget、curl など）、やはり脆弱です。

攻撃者にとってはユーザーを欺いて悪質なサイトにアクセスさせるという手間が掛かるので、いくぶんリスクは軽減されますが、その手間が掛からない場合もあります。たとえば、フランス語で書かれたページの URL を入力すると、そのコンテンツが英語に自動的に翻訳されるオンライン翻訳サービスを例に考えてみましょう。この翻訳サービスは、独自のバックエンドクライアントを使ってフランス語ページのコンテンツを取得します。このとき悪質なサーバーの URL を入力すればバックエンドクライアントを悪用して、この翻訳サービスからコードや資格情報といった重要な情報を盗み出せることになります。

接続の乗っ取り
前述のように、クライアントを悪質なサーバーに誘導するには、任意のサーバーにアクセスするようクライアントに指示する必要があります。確かに、多くのクライアントが接続するのは、ハードコード化された、あらかじめ定義されたドメインだけかもしれませんが、そうした場合でも、やはりクライアントの悪用は可能です。一部の公共 Wi-Fi ネットワークのような共有のオープンネットワークでは、他人がトラフィックを傍受して変更できる可能性があるため、攻撃者は脆弱なクライアントをリダイレクトできます。通常であれば、この問題のひとつの解決策となるのが SSL/TLS（たとえば、暗号化された Web ブラウジングである HTTPS）です。暗号化すれば、傍受もリダイレクトも防げるからです。ところが、SSL/TLS セッションが完全に確立する前であれば、悪質な Heartbeat メッセージを送信することが可能です。

攻撃者は、公共のネットワークに参加して、無防備なユーザーの通信を傍受することができます。無防備なユーザーが、正規のサーバーへの SSL/TLS 接続を確立する際に脆弱なクライアントを使っている場合、攻撃者はその接続を悪質なサーバーにリダイレクトします。SSL/TLS 接続が完全に確立される前で、リダイレクトを遮断するチャンスがある段階であれば、攻撃者は悪質な Heartbeat メッセージを送信して被害者のコンピュータのメモリから内容を抜き取ることができます。これには、認証資格情報などの個人データが含まれているかもしれません。

図 2. 共有のオープンネットワーク上で攻撃者が脆弱なクライアントを乗っ取ってリダイレクトする仕組み

以前のブログに示した注意事項に加えて、以下の推奨事項にも従うようにしてください。

• どのようなクライアントソフトウェアを使っている場合でも、不明なドメインにはアクセスしないでください。脆弱な OpenSSL ライブラリを使って Heartbeat メッセージを受信してしまうかもしれません。
• パッチが適用されていないプロキシサービスは使用しないようにしてください。
• ソフトウェアもハードウェアも、ベンダーからパッチが公開されたら速やかに更新してください。
• 公共のネットワークでは、Heartbleed に対して脆弱でないことが確認されている VPN クライアントやサービスを使用してください。

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。

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.