reasoning.org presents

hash's Security Alert

hash's Security Note

reasoning.org presents
CERT文書
和訳版

最近版

全CERT勧告

Tech Tips

CERT/CC presents

Advisories

Tech Tips

Incident Notes

Summaries

Code Red II についての警告

hash's Security Alert 2001-02

2001年8月9日05時30分
本文書は2001年8月7日12時45分に全面改訂版を リリースしたが、8月9日現在、マイクロソフトをはじめとする諸機関 から公式の対策文書がリリースされている。Code Red IIの技術的解説と しては本文書はまだ価値を持つと考えるが、対策手順等については以下に 示す各文書を参照されたい。少なくとも対策手順の提示という意味では 本文書の価値は8月9日以降ほぼなくなったと筆者は判断する。なお、 筆者が8月9日に改めて行なった感染実験ではこれまで報告されている ものと若干異なった症状を表すケースが存在した。これが亜種の登場を 意味するかどうかは未確定だが、その可能性にも今後注意されたい。

8月8日現在、マイクロソフトより次の詳細な修正/復旧手順マニュアルが 刊行されている。
Code Red による深刻な問題に対する防護策と対処方法についての説明
この文書は必ず参照することを強く推奨する。

また、シマンテックならびにトレンドマイクロから感染検出ツール並びに 復旧ツールが公開されているので、これについても参照することを強く 推奨する。

またJPCERTから次の文書がリリースされている。
緊急報告 - Microsoft IIS の脆弱性を使って伝播するワーム "Code Red II"

更新履歴
2001年8月6日02時45分 初版公開
2001年8月7日08時30分 全面改訂版の未完成版を暫定的に公開
2001年8月7日12時45分 全面改訂版の初版を公開。(その後の更新履歴は略)
2001年8月9日05時30分 マイクロソフト等から公式の対策手順マニュアルが リリースされたことを受け、大幅に改訂。

要旨

Code Red IIと自称するワームが日本時間の8月4日午後から急速に広まっている。 このワームは、IISを攻撃するのにCode Red (CRv1 & CRv2) と同じ脆弱性(Cert Advisory 2001-13 ; その和訳) を悪用するが、その後の活動はまったく別である。新たな感染ホストを 探すロジック自体がCode Redと異なっており、その頻度も非常に高い。さらに バックドアを設け、トロイの木馬を仕掛けるなどきわめて悪質な活動を行なう。 感染したホストについて は修正パッチを適用し再起動する(Code Redに対する対処)だけではまったく 不十分であり、レジストリ値の変更等も必要になる。また、こうした対処を しても、既にバックドアを悪用された可能性もあり、システムの全面的かつ 徹底的なチェックが必須である。それが難しい場合は、全面的な再インストール を行なうことが強く推奨される。

既にこのワームの活動によりインターネット全体 のパフォーマンスも低下が見られ、ホストによってはDoS(サービス妨害)攻撃 を受けたのと同等レベルの被害を受けている。また、比較的上流に位置する ルータや、限界性能の低いルータは攻撃パケットの流量の多さに耐え切れず、 きわめて不安定な状態に陥っているものが多数ある。

Code Red IIは攻撃パケットを送り続ける活動を24時間ないし48時間続けた のちシステムを再起動するとされている。そうでなかったにせよ、対策を講じない まま再起動すれば、ほぼ確実に再感染するため、8月9日現在でも攻撃パケット の流量はそれほど大きく減少していない。現在、インターネット全体で深刻な ネットワーク障害が各地で発生しており、IISを使用しているホストの管理者は できる限り早く適切な対処を取ることが社会に対する義務である。

目次

  1. 影響のあるシステム
  2. 記述
    1. Code Red IIの特徴
    2. 感染段階
    3. 自己拡散モード
    4. 侵入路の設置
    5. トロイの木馬による継続的なシステム書き換え
  3. 被害
    1. 感染したホストのこうむる被害
    2. 感染したホストが流す攻撃パケットによる被害
  4. 解決策
    1. 感染の確認
    2. 修正パッチを適用してあるかどうかの確認 未感染ホストの修正
    3. 感染ホストの修正/a>
  5. 参考文献

1. 影響のあるシステム

マイクロソフトが公開した対策手順マニュアルに影響を受けるシステムが 詳細に紹介されているので、そちらを参照されたい。

 Code Red による深刻な問題に対する防護策と対処方法についての説明

8月7日現在に判明していた影響のあるシステム

Code Red IIに直接被害を受けるのは次のシステムである。なお、 Code Redについては hash's Security Alerts 2001-01 Code Redワームについての情報を 参照されたい。

  • Windows 2000シリーズ(プロフェッショナル、サーバ等)で IIS(Internet Information Server) 5.0 (または4.0)を利用し、Indexing Serviceをインストールしている もののうち、MS01-033で提供される 修正パッチ(hotfix)を未適用のシステム。
  • Windows NT 4.0 + IIS 4.0 (または5.0)を利用し、Index Server 2.0をインストールしているもののうち、MS01-033で提供される修正パッチ (hotfix)を未適用のシステム、また、この他、IIS 4.0ないし IIS 5.0を使用しているシステム
    [注] Aris Security Alert等の文書ではWindows NT 4.0の場合はCode Red II に無関係である、としているが、トレンドマイクロは「日本語版、中国語版 のNT 4.0は感染する場合がある」としている。マイクロソフトはNT 4.0の 場合の対策手順も記載している(ただし、マイクロソフトはCode Redと Code Red IIの区別を明示的には行なっていない)。

また、Indexing Server 2.0、Indexing Serviceについては、本当の 問題は「付随してインストールされるidq.dllの脆弱性が問題なのであり、 この脆弱性は".idqまたは.idaへのスクリプトマッピングが有効になっていれば 付け入ることができる。Indexing Server 2.0 / Indexing Serviceを"利用して いるかどうか"は無関係である」。Indexing Server 2.0やIndexing Serviceは インストールしていない/使用していないので安全だと思っていた、と注意を 怠っていた事例が少なからずある、との報告があるので、この点注意されたい。

また、Code Red IIに感染するわけではないが、Code RedやCode Red IIが 送信する不正な長さのパケットを受信したためにバッファオーバフローを起こす ルータも報告されている。

  • Cisco CSS 11000シリーズ コンテンツサービススイッチ
    修正パッチを適用していないCisco 600シリーズ(DSLルータ)
    その他
    詳しくは Cisco Security Advisory: "Code Red" Worm - Customer Impactを 参照されたい。
  • Yamaha 50i, Yamaha 80iの初期リビジョンでWWWサーバ機能を利用している ケースでは、バッファオーバフローの結果、ルータが再起動する。
    詳しくは RTシリーズのTCP/IPに関するFAQ
  • この他にも多くのルータが同種の問題を抱えている可能性がある。 この点については上記のマイクロソフトの公式手順マニュアルを参照されたい。

2. 記述

ここでCode Red IIと呼ぶワームはその攻撃パケットのバイナリ部分に Code Red IIと書かれているため、本文書ではこれを名称としている。 ただし、これ以前にCode Redはオリジナルと亜種が発見されているため、 Code Red Version 3と呼ぶ文書もある。本文書ではオリジナルをCode Red CRv1、 亜種をCode Red CRv2、今回のものをCode IIとする。 (トレンドマイクロはCode Red Cと呼んでいる)

2.1. Code Red IIの特徴

ウェブサーバのアクセスログに見られるCode Red系の攻撃パケットは 次に示すとおり、Code Red (CRv1, CRv2)とCode Red IIはパディングに 使用されている文字が N か X かだけが違う。

アクセスログに見られるCode Redの攻撃パケット

"GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u78
01%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u81
90%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a

アクセスログに見られるCode Red IIの攻撃パケット

"GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u78
01%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u81
90%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a

しかし、この後のバイナリ部分はまったく異なり、概略、次のような 性質がある。

  • 感染して自身を広めようとしたりするのはWindows 2000 + IISの 場合で、Windows NT 4.0 + IIS等の場合は感染ではなくシステムないし IISをクラッシュさせる。これは後に述べるシステム書き換えがWindows 2000に合わせたものであり、Windows NT 4.0では無効なものであるため であると考えられる。
  • 自身を広めようとする(自己拡散モードとここでは呼んでおく)ため の攻撃パケットの送出量、頻度がCode Redより高く、その際の攻撃先のIPの 生成ロジックも異なる。基本的に感染ホストのIPアドレスと近いところ への攻撃が中心となる。
  • コマンドラインインタープリタであるcmd.exeをIISのスクリプト用ディレクトリ などにroot.exeとしてコピーする。また、c:\, d:\, \msadc, \Scriptsの各ドライブ、 ディレクトリを読み込み・書き込みの可能な仮想ルートとしてマップする。 これがバックドアとなり、任意の侵入者が任意のコマンドを実行できる。 つまり、被害にあった ホストがどこか分かれば(そして、これは自明と言ってよいほどすぐに 分かる)誰でも侵入して何でもできる、ということに他ならない。
  • c:\とd:\(存在する場合)にexplorer.exeというファイル名のトロイ の木馬を置き、上記の仮想ルートを設定し、かつ、それを継続的に 維持しようとする。
  • このトロイの木馬プログラムはまた、システムファイルの保護機能を 無効にし、書き換えを可能にする。

以下で各点について整理する。

2.2. 感染段階

  • 感染したホストのIPアドレスを取得する。このIPアドレスを元に 自己拡散モードにおける攻撃先IPの生成が行なわれる。
  • システム言語が中国語(Taiwanese, PRCの両方を含む)かどうかを チェックする。

  • 既にCode Red IIに感染しているかどうかを確認する。具体的には 既にCode Red IIがアトムをアトムテーブルに置いたかどうかを参照する。 アトムがあれば既に感染していると判断し、そのまま(新たに感染しよう としたCode Red IIのインスタンスが)休眠状態になり、再度活動すること はない(つまり、Code Red IIに同じホストが2度感染することはない)。 アトムがなければ、新たにアトムをアトムテーブルに置き、 その後の攻撃活動を続行する。

  • 中国語の場合は、自己流布のためのスレッドを600個作成し、これが それぞれ48時間、自己流布のために攻撃パケットを送信しつづける。 中国語以外の場合は、自己流布のためのスレッドを300個作成し、これが それぞれ24時間、自己流布のために攻撃パケットを送信しつづける。

  • トロイの木馬を設置する活動に入る。

  • 上記の期間限定はワーム自身がトロイの木馬を設置しシステムファイルを 書き換えたのち、休眠状態に入り、その後、システム をリブートするからである。Code Red IIはメモリ上にあるため、リブート した時点で(もちろん生成されたスレッドもなくなるから) 攻撃パケットの送信もなくなる。しかし、この時点で既にバックドアとトロイ の木馬が設置されているため、システムは任意の侵入者が任意のコードを 実行できる環境になっており、きわめて危険な状態である(にも関わらず、 気づかない管理者が多数発生する可能性がある)。また、以下で詳しく述べる ように、再起動後、再びCode Red IIに感染する可能性が高い。

注記: アトムについて

上記で言及したアトム(atom)については、 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/hh/winbase/atoms_0p83.aspに説明がある。概要をまとめておくと 次のようになる。 「アトムテーブルはシステムが定義するテーブルであり、文字列とそれに対応する 識別子を格納する。アプリケーションはアトムテーブルに文字列を置くと、アトム と呼ぶ16ビットのインテジャを受け取る。このアトムを使うことで先の文字列に アクセスできる。アトムテーブルに置かれる文字列はアトム名と呼ぶ」

アトムテーブルは主にアプリケーションの二重起動を避けるために 用いられており、Windowsを再起動すると内容は初期化される。 つまり、Code Red IIが二重感染しないようになっている、というのは 感染してから再起動するまでの期間の話であって、適切な対策を講じなければ 再起動後に再び感染することがある。

この点について筆者はWindows 2000 Professional(日本語版)＋IIS 5.0で 実験を行なったが、次のような結果であった。

  1. IIS 5.0を追加モジュールとしてインストールしてインターネットに接続後、 わずか3分後には感染した。
  2. その後、何ら対策を講じないで(ただし、再感染を確認するため、root.exe は削除した)、システムを再起動すると、やはり3分ほどで再感染した。

再感染するかどうかは、攻撃パケットが当該IPアドレス宛に送られてくる ことが大前提であるが、筆者の実験から分かる通り、現在の攻撃パケット流量 の多さから見て「適切な対策を講じず再起動するだけでは確実に再感染する」 と考えるべきである。実際、筆者の管理するホストのほとんどで24時間ないし 48時間以上の期間に渡って同一IPから断続的に攻撃パケットが送られてきて いるのを確認している。そのうちのいくらかは単にそのIPがネットワーク境界 になっているだけで、実際に感染しているのはその背後の数台と考えられる が、上記のように、実際に同一ホストが再感染する。

2.3. 自己拡散モード

自己拡散モードは2001年10月1日までの期間限定である。ただし、これは1台のホストが いったん感染した場合、そこまで流布を続けるのではない(上記のスレッドに関する 記述を参照せよ)。これは新たな攻撃先IPにパケットを送信する前にlocaltime をチェックしているためである。9月末日付近で初めて感染したホストがあった としても、10月1日を迎えた時点で、このlocaltimeのチェックでfalseとなるため、 その時点でシステムが再起動される。また、それ以前に感染したホストについて も既にシステムが再起動され、ワームはメモリ上から消えている。こうしたこと から、Code Red IIは2001年10月1日を迎えてすぐの時点で(これは最悪の場合でも ということだが)存在しなくなることになる。しかし、後述するバックドアや トロイの木馬にそうした期間限定は存在しないので、注意されたい。

自己拡散に当たって、攻撃する先のIPアドレスの生成を行なうが、これはCode Red の場合と異なり、確率的に次のようなルールで生成しているため、感染ホストに近い ホストほど攻撃を受けることになる。また、127, 224で始まるIPアドレス (つまり、127.xxx.xxx.xxxと224.xxx.xxx.xxx)は生成せず、 各オクテットの生成に当たっても0と255は生成しないようになっている、 という報告がある。この点について詳細にはSecurity FocusのIncident Analysis Reportの9ページを参照されたい。

  • 2分の1(4/8)の確率で、感染ホストと1オクテット目が同じIPアドレスを ランダムに生成する。
  • 8分の3の確率で、感染ホストと最初の2オクテットが同じIPアドレスを ランダムに生成する。
  • 8分の1の確率で、感染ホストのIPアドレスとは無関係にIPアドレスを生成する。

生成したIPアドレスへの攻撃に当たっては、非ブロッキングモードで接続を試みる。この場合、接続の完了を待たずに次の攻撃に移れるため、結果として、攻撃頻度が 高くなる。

この攻撃によって他ホストへの接続に成功すると、自身のコピーを送りつける。 現時点では自己改変機能はないため、Code Red IIはすべて同じ内容である。なお、 このコピーは約3.5KBある。

この攻撃頻度はきわめて高く、その結果、例えば筆者の管理するホストの 多くは8月4日午後以降、1時間に30件以上、攻撃パケットを受信している。 これはCode Redのときに比べて10〜30倍にも達している。この頻度はホストに よって異なるが、筆者が報告を受けた限りではやはり10〜30倍である。

なお、既に他でも指摘され始めているが、今回の攻撃パケットは特に 61.XXX.XXX.XXX、201.XXX.XXX.XXX, 210.XXX.XXX.XXX, 211.XXX.XXX.XXX の各ゾーンが圧倒的に多い。これは該当IP部分が小規模単位に切り売り されている、つまり、専任のシステム管理者がいないようなサイトが多く 固まっている、というのが原因の一つであると考えられる(いま一つの理由 として当該ゾーンは中国、台湾、香港、韓国、日本といったアジア系の各国 のISPに割り当てられていることが多いことが挙げられる)。特に 201.XXX.XXX.XXXのあるホストでは8月7日に1,000件を超える攻撃パケット を受け取ったという事例があった。

2.4. 侵入路の設置

自己流布の攻撃パケットを送信するだけでなく、Code Red IIは後で容易に 侵入可能にするためにパブリックにアクセスできる箇所に コマンドラインインタプリター(cmd.exe)を置き、かつ、トロイの木馬を作成する。

  • システムディレクトリを取得する(通常はc:\winnt\system32または c:\windows\system32である)。これは次のcmd.exeの配置場所を確認する ためである。
  • cmd.exeを次の2箇所にroot.exeとしてコピーする。 
    c:\inetpub\scripts\
c:\Program Files\Common Files\System\MSADC\

    ただし、筆者の8月9日深夜に改めて行なった感染実験においては 前者にのみコピーされ、後者にはコピー されない場合の方が多い。

  • c:\にexplorer.exeという名前のトロイの木馬を置く。これは保護された システムファイルとなっており、通常では表示されない。
  • 上記をd:\ドライブに対しても繰り返す。d:\ドライブがなければただ 失敗するだけである。

    これについても筆者が8月9日深夜に改めて行なった実験においては複数の パターンが存在した。上記の通りの場合も確かにあったのだが、別のケース として、c:\, d:\いずれにもexplorer.exeが作成されない例が1回あった。 それでもなお、後で述べるレジストリ等の変更は観察されたため、きわめて 似通った亜種が既に登場している可能性がある。(ただし、この点については 筆者の誤認である可能性もある)

ここで用意されたroot.exeにより、後から、任意の侵入者が任意のコードを 実行できるようになる。これは後述するトロイの木馬による継続的なシステム 書き換えによる設定変更が関係している。

2.5. トロイの木馬による継続的なシステム書き換え

c:\explorer.exeならびにd:\explorer.exeとして作成されたトロイの木馬 プログラムは次のような条件で動作する。

  • システムがリブートされるまでは実行されない。
  • リブート後も、Administratorないしそのグループに所属するユーザがログオン するまで実行されない。
  • SP2がインストールされておらず、MS00-052で提供される修正パッチも 適用されていない(MS00-052の修正パッチはWindows 2000 SP2に含まれている) 場合しか実行されない。これはこうした修正モジュールが 適用されている場合は、explorer.exeが必ず、本来の場所にあるものが優先的に 起動されるのに対して、こうした修正モジュールが適用されていない場合は、 トロイの木馬であるc:\またはd:\のexploer.exeが先に実行されるためである。

ただし、筆者が8月9日に改めて行なった実験では、システムを再起動する 前から以下のようなレジストリ等の改竄が行なわれたケースがあった。

実際にこのトロイの木馬のexplorer.exeが実行されると、次のような活動を 無限に繰り返す。

  • 次のレジストリ項目の値を 0FFFFFF9Dh に設定する。これにより、 システムファイル保護機能(WFP, Windows File Protection) が無効となり、書き換えの監視が行なわれていたはずのシステムファイルも 書き換えが可能になる。 
    SOFTWARE\MicrosoftWindows NT\CurrentVersion\Winlogon\SFCDisable
  • 次の4つのレジストリ項目(がなければ作成され)の値が217に設定される。 
     SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\Scripts
 SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\msadc
 SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\c
 SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\d

    これにより、ここで指定された.\scripts, .\msadc, c:\, d:\の各ディレクトリ、 ドライブが仮想ドライブとしてネットワーク上に公開されると同時に、217という 値がその読み込み、書き込み、実行を許可することを意味している。

  • 10分間休眠し、その後、同じ活動を永遠に繰り返す。

この仮想ルートの設定が繰り返されることにより、scriptsとmsadcの両 ディレクトリが確実にマップされ続けること、さらにc:\とd:\までもが 仮想ルートとして継続的にマップされてしまうことになる。この結果、攻撃者 は感染ホスト上で任意のコマンドを実行できる。特に注意されたいのは、 この結果、感染ホストであるかどうかさえ分かれば、誰でも攻撃者に なれるということである。その攻撃方法はきわめて単純であり(ここでは 敢えて記載しない)、高度な技術知識を持っている必要はまったくない。 つまり、Code Red IIの被害を受けたまま何ら対策を講じないのであれば、 世界中に向かって自分のマシンを攻撃してくださいと大声で叫んでいる のと同じである。

さらに、c:\とd:\が仮想ルートにマップされるため、たとえ上述のroot.exe を削除したとしても、自由に任意のコードを実行できることに変わりはない。

また、後からexplorer.exeを削除したとしても、少なくとも一度レジストリ が書き換えられば、それを修正しない限り、やはりバックドアは開いた ままである。

3. 被害

上記までで既に明らかであるが、被害は大きく(1) 感染したホストの こうむる被害、と、(2) 感染したホストが流す攻撃パケットによる 被害に分けられる。

3.1. 感染したホストのこうむる被害

既に上述であきらかであるが、感染したホストは他に攻撃パケット を多数送信する(この活動の結果、DoS(サービス拒否)状態になる可能性 がある)こと以上に、誰にでも簡単に使えるバックドアを広く開けてしまう 点がもっとも危険である。できる限り早く解決策 で提示した手順に従って、復旧を行なう必要がある。

なお、ファイアウォールの中にある ホストも感染したという報告が当方にも寄せられている。この原因は 現時点では未確定だが、可能性としては、(1) 内部と外部を分ける NICを2枚以上持つホストが感染する、(2) このホストのIPアドレスを 取得する際、内部側のIPアドレス(ほとんどの場合、プライベート アドレスであろう)を取得することがある、(3) この場合、内部に対して 攻撃パケットを多量に送ることになる、(4) 小規模サイトでは内部に 割り振ったIPアドレスは少量であることが多いため、必ずしもすべて の内部ホストに攻撃パケットが送られるわけではない(から、すべてが 感染するわけではない)、というものが考えられる。この件について 実例等があれば、(For Your Informationとしての)ご報告を歓迎する。

3.2. 感染したホストが流す攻撃パケットによる被害

現在、世界中でCode Red並びにCode Red IIに感染したホストが 流す攻撃パケットは莫大な量に達しており、 CPUの高負荷になり空きメモリが逼迫してルータが不安定になる 事例が多数報告されている。これは当該ルータが不正に長いパケット を受信した結果、バッファオーバフローを起こすというパターンだけで なく、純然と流量の莫大さに耐え切れなくなったケースが多々発生して いる点に注意しておきたい。このため、8月4日以降、現在にいたるまで その解決にも至らずネットワークが事実上使用不能になっているところ が多数ある。日本の場合、特に学術系ネットワークで深刻なネットワーク 障害がここ数日続いている。

参考までに実際どれくらいの攻撃パケットが流れるかを筆者の実験から 紹介しておく。筆者の実験では、まず上流に対しては128Kbpsの専用線で 接続されており、実験用脆弱ホストが感染するまでは帯域の利用率は数%で あった。この脆弱ホストがCode Red IIに感染したのち1分以内に帯域利用率 は30%を超え、5分以内に70%にまで上昇した。つまり、単純に考えれば、 わずか1台のホストが感染するだけで80Kbps以上の帯域を食いつぶすので ある。

また、既に述べたとおり、Code Red IIに一度感染したホストも、対策を 講じないまま再起動した/された場合、ほぼ確実に再感染する。このため に当初一部で楽観的に期待されていた「2, 3日で攻撃パケットの流量は 激減するであろう」という予測はまったく間違いで、8月9日を過ぎても 攻撃パケットの流量はせいぜい1割程度しか減っていない(つまり、 感染ホストで適切に修正されたのがその程度しかないということだろう)。

4. 解決策

8月8日以降は既にマイクロソフトから公式の 対策手順書が出ているのでそちらを参照されたい。本文書の本セクション は8月9日以降は更新しない。

マイクロソフトより次の詳細な修正/復旧手順マニュアル

Code Red による深刻な問題に対する防護策と対処方法についての説明

以下は参考のために残しているものであり、8月9日以降は対策手順として は参考にしないこと

Code Red IIの場合、Windows NTの場合は、Code Redと同じ対処 であるので、 hash's Security Alert 2001-01などで紹介されている手順を踏むこと。

一方、Windows 2000の場合は、Code Redに比べ確認、復旧 の手順はかなり増えることになる。Code Red (CRv1, CRv2とも)の場合、感染した場合もシステムを 再起動し、修正パッチを適用することで感染そのものからは復旧できる とされているが、Code Red IIはトロイの木馬を仕掛けたり、その後の 侵入路を用意したりするために、復旧の手順も複雑になる。さらに、 侵入路が用意されたために感染された事実を発見するのが遅れた場合、 Code Red IIへの感染後にシステムへ侵入された可能性があり、その 場合は、どのような改竄が加えられたかを徹底的にチェックする必要が ある。原則としては、c:\, d:\を含む全ドライブをフォーマットしなおし、 全面的な再インストールをすること推奨する。

4.1. 感染の確認

修正パッチを適用していない場合、アクセスログに1.で示したCode Red IIの攻撃記録があれば、感染していると考えた方がよい。しかし、 その記録がなかったとしても感染していないとは保証できない(現時点では 複数の見解があるが、感染した そのときの記録はログに残らないとする報告がある)。

また、 netstat -naで異常な数のパケットを送信していないか確認すれば 感染しているかどうか分かるというCode Redと同じ判別方法を紹介して いるものもあるが、これは間違いである。Code Red IIはCode Redに 比べて自己拡散モードの期間が短く(日本の場合は通常1日間である)、 netstat -naで判別できる期間は限られている(例えば、多くの企業など では週末に感染した場合、週明けにはもうこの判別法は使えない)。 むしろ、トロイの木馬に関係するファイルが置かれているかどうかを もって感染の確認をすべきである。

  • c:\explorer.exeがあれば確実に感染している。
  • c:\inetpub\scripts\root.exeや c:\Program Files\Common Files\System\MSADC\root.exeが あれば確実に感染している。
  • トロイの木馬版explorer.exeは感染したのちに再起動して から管理者権限をもつユーザがログオンするときまで実行されない ため、レジストリ値の変更点を見たり、仮想ルートが設定されて いるかを確認するのは十分なチェックではない。

また、そもそもIISを動作させているかが分からないというケース も頻繁に報告されている。この確認は簡単には以下のようにする。

  • タスクマネージャを起動する (CTRL + ALT + DELを同時に押し、表示されたダイアログボックスで タスクマネージャのボタンをクリックするのが簡単である)
  • 「プロセス」タブを選択肢、イメージ名欄でInetinfo.exeを探す
  • もしInetinfo.exeがあればIISを動作させているのであり、必要な修正 パッチをインストールせよ。なければIISは起動されていないので、これ 以降の対処は一応、不要である。
  • ただし、現在、IISが起動されていなくても、インストールされている場合は ある。この場合は、修正パッチを適用すべきである。
  • 脆弱性の直接的な原因はインデックスサービスのDLLであるが、インデックス サービスを使用しているかどうかは無関係であるため、IISの存在をもって修正 パッチの適用を判断すべきである。

4.2. 修正パッチを適用してあるかどうかの確認

修正パッチを適用しているかどうか分からない場合、もう一度適用する か、以下のツールを使って確認せよ。ただし、これは英語版であり、日本語 Windowsで適切に動作するかは現時点では未確認である。

http://www.microsoft.com/Downloads/Release.asp?ReleaseID=24168

4.3. 未感染ホストの修正

未感染ホストと言ってもいつ攻略されるかきわめて危険な状況である。 できるだけ早期に修正パッチを適用する必要がある。

  1. 以下の修正パッチはWindows 2000 SP2以降用である。SP2をまだ インストールしていない場合は、すぐにインストールすること。
  2. MicrosoftからWindows 2000 Professional, Server 並びに Advanced Server用の 修正パッチを http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30800 にアクセスし、Japaneseを選択してダウンロードせよ。 ダウンロードされるファイルは Q300972_W2k_SP3_x86_ja.exe である。
  3. 感染してしまう危険を少しでも避けるため、上記ファイルをダウンロード したらいったんインターネット/ネットワークからマシンを切り離すことを 強く推奨する。
  4. ダウンロードした修正パッチを適用する。
  5. システムを再起動して、ネットワークに接続しなおす。

4.4. 感染ホストの修正

Code Red IIに感染したホストはCode Red IIのコードをメモリから 除去して、修正パッチを適用するだけでなく、不正に置かれたファイル の削除、改竄されたレジストリの修正が必要である。しかし、これで完全 に復旧できたとは保証されない。設けられたバックドアを利用してリモート から侵入され、任意のファイルが改竄された可能性がある。重ねて指摘する が、こうした侵入はCode Red IIを開発した人間だけでなく、誰にでも 可能である。このため、通常のバックドアよりもはるかに危険であり、 既に誰かが侵入した可能性も十分ある。いったん侵入すれば任意のコード を実行できるため、アクセスログに残る侵入の痕跡自体も消すことができる から、アクセスログを確認するだけでは十分ではない。今回のような 場合は特に侵入の有無を 検証するのはかなりの時間と労力がかかるため、システムの全面的な 再インストールの方が早いかもしれない。(筆者がこの被害にあったと すれば、侵入の有無の検証は事実上不可能と考え、迷わずシステムの 全面的な再インストール、必要なファイルの感染前に取ったバックアップ からの復旧、という手順を取るであろう)

まず、参照文献[1]に示された対処法を若干修正して紹介する

  1. Microsoftから自分のバージョンに合ったIIS Web Server用修正パッチ をダウンロードする。 Windows 2000 Professional, Server 並びに Advanced Serverについては、 http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30800 にアクセスし、Japaneseを選択してダウンロードせよ。 ダウンロードされるファイルは Q300972_W2k_SP3_x86_ja.exe である。
  2. 感染/再感染を防ぐためインターネット接続から切り離す
  3. もしc:\explorer.exe, d:\explorer.exeがあれば、それはトロイの木馬 なので削除する。(通常はc:\やd:\にexplorer.exeは存在しない)

    なお、Administratorがログオンしている場合、(感染してから再起動するまでに) Administratorでログオンしたことがある場合、これらファイルが削除でき ないことがある(SP2またはMS00-052を適用していない場合)。 これはトロイの木馬が実行されている状態であるために c:\explorer.exeが使用中であるとして削除できないというものである。 この場合は再起動後に一般ユーザとしてログオンして削除せよ。また、 この時点でc:\explorer.exe, d:\explorer.exeが削除できる場合(SP2または MS00-052を適用している場合)は、後で見るレジストリの改竄は行なわれて いない可能性がある(この点は現在未確認)。

  4. メモリ上からワームを除去するためにシステムを再起動する。
  5. 1つ前の手順でAdministratorとしてはc:\explorer.exe, d:\explorer.exe が削除できなかった場合、Administratorとしてログオンする前に、 一般ユーザ、パワーユーザなどAdministratorグループに所属しない アカウントでログオンして、c:\explorer.exe, d:\explorer.exeを削除 せよ。
  6. 再感染を防ぐため、1.でダウンロードしておいた修正パッチを適用する。
  7. (再起動後も)もしc:\explorer.exe, d:\explorer.exeがあれば、もう一度 削除する
  8. レジストリ値を変更する前に再び再起動する
  9. c:\inetpub\scripts\root.exe, d:\inetpub\scripts\root.exeがもしあれば、 root.exeをすべて削除する。(本来、このようなファイルはない)
  10. 以下のレジストリ項目をレジストリエディタで、その値を 0 に 設定しなおす。これで ワームにより解除されていたシステムファイル保護を再び有効になる。 
    SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogno\SFCDisable
  11. Code Red IIはリモートからのウェブアクセスのために以下のレジストリ値 を217に設定する。IISをデフォルトでインストールしている場合、以下のレジス トリそのものが不要であるので、レジストリ項目自体を削除するか、値を 0 に設定する。もし利用している場合は、本来の値に戻す。 
     SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\Scripts
 SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\msadc
 SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\c
 SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\d
  12. 再度、システムを再起動する。

重ねて注記するが、この対処によってCode Red IIの除去とそのシステム 改変の修正は行なわれたわけだが、Code Red IIが用意したバックドア等を 悪用してシステムに侵入された可能性は否定できない。この点について徹底的な 検証は一般に困難であり、確実な対処は、システムの全面的な 再インストール以外ないと言っても過言ではない。以下に筆者の推奨する 対処を紹介する。

  1. 感染を確認したら、いったんインターネット/ネットワークから切り離す。
  2. 必要なデータが存在する場合は、Windowsがインストールされているのと は別のハードディスク、リムーバブルメディアに退避するか、ネットワーク から当分切り離して差し支えない別マシンに退避させる。
  3. c:並びにd:を含むハードディスクは必ずフォーマットしなおして、 システムの全面的な再インストールを行なう。
  4. SP2ならびに上記の修正パッチを適用する。
  5. 必要なソフトウェアをインストールしなおす。
  6. 必要な文書ファイルその他については原則として感染前に取ったバックアップ から復旧する。これができない場合は、最低限、ウィルス検知ソフトなどで 何かウィルスが送り込まれていないか確認する。

参考文献

Code Red IIそのものについて

  1. シマンテックのCode Red Check
  2. トレンドマイクロのワーム「CodeRED」セキュリティホール検知ツール
  3. トレンドマイクロの「CODERED.C」自動駆除ツール
  4. JPCERT: 緊急報告 - Microsoft IIS の脆弱性を使って伝播するワーム "Code Red II"
  5. CERT/CCのIncident Note 2001-09; その和訳
  6. http://www.incidents.org/react/code_redII.php: 詳細な分析がある。
  7. Aris predictorによるCode Red IIの警告文書(PDF文書)
  8. Aris predictorによるCode Red IIの分析レポート(PDF文書)
  9. Incident MLに投稿された分析レポート(Marc Maiffret による): 詳細な分析レポートもここからダウンロードできる。
  10. SysportCoreによるCode Red IIの詳細な記述
  11. http://www.incidents.org/diary/diary.php
  12. http://www.geocrawler.com/lists/3/SourceForge/4890/0/6330369/
  13. http://grc.com/x/talk.exe?cmd=article&group=grc.security&item=21298&utag=
  14. JPCERTの"Code Red" Wormに対する注意喚起

Code Redについて

  1. hash's Security Alert 2001-01とそこに挙げた関連文書

謝辞

本文書の作成に当たって参考にさせていただいた文書の作成者達に感謝する。 また、本文書の旧版を作成するにあたり、 筆者がログ等の解析を行なうに当たって自サイトのログを提供していた だいた方々、Linux User's Groupのliloに深く感謝する。特に斎木 理緒氏には さまざまな情報を提供していただいたことに深く感謝する。
また、本文書の改訂に当たって特にSysportCoreの井口氏のご指摘も参考にさせて いただいた。記して感謝する。また、このワームに攻略されたホストの管理者 からも本文書の内容を裏付ける状況報告をいただいた。名誉のため名前は記さない が、報告に感謝する。
さまざまな文書の探索には小島肇さんの セキュリティホールmemoが参考になった。

このページはhash's Secutiry Alert 2001-02として発行するものである。 2001-02は当初8月6日早朝にリリースしたが、その後判明した情報に基づき 全面的に改訂した。改訂前の文書は既に価値を失っているが、記録のため、 8月6日リリースの初期文書に置く。
また、8月9日早朝にもかなり改訂を行なったため、記録のため 8月7日リリースの全面改訂版(8月8日午後に最終更新)に置く。
hash's Security Alertはコンピュータセキュリティに関する情報のうち、 とりわけ緊急性の高いものについて、筆者独自の調査ならびに関係各所の 情報を取りまとめて提供する。改善案等については歓迎である。

なお、このページに掲載したいかなる情報も無保証であり、ここに書かれた 情報を利用した結果起こるかもしれない一切の損害、不具合等については 筆者は責任を負いかねる。

作成者橋本 喜代太