HACKER MEDICINE

ZeroAccess は、これまでも常に P2P プロトコルを使って侵入先のコンピュータに悪質なペイロードを拡散してきました。P2P プロトコルを使うと、悪質なペイロードを配布する際に中央のコマンド & コントロール（C&C）サーバーを管理する必要がなくなるからです。2011 年には、ZeroAccess の P2P プロトコルは TCP 上で通信されていましたが、2012 年の第 2 四半期に、UDP を使うように変更されました。2013 年 6 月 29 日を迎えるまで、ZeroAccess の P2P に対する大きい更新はこれが最終でした。

シマンテックは、発見以来 ZeroAccess の P2P ネットワークを厳重に監視し続けています。2013 年 6 月 29 日、シマンテックは ZeroAccess ピアで新しいモジュールが拡散していることを確認しました。このときの通信にはポート 16464 と 16465 で動作する UDP ベースの P2P ネットワークが使われていましたが、ZeroAccess はポート 16470 と 16471 で動作する UDP ベースネットワークも確保しています。ZeroAccess のピアは同じネットワークに接続された他のピアと通信するので、ピアどうしがネットワーク上で通信することはありません。

6 月 29 日に発見されたモジュールは、ZeroAccess の P2P 機能を更新し、P2P ネットワークの堅牢性を高くして外部からの操作に対する耐性を強化するものです。2013 年 6 月 29 日に実施され、ZeroAccess の P2P 機能に影響する主なコード変更を以下にまとめます。

• サポートされる P2P プロトコルメッセージの数が、3 つから 2 つに減った。
• セカンダリの内部ピアリストが使われるようになり、リストに含めることができるピアの IP アドレスが 256 個から 1,600 万個に増えた。
• セカンダリの内部ピアリストは、Windows NTFS の代替データストリームとして格納されている。
• ZeroAccess のピアが他のピアと通信する方法のロジックが変更された。
• 悪質なファイルをダウンロードする TCP 接続に、エラーチェックとタイムアウトが追加された。

既存のピアについては UDP 16464/16465 のピアネットワーク上でコードの更新を利用できるほか、2013 年 6 月 29 日以降は、UDP 16464/16465 を対象としてコンピュータを ZeroAccess に感染させる ZeroAccess インストーラにも、新しい P2P プロトコルとコード変更が含まれていることが確認されています。

興味深いことに、ZeroAccess の UDP 16470/16471 ネットワークにはまだコード更新が適用されていません。UDP 16470/16471 を対象とする新しい ZeroAccess インストーラのサンプルにも、新しいコードは含まれていません。これまでは、UDP 16464/16465 と UDP 16470/16471 のネットワークはほぼ同じ時期に新機能とコード変更を適用されるのが通例でした。

ZeroAccess の作成者が今回の更新で実施したコード変更は、ZeroAccess に関して公開された研究に対応したため、または作成者がコード中に明らかな弱点を発見したためと考えられます。今回の変更は、ZeroAccess が今もなお鋭意開発中であり、依然として脅威であることの証拠とも言えます。シマンテックは、ZeroAccess の開発が今後も続くものと予測し、この脅威に変化が起きないかどうか全力で監視を続ける予定です。

次節では、P2P プロトコルについて技術的に詳しく説明し、ZeroAccess で実施された関連のコード変更についてもまとめます。
 

変更された P2P プロトコル

2012 年に発見されたとき、ZeroAccess の UDP ベース P2P プロトコルは getL、retL、newL の 3 つのメッセージタイプをサポートしていました。このメッセージについては多くのセキュリティ研究で説明されており、プロトコルの欠陥、特に newL メッセージタイプに関する欠陥も指摘されています。newL タイプのメッセージは、ZeroAccess がピア間で直接ルーティング可能な IP アドレス（スーパーノードまたはスーパーピアとも言う）を共有するために使われます。newL メッセージを受け取ったピアは、newL メッセージタイプに含まれている IP アドレスを内部のピアリストに追加します。ピアは newL メッセージを既知の他のピアにも転送し、メッセージの効果が増強されます。6 月 29 日より前には、newL メッセージを作成して ZeroAccess のピアに送信すると、感染した ZeroAccess ピアの内部ピアリストに悪質な IP アドレスを追加することができ、その悪質な newL メッセージを ZeroAccess ピアに拡散させることができました。

新しい P2P プロトコルではこの newL メッセージタイプが削除され、ボットネットが悪質なピアの IP を除外できるようになっています。
 

内部ピアリストの拡張

ZeroAccess の P2P プロトコルについて以前から指摘されていたもうひとつの欠点は、内部のピアリストが固定サイズだったことです。6 月 29 日の更新より前、ZeroAccess の内部ピアリストは上限が 256 ピアでした。同日以降はセカンダリのピアリストが追加されてメモリも確保され、1,600 万ピアの IP アドレスを保持できるようになっています。256 ピアのリストは引き続き、ピアの「ワーキングセット」として存続し、定期的にアクセスされています。セカンダリのピアリストは、冗長性の目的で使われているのです。

ピアリストの上限が 256 ピアだったときには、ZeroAccess を十分にクリーンアップすれば、ZeroAccess ピアを P2P ネットワークから切断することが現実に可能でした。256 個の既知のピアはいずれも、オンラインではなかったからです。また、ZeroAccess ピアの 256 個の内部ピアリストを悪質な IP アドレスに置き換えることも、理屈のうえでは可能でした。セカンダリのピアリストの追加で、このどちらも難しくなっています。

セカンダリのピアリストは、256 ピアのワーキングセットとともにディスクに書き込まれます。6 月 29 日より前には、内部ピアリストに記載された 256 個のピアは「@」という名前のファイルに保存されていました。同日以降も @ ファイルは存在し、ワーキングセットに含まれる 256 ピアの IP アドレスが記載されています。セカンダリのピアリストは、最大で 1,600 万個の IP アドレスを含み、@ ファイルの NTFS 代替データストリームとして保存されます。この NTFS 代替データストリームも、@ というファイル名を使っています。
 

実行時のピアの接続動作を変更

6 月 29 日より前には、ZeroAccess の内部ピアリストにある 256 ピアのうち 1 つに毎秒 getL を使って接続し、新しい悪質なモジュール上のデータと、新しい ZeroAccess ピアの IP アドレスを確認していました。この動作は同日以降にも続いていますが、いずれかのリモートピアがメッセージに応答する場合、応答しているそのピアの IP アドレスと応答時のタイムスタンプがセカンダリのピアリストに追加されます。

セカンダリの接続先リストにある IP には、ZeroAccess の最初の起動時にも接続されます。起動時には、セカンダリのピアリストから 1 秒ごとに 16 個もの IP アドレスが接続されます。このセカンダリのピアリスト通信は、感染したホストに少なくとも 16 個のリモートピアが応答するまで続きます。感染したピアに 16 個のリモートピアが接続を完了すると、セカンダリのリストにあるピアは、感染したコンピュータが再起動されるまで接続しなくなります。ワーキングセットの 256 ピアによる通常の定期的な接続の一環としてリモートピアが応答すると、セカンダリのピアリストは追加を続行され、更新されます。この動作によって、ZeroAccess クライアントはすでに接続したことのあるピアの膨大なリストを冗長性のために保持し続けますが、ZeroAccess ネットワークを通じて悪質なペイロードを急速に拡散するために、256 ピアの小さいワーキングセットも引き続き使われています。

実行時のピア接続動作についてもうひとつの変更は、接続先ピアの状態テーブルが記録されることです。ZeroAccess のピアは引き続き大量の getL メッセージをリモートピアに送信しており、応答として retL メッセージを受信するものと想定します。retL 応答には、悪質なペイロードのメタデータと、新しいピアの IP アドレスが含まれています。6 月 29 日より前には、感染したピアは任意の IP アドレスから任意の UDP メッセージを受信していました。これは、感染したホストがそのリモート IP アドレスに以前に接続したことがあるかどうかを問いませんでした。6 月 29 日以降も、ZeroAccess のピアは任意のリモート IP から getL メッセージを受信しますが、retL メッセージについては、受信側のピアが以前に getL メッセージを送信したことがある IP アドレスからのみ受信します。基本的に、ZeroAccess ピアが getL メッセージをリモート IP アドレスに送信すると、そのリモート IP アドレスはメモリ内のテーブルに追加されます。ZeroAccess ピアが retL メッセージを受け取ると、以前に getL メッセージを送ったことがある送信先の IP アドレスのテーブルがスキャンされ、retL メッセージを送信したピアの IP アドレスがそのテーブルに存在しなければ、retL メッセージを受け取った ZeroAccess ピアはそれを無視します。この変更によって、大量送信される retL メッセージは無視されるので、悪質な IP アドレスを送信する手段として（以前のプロトコルで newL メッセージが使われていたのと同じように）retL メッセージを使うことは、ますます難しくなっているのです。
 

ペイロードファイル転送の耐性が向上

ZeroAccess のピアには、リモートホストから悪質なペイロードをダウンロードしないよう確認するチェックが含まれています。ペイロードファイルのメタデータは retL メッセージに含まれ、デジタル署名されているので容易には偽造されません。また、悪質なペイロードファイル自体もデジタル署名されており、ファイルのダウンロード後に署名がチェックされます。デジタル署名は、悪質なピアが実行可能な任意のモジュールを P2P ネットワークに引き込んでしまわないように防いでいます。6 月 29 日のコード変更で、TCP ファイル転送の完了までに時間がかかりすぎないよう確認するチェックも追加されました。この変更は、一種のサービス拒否攻撃を防ぐことを目的としていると考えられます。つまり、悪質なピアが ZeroAccess のピアを欺き、悪質なピアから大量のファイルをダウンロードするよう仕向けて、結果的にファイルの配信速度を遅らせるという攻撃です。この攻撃を使えば、感染したコンピュータ上ですべての TCP ポートを占有し、意図された悪質なペイロードをダウンロードできなくさせることが可能です。

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

ZeroAccess は、これまでも常に P2P プロトコルを使って侵入先のコンピュータに悪質なペイロードを拡散してきました。P2P プロトコルを使うと、悪質なペイロードを配布する際に中央のコマンド & コントロール（C&C）サーバーを管理する必要がなくなるからです。2011 年には、ZeroAccess の P2P プロトコルは TCP 上で通信されていましたが、2012 年の第 2 四半期に、UDP を使うように変更されました。2013 年 6 月 29 日を迎えるまで、ZeroAccess の P2P に対する大きい更新はこれが最終でした。

シマンテックは、発見以来 ZeroAccess の P2P ネットワークを厳重に監視し続けています。2013 年 6 月 29 日、シマンテックは ZeroAccess ピアで新しいモジュールが拡散していることを確認しました。このときの通信にはポート 16464 と 16465 で動作する UDP ベースの P2P ネットワークが使われていましたが、ZeroAccess はポート 16470 と 16471 で動作する UDP ベースネットワークも確保しています。ZeroAccess のピアは同じネットワークに接続された他のピアと通信するので、ピアどうしがネットワーク上で通信することはありません。

6 月 29 日に発見されたモジュールは、ZeroAccess の P2P 機能を更新し、P2P ネットワークの堅牢性を高くして外部からの操作に対する耐性を強化するものです。2013 年 6 月 29 日に実施され、ZeroAccess の P2P 機能に影響する主なコード変更を以下にまとめます。

• サポートされる P2P プロトコルメッセージの数が、3 つから 2 つに減った。
• セカンダリの内部ピアリストが使われるようになり、リストに含めることができるピアの IP アドレスが 256 個から 1,600 万個に増えた。
• セカンダリの内部ピアリストは、Windows NTFS の代替データストリームとして格納されている。
• ZeroAccess のピアが他のピアと通信する方法のロジックが変更された。
• 悪質なファイルをダウンロードする TCP 接続に、エラーチェックとタイムアウトが追加された。

既存のピアについては UDP 16464/16465 のピアネットワーク上でコードの更新を利用できるほか、2013 年 6 月 29 日以降は、UDP 16464/16465 を対象としてコンピュータを ZeroAccess に感染させる ZeroAccess インストーラにも、新しい P2P プロトコルとコード変更が含まれていることが確認されています。

興味深いことに、ZeroAccess の UDP 16470/16471 ネットワークにはまだコード更新が適用されていません。UDP 16470/16471 を対象とする新しい ZeroAccess インストーラのサンプルにも、新しいコードは含まれていません。これまでは、UDP 16464/16465 と UDP 16470/16471 のネットワークはほぼ同じ時期に新機能とコード変更を適用されるのが通例でした。

ZeroAccess の作成者が今回の更新で実施したコード変更は、ZeroAccess に関して公開された研究に対応したため、または作成者がコード中に明らかな弱点を発見したためと考えられます。今回の変更は、ZeroAccess が今もなお鋭意開発中であり、依然として脅威であることの証拠とも言えます。シマンテックは、ZeroAccess の開発が今後も続くものと予測し、この脅威に変化が起きないかどうか全力で監視を続ける予定です。

次節では、P2P プロトコルについて技術的に詳しく説明し、ZeroAccess で実施された関連のコード変更についてもまとめます。
 

変更された P2P プロトコル

2012 年に発見されたとき、ZeroAccess の UDP ベース P2P プロトコルは getL、retL、newL の 3 つのメッセージタイプをサポートしていました。このメッセージについては多くのセキュリティ研究で説明されており、プロトコルの欠陥、特に newL メッセージタイプに関する欠陥も指摘されています。newL タイプのメッセージは、ZeroAccess がピア間で直接ルーティング可能な IP アドレス（スーパーノードまたはスーパーピアとも言う）を共有するために使われます。newL メッセージを受け取ったピアは、newL メッセージタイプに含まれている IP アドレスを内部のピアリストに追加します。ピアは newL メッセージを既知の他のピアにも転送し、メッセージの効果が増強されます。6 月 29 日より前には、newL メッセージを作成して ZeroAccess のピアに送信すると、感染した ZeroAccess ピアの内部ピアリストに悪質な IP アドレスを追加することができ、その悪質な newL メッセージを ZeroAccess ピアに拡散させることができました。

新しい P2P プロトコルではこの newL メッセージタイプが削除され、ボットネットが悪質なピアの IP を除外できるようになっています。
 

内部ピアリストの拡張

ZeroAccess の P2P プロトコルについて以前から指摘されていたもうひとつの欠点は、内部のピアリストが固定サイズだったことです。6 月 29 日の更新より前、ZeroAccess の内部ピアリストは上限が 256 ピアでした。同日以降はセカンダリのピアリストが追加されてメモリも確保され、1,600 万ピアの IP アドレスを保持できるようになっています。256 ピアのリストは引き続き、ピアの「ワーキングセット」として存続し、定期的にアクセスされています。セカンダリのピアリストは、冗長性の目的で使われているのです。

ピアリストの上限が 256 ピアだったときには、ZeroAccess を十分にクリーンアップすれば、ZeroAccess ピアを P2P ネットワークから切断することが現実に可能でした。256 個の既知のピアはいずれも、オンラインではなかったからです。また、ZeroAccess ピアの 256 個の内部ピアリストを悪質な IP アドレスに置き換えることも、理屈のうえでは可能でした。セカンダリのピアリストの追加で、このどちらも難しくなっています。

セカンダリのピアリストは、256 ピアのワーキングセットとともにディスクに書き込まれます。6 月 29 日より前には、内部ピアリストに記載された 256 個のピアは「@」という名前のファイルに保存されていました。同日以降も @ ファイルは存在し、ワーキングセットに含まれる 256 ピアの IP アドレスが記載されています。セカンダリのピアリストは、最大で 1,600 万個の IP アドレスを含み、@ ファイルの NTFS 代替データストリームとして保存されます。この NTFS 代替データストリームも、@ というファイル名を使っています。
 

実行時のピアの接続動作を変更

6 月 29 日より前には、ZeroAccess の内部ピアリストにある 256 ピアのうち 1 つに毎秒 getL を使って接続し、新しい悪質なモジュール上のデータと、新しい ZeroAccess ピアの IP アドレスを確認していました。この動作は同日以降にも続いていますが、いずれかのリモートピアがメッセージに応答する場合、応答しているそのピアの IP アドレスと応答時のタイムスタンプがセカンダリのピアリストに追加されます。

セカンダリの接続先リストにある IP には、ZeroAccess の最初の起動時にも接続されます。起動時には、セカンダリのピアリストから 1 秒ごとに 16 個もの IP アドレスが接続されます。このセカンダリのピアリスト通信は、感染したホストに少なくとも 16 個のリモートピアが応答するまで続きます。感染したピアに 16 個のリモートピアが接続を完了すると、セカンダリのリストにあるピアは、感染したコンピュータが再起動されるまで接続しなくなります。ワーキングセットの 256 ピアによる通常の定期的な接続の一環としてリモートピアが応答すると、セカンダリのピアリストは追加を続行され、更新されます。この動作によって、ZeroAccess クライアントはすでに接続したことのあるピアの膨大なリストを冗長性のために保持し続けますが、ZeroAccess ネットワークを通じて悪質なペイロードを急速に拡散するために、256 ピアの小さいワーキングセットも引き続き使われています。

実行時のピア接続動作についてもうひとつの変更は、接続先ピアの状態テーブルが記録されることです。ZeroAccess のピアは引き続き大量の getL メッセージをリモートピアに送信しており、応答として retL メッセージを受信するものと想定します。retL 応答には、悪質なペイロードのメタデータと、新しいピアの IP アドレスが含まれています。6 月 29 日より前には、感染したピアは任意の IP アドレスから任意の UDP メッセージを受信していました。これは、感染したホストがそのリモート IP アドレスに以前に接続したことがあるかどうかを問いませんでした。6 月 29 日以降も、ZeroAccess のピアは任意のリモート IP から getL メッセージを受信しますが、retL メッセージについては、受信側のピアが以前に getL メッセージを送信したことがある IP アドレスからのみ受信します。基本的に、ZeroAccess ピアが getL メッセージをリモート IP アドレスに送信すると、そのリモート IP アドレスはメモリ内のテーブルに追加されます。ZeroAccess ピアが retL メッセージを受け取ると、以前に getL メッセージを送ったことがある送信先の IP アドレスのテーブルがスキャンされ、retL メッセージを送信したピアの IP アドレスがそのテーブルに存在しなければ、retL メッセージを受け取った ZeroAccess ピアはそれを無視します。この変更によって、大量送信される retL メッセージは無視されるので、悪質な IP アドレスを送信する手段として（以前のプロトコルで newL メッセージが使われていたのと同じように）retL メッセージを使うことは、ますます難しくなっているのです。
 

ペイロードファイル転送の耐性が向上

ZeroAccess のピアには、リモートホストから悪質なペイロードをダウンロードしないよう確認するチェックが含まれています。ペイロードファイルのメタデータは retL メッセージに含まれ、デジタル署名されているので容易には偽造されません。また、悪質なペイロードファイル自体もデジタル署名されており、ファイルのダウンロード後に署名がチェックされます。デジタル署名は、悪質なピアが実行可能な任意のモジュールを P2P ネットワークに引き込んでしまわないように防いでいます。6 月 29 日のコード変更で、TCP ファイル転送の完了までに時間がかかりすぎないよう確認するチェックも追加されました。この変更は、一種のサービス拒否攻撃を防ぐことを目的としていると考えられます。つまり、悪質なピアが ZeroAccess のピアを欺き、悪質なピアから大量のファイルをダウンロードするよう仕向けて、結果的にファイルの配信速度を遅らせるという攻撃です。この攻撃を使えば、感染したコンピュータ上ですべての TCP ポートを占有し、意図された悪質なペイロードをダウンロードできなくさせることが可能です。

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