OpenSSL patches critical vulnerabilities two months after Heartbleed
Two of the flaws are critical, but are they as serious as Heartbleed?
Read more…
Two of the flaws are critical, but are they as serious as Heartbleed?
Read more…
A maior parte do foco com o Heartbleed tem sido referente a sites públicos, mas o bug afeta muito mais do que isso. Ainda que os sites mais populares não estejam vulneráveis, isso não significa que o usuário final possa baixar a guarda.
O Heartbleed também afeta softwares das organizações e corrompe sites, e-mail, chats, FTPs, aplicativos móveis, VPN e atualizadores de software. Em suma, qualquer cliente que se comunique através de SSL/TLS, usando uma versão vulnerável de OpenSSL, está sujeito a ataques.
Além disso, o Heartbleed afeta diversos outros aparelhos além de servidores de Web. Entre eles, proxies e servidores de mídia, games, banco de dados, chat e FTP. Por fim, equipamentos de hardware não estão imunes à vulnerabilidade. Ela pode afetar roteadores, PABXs (sistemas telefônicos corporativos) e, provavelmente, uma série de aparelhos que possuem Internet – IoT (Internet da Coisas, em português).
O ataque a estes servidores de software e hardware por meio da vulnerabilidade Heartbleed é feito de forma semelhante a um ataque a sites vulneráveis. No entanto, golpes a clientes podem acontecer essencialmente da forma reversa.
Normalmente, a exploração do Heartbleed vem sendo descrita como um cliente atacante que envia uma mensagem maliciosa para um servidor vulnerável e este equipamento expõe os dados privados. No entanto, o contrário também acontece. Uma empresa vulnerável pode se conectar a um servidor e ele pode enviar uma mensagem maliciosa de Heartbeat para o cliente – que cliente responderá com dados adicionais encontrados em sua memória, potencialmente expondo credenciais e demais dados privados.
Figura 1. Como um cliente vulnerável é atacado
Felizmente, enquanto os clientes estão vulneráveis, pode ser difícil explorá-los em cenários do mundo real. Os dois principais vetores de ataque são instruir o cliente a visitar um servidor SSL/TLS malicioso ou sequestrar a conexão a partir de fraquezas não relacionadas. Ambos apresentam uma complicação adicional para o atacante.
Direcionar o cliente a um servidor malicioso
Um exemplo simples de como um cliente pode ser explorado é por meio de um navegador Web vulnerável. É preciso simplesmente convencer a vítima a visitar uma URL maliciosa para permitir que o servidor atacante consiga acesso à memória do navegador Web do cliente. Isso coloca em risco conteúdos como cookies de sessões anteriores, sites visitados, dados de formulários e credenciais de autenticação.
Os navegadores mais populares não utilizam OpenSSL, mas as bibliotecas NSS (Network Security Services) são vulneráveis ao Heartbleed. No entanto, muitos clientes Web de linha de comando usam OpenSSL (por exemplo, wget e curl) e estão suscetíveis.
O fato de um atacante precisar enganar o usuário para que visite um site malicioso pode mitigar parte do risco, mas isso nem sempre é necessário. Imagine um serviço online de tradução de idiomas que você fornece uma URL para uma página em francês a um serviço automatizado e o serviço traduzirá o conteúdo para o inglês. Nos bastidores, o serviço está buscando o conteúdo na página em francês usando seu próprio cliente de backend. Se você fornecer a URL de um servidor malicioso, o cliente de backend será explorado e o atacante pode coletar informações sensíveis como códigos ou credenciais do serviço de tradução.
Sequestro de conexão
Direcionar clientes para um servidor malicioso conforme descrito acima exige a instrução das pessoas para que visitem servidores arbitrários. No entanto, muitos clientes podem contatar apenas um domínio pré-definido, hard-coded. Nestes casos, ainda assim a pessoa pode ser explorada. Em redes abertas compartilhadas como algumas redes públicas de Wi-Fi, o tráfego pode ser visível e alterado por outros, permitindo que os atacantes redirecionem clientes vulneráveis. Normalmente, SSL/TLS (por exemplo, HTTPS, navegação Web criptografada) é uma das soluções para este problema, já que a criptografia evita o eavesdropping (espionagem do tráfego da rede) e redirecionamento. Porém, é possível enviar mensagens maliciosas de Heartbeat antes da sessão SSL/TLS estar plenamente estabelecida.
Um atacante pode entrar em uma rede pública e espionar (eavesdrop) vítimas em potencial. Quando uma vítima em potencial utiliza um cliente vulnerável para estabelecer uma conexão SSL/TLS com um servidor legítimo, o atacante redireciona a conexão para o servidor malicioso. Antes que a conexão SSL/TLS esteja plenamente estabelecida e tenha chance de bloquear qualquer redirecionamento, o atacante pode enviar uma mensagem maliciosa de Heartbeat, extraindo os conteúdos da memória do computador da vítima. Isso pode incluir dados privados como credenciais de autenticação.
Figura 2. Como um atacante pode sequestrar e redirecionar um cliente vulnerável em uma rede aberta compartilhada
Além da orientação prévia, nós também recomendamos:
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. 共有のオープンネットワーク上で攻撃者が脆弱なクライアントを乗っ取ってリダイレクトする仕組み
以前のブログに示した注意事項に加えて、以下の推奨事項にも従うようにしてください。
* 日本語版セキュリティレスポンスブログの 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.
While most of the focus on Heartbleed has been on vulnerable public websites, the bug affects much more than this. While most popular sites are no longer vulnerable, this does not mean that end-users can drop their guard.
Heartbleed equally affects client software such as Web clients, email clients, chat clients, FTP clients, mobile applications, VPN clients and software updaters, to name a few. In short, any client that communicates over SSL/TLS using the vulnerable version of OpenSSL is open to attacks.
In addition, Heartbleed affects various other servers aside from Web servers. These include proxies, media servers, game servers, database servers, chat servers and FTP servers. Finally, hardware devices are not immune to the vulnerability. It can affect routers, PBXes (business phone systems) and likely numerous devices in the Internet of Things.
Attacking these software and hardware servers through the Heartbleed vulnerability is done in a similar manner as an attack to vulnerable websites. However, attacks on clients can happen in essentially the reverse manner.
Typically, exploitation of Heartbleed has been described as an attacking client sending a malicious Heartbeat message to a vulnerable server and the server exposing private data. However, the reverse is also true. A vulnerable client can connect to a server, and the server itself can send a malicious Heartbeat message to the client. The client will then respond with extra data found in its memory, potentially exposing credentials and other private data.
Figure 1. How a vulnerable client is attacked is essentially the reverse of an attack on a server
Fortunately, while clients are vulnerable, it may be difficult to exploit them in real-world scenarios. The two main vectors of attack are instructing the client to visit a malicious SSL/TLS server or hijacking a connection through an unrelated weakness. Both present an added complication for the attacker.
Directing the client to a malicious server
The simplest example of how a client may be exploited is through something like a vulnerable Web browser. One simply has to convince a victim to visit a malicious URL in order to allow the attacking server to gain access to the client Web browser memory. This puts at risk content such as previous session cookies, websites visited, form data and authentication credentials.
Most popular Web browsers do not use OpenSSL, but the NSS (Network Security Services) libraries, which are not vulnerable to Heartbleed. However, many command line Web clients do use OpenSSL (e.g., wget and curl) and are vulnerable.
The attacker’s need to trick a user into visiting a malicious site may mitigate some risk, but it is not always necessary. Imagine an online language translation service where you provide an automated service with a URL to a page in the French language and the service will translate the content to English. Behind the scenes, the service is fetching the content of the French page using their own backend client. If you provide the URL of a malicious server, the backend client can be exploited and the attacker may retrieve sensitive information such as code or credentials from the translation service.
Hijacking a connection
Directing clients to a malicious server as described above requires clients that can be instructed to visit arbitrary servers. However, many clients may only contact a preset, hardcoded domain. In these cases, the client may still be exploited. On shared open networks such as some public WiFi networks, traffic can be visible and altered by others, allowing attackers to redirect vulnerable clients. Normally, SSL/TLS (e.g. HTTPS, encrypted Web browsing) is one of the solutions to this problem, since the encryption prevents eavesdropping and redirection. However, one can send malicious Heartbeat messages prior to the SSL/TLS session being fully established.
An attacker can join a public network and eavesdrop on potential victims. When a potential victim uses a vulnerable client to establish an SSL/TLS connection with a legitimate server, the attacker redirects the connection to the malicious server. Before the SSL/TLS connection is fully established and has a chance to block any redirection, the attacker can send a malicious Heartbeat message extracting contents from the memory of the victim’s computer. This can include private data such as authentication credentials.
Figure 2. How an attacker can hijack and redirect a vulnerable client on a shared, open network
In addition to previous guidance, we also recommend the following:
Heartbleed와 관련하여 취약한 공개 웹 사이트에 초점이 맞춰지고 있지만 실제로 이 취약점은 훨씬 더 광범위하게 영향을 미치고 있습니다. 대부분의 유명 사이트는 더 이상 취약하지 않습니다. 그렇다고 해서 엔드유저가 마음 놓아도 될 상황은 아닙니다.
Heartbleed는 웹 클라이언트, 이메일 클라이언트, 채팅 클라이언트, FTP 클라이언트, 모바일 애플리케이션, VPN 클라이언트, 소프트웨어 업데이트 프로그램 등 각종 클라이언트 소프트웨어에도 영향을 미칩니다. 즉 SSL/TLS를 통해 통신하고 취약한 버전의 OpenSSL을 사용하는 클라이언트라면 이 공격을 당할 가능성이 높습니다.
뿐만 아니라 Heartbleed는 웹 서버 외에도 프록시, 미디어 서버, 게임 서버, 데이터베이스 서버, 채팅 서버, FTP 서버 등 다양한 서버에 영향을 미칩니다. 하드웨어 장치 역시 안전하지 않습니다. 라우터, PBX(업무용 전화 시스템), 사물 인터넷을 구성하는 무수히 많은 장치도 영향을 받을 수 있습니다.
Heartbleed 취약점을 통해 이러한 소프트웨어 및 하드웨어 서버를 공격하는 방식은 취약한 웹 사이트에 대한 공격과 유사합니다. 하지만 클라이언트에 대한 공격은 정반대의 양상을 띨 수도 있습니다.
일반적으로 알려진 Heartbleed 익스플로잇은 공격자 측 클라이언트가 취약한 서버로 악성 하트비트 메시지를 보내고 해당 서버에서 개인 데이터가 유출되는 방식입니다. 하지만 그 반대의 상황도 가능합니다. 즉 취약한 클라이언트가 서버에 접속하면 이 서버에서 클라이언트에게 악성 하트비트 메시지를 보내는 것입니다. 그러면 클라이언트는 메모리에 남아 있는 추가 데이터를 사용하여 응답하는데, 이때 인증 정보와 기타 개인 데이터가 유출될 우려가 있습니다.
그림 1. 서버에 대한 공격과 정반대로 이루어지는 취약한 클라이언트에 대한 공격
다행히 클라이언트가 취약하더라도 현실적으로 그에 대한 익스플로잇 공격에는 어려움이 따를 수 있습니다. 대표적인 두 공격 벡터는 클라이언트에게 악성 SSL/TLS 서버를 방문하도록 지시하거나 다른 무관한 약점을 통해 연결을 하이재킹하는 것인데, 둘 다 공격자 입장에서는 매우 복잡한 방식입니다.
클라이언트를 악성 서버에 연결
클라이언트의 취약점을 공격하는 가장 단순한 예로 취약한 웹 브라우저 등을 이용하는 방법이 있습니다. 이 경우 피해자가 악성 URL을 방문하도록 유도하면 되는데, 그러면 공격자 측 서버가 클라이언트 웹 브라우저 메모리에 접근합니다. 이때 이전의 세션 쿠키, 방문한 웹 사이트, 폼 데이터, 인증 정보 등의 컨텐트가 유출될 위험이 있습니다.
많이 사용되는 웹 브라우저의 대부분은 OpenSSL이 아니라 Heartbleed에 취약하지 않은 NSS(Network Security Services) 라이브러리를 사용합니다. 하지만 명령줄 웹 클라이언트 중 상당수(예: wget, curl)는 OpenSSL을 사용하기 때문에 취약합니다.
공격자가 사용자를 악성 사이트로 유인해야 한다는 점 때문에 위험성이 다소 줄어들 수는 있지만 안심할 수 있는 것만은 아닙니다. 프랑스어 페이지 URL을 입력하면 그 내용을 영어로 자동 번역해 주는 온라인 번역 서비스가 있다고 가정해 보십시오. 하지만 실제로 이 서비스는 은밀하게 자체 백엔드 클라이언트를 사용하여 프랑스어 페이지의 내용을 가져옵니다. 따라서 만약 사용자가 악성 서버 URL을 입력할 경우 백엔드 클라이언트가 익스플로잇의 대상이 되고 공격자는 번역 서비스를 통해 코드, 인증 정보와 같은 중요 정보를 획득하게 됩니다.
연결 하이재킹
위에 설명한 것처럼 클라이언트를 악성 서버로 연결하려면 해당 서버를 방문하라는 지시를 내릴 대상 클라이언트가 있어야 합니다. 하지만 대다수의 클라이언트는 미리 설정되고 하드코딩된 도메인에만 접속합니다. 이러한 경우에도 클라이언트에 대한 익스플로잇이 가능합니다. 일부 WiFi 네트워크와 같이 공개된 공유 네트워크에서는 다른 사람이 트래픽을 보고 변경할 수 있으므로 공격자가 취약한 클라이언트를 리디렉션하는 것이 가능합니다. 일반적으로 암호화를 통해 염탐이나 리디렉션을 차단할 수 있으므로 SSL/TLS(예: HTTPS, 암호화된 웹 브라우징)는 이러한 문제의 해결책 중 하나입니다. 하지만 이러한 SSL/TLS 세션이 완전히 설정되기 전에 악성 하트비트 메시지를 보낼 수 있습니다.
공격자는 공용 네트워크에 접속하여 잠재적인 피해자를 몰래 지켜볼 수 있습니다. 잠재적 피해자가 취약한 클라이언트를 사용하여 합법적인 서버와의 SSL/TLS 연결을 설정할 경우 공격자는 해당 연결을 악성 서버로 리디렉션합니다. SSL/TLS 연결이 완전히 설정되어 리디렉션을 차단하기 전까지 공격자는 악성 하트비트 메시지를 보내 피해자 시스템의 메모리에서 컨텐트를 유출시킵니다. 여기에는 인증 정보와 같은 개인 데이터가 포함될 수도 있습니다.
그림 2. 공격자가 공개된 공유 네트워크에서 하이재킹하여 취약한 클라이언트를 리디렉션하는 방법
앞서 전달한 지침과 함께 아래의 권장 사항도 따르는 것이 좋습니다.
Ransomcrypt の作成者は、良心のかけらもないことで知られています。これまでも常に、被害者は脅迫的な要求に支払いで応じ、ファイルを復号してもらうしか選択の余地がありませんでした。しかし、今回出現した Trojan.Ransomcrypt.G では様子が少し違うようです。Trojan.Ransomcrypt.G の作成者が詐欺師であることに違いはありませんが、何らかの行動原理に従っているらしく、身代金を支払わなくても 1 カ月が経過すれば、被害者のファイルを無償で復号すると申し出てきます。このような行動で作成者が無罪放免されるわけではないものの、残念ながらこの詐欺の被害に遭ったユーザーにとっては、一縷の望みと言えるでしょう。
図 1. Trojan.Ransomcrypt.G によって生成されるランサムウェアファイル「how to get data.txt」の一部
Trojan.Ransomcrypt.G の最初の例は、被害を受けたユーザーから、あるオンラインフォーラムに報告されました。侵入先のシステムでデータファイルを暗号化する、典型的な Ransomcrypt Trojan です。暗号化するファイルの拡張子は、Trojan.Ransomcrypt.G のバイナリファイルに格納されている長大なリストに照合してチェックされます。一般的な種類のデータファイルはほとんど影響を受けますが、完全なリストはこちらを参照してください。暗号化されたファイルには、.OMG! というファイル拡張子が追加されます。たとえば、hello.doc というファイルが Trojan.Ransomcrypt.G によって暗号化されると、hello.doc.OMG! という名前に変わります。
侵入を受けると、暗号化されたファイルと同じディレクトリに「how to get data.txt」というテキストファイルが生成されます。
図 2. 暗号化されたファイルを含むディレクトリ
このファイルを開くと、暗号化されたファイルとこのテキストファイルを添付して電子メールを攻撃者に送信するようにという指示が書かれています。攻撃者からは、復号された一部のファイルが添付されたメールが返信されてきます。そのメールに、すべてのデータファイルを復号できるロック解除ツールの入手方法が記載されています。
この「how to get data.txt」ファイルの末尾には、通常とは異なる文字列が含まれています。
図 3. ランサムウェアのファイルに含まれるバイナリ文字列
この文字列が実は、暗号化された暗号鍵と、感染のタイムスタンプ情報のバイナリダンプです。ロック用のこの鍵が、感染したシステムでファイルの暗号化と復号に使われます。鍵は、Windows 標準の暗号化機能を使って、感染したシステム上で動的に生成されます。その鍵を平文で送信するのではなく、Trojan.Ransomcrypt.G のバイナリデータの設定データに含まれる公開暗号鍵(RSA)を使って、ロック用の鍵を暗号化します。攻撃者は対応する秘密鍵を知っているので、それを使ってテキストファイルのバイナリ文字列の解読、ロック用鍵の回復、送られてきた暗号化ファイルの復号を行うことができます。また攻撃者は、暗号化された文字列から感染のタイムスタンプを取り出し、被害者が無償のロック解除ツールを使える期間になったかどうかも判定できます。
Ransomcrypt Trojan では、攻撃者が制御しているサーバーと被害者のシステムとの間のネットワーク通信によって、この種の鍵交換が自動化されているのが普通です。Trojan.Ransomcrypt.G はより単純なアプローチを使っているため、同じ処理を実行する際にユーザーとのやり取りが必要になるのです。
ファイルを復号するために、けっして身代金を支払ってはいけません。シマンテックの最新技術と、コンシューマ向けのノートン製品やエンタープライズ向けのソリューションをお使いいただくことで、こういったランサムウェアの攻撃から保護することができます。ファイルは常にバックアップするようにしてください。そうすれば、必要に応じてファイルを復元することが可能です。
シマンテック製品をお使いのお客様は、以下の検出定義によって今回のトロイの木馬から保護されています。
* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。
Ransomcrypt authors are not known to have a conscience, and until now have always left their victims with no way out, other than paying the extortion demand to decrypt their files. This seems to have changed somewhat with the arrival of Trojan.Ransomcrypt.G. While the authors of this malware are still total scammers, they seem to have some principles and offer to decrypt the victim’s files for free after a one month period, even if the ransom has not been paid. While this behavior does not exonerate the actions of the malware authors, it does leave some light at the end of the tunnel for any unfortunate victims of this scam.
Figure 1. “how to get data.txt” snippet from ransom file left behind by Trojan.Ransomcrypt.G
Trojan.Ransomcrypt.G was first reported by affected users in an online forum. It is a typical ransomcrypt Trojan that encrypts data files on the infected system. File extensions are checked against a long list stored in the Trojan binary file. Most common data file types are affected and you can see the full list here. Encrypted files are given an extra file extension, .OMG!, by the Trojan. For example, if the Trojan encrypted the file hello.doc, it would rename it hello.doc.OMG!.
Compromised users may notice a text file called “how to get data.txt” in directories containing encrypted files.
Figure 2. Directory containing compromised files
This file informs the user that they must send an email to the attacker and attach the text file along with some encrypted files. The attacker will reply with the decrypted files and instructions on how to obtain the unlocker tool that they can use to decrypt all of their data files.
Users may also notice an unusual string of characters at the end of the “how to get data.txt” file.
Figure 3. Binary string from ransom file
This string is actually a binary dump of an encrypted cryptographic key and infection timestamp information. This locking key is used to encrypt and decrypt files on the infected system. It is dynamically generated on the infected system using standard cryptographic Windows functions. Rather than sending this key in plaintext, the Trojan encrypts the locking key with a public cryptographic key (RSA) that is included in the configuration data in the Trojan binary data. The attacker knows the corresponding private key and so they can use it to decrypt the binary string in the text file, recover the locking key, and decrypt the encrypted files sent to them by the victim. The attacker can also recover the infection timestamp from the decrypted string and determine if the victim is eligible for the free unlocker tool.
Most ransomcrypt Trojans automate this type of key exchange with network communications between the victim’s system and a server controlled by the attacker. Trojan.Ransomcrypt.G uses a more basic approach that requires user interaction to perform the same operation.
Users should never pay any ransom to have their files decrypted. The latest Symantec technologies and Norton consumer and Symantec enterprise solutions protect against these kinds of attacks. You should always backup your files, that way you can restore them if necessary.
Symantec customers are protected from this Trojan with the following detections:
Question of the week: I have read frightening stories about CryptoLocker locking computers. I don’t have $200 to pay blackmailers for my own files. How do I protect myself from getting attacked? Does avast! protect from CryptoLocker? “Avast! Antivirus detects all known variants of CryptoLocker thanks to our automated processing and CommunityIQ,” said Pavel […]
Encryption is the science of encoding and decoding secret messages. It began as cryptography—the ancient Greeks used it to protect sensitive information that might fall into the hands of their enemies. More recently, governments have used encryption for military purposes, but these days the term if often used in reference to online security. Encryption is Read more…