Insider's Eye緊急リポート
|
|
デジタルアドバンテージ |
8月になってまたCode Redワームが活発な活動を開始している。その危険性や侵襲性の高さのために、一般の新聞やTVのニュースにもなっているくらいだ。編集部のIISサーバも、原稿執筆時点で、それぞれ異なる相手から(1 IPアドレスにつき)1時間に10回以上のアタックを受ける状態が続いている。このワームは、Windows NT/2000のIIS(Internet Information Server)のセキュリティ・ホールを使って多数のシステムに侵入し、同時にある特定のサイトに対する分散型のサービス拒否攻撃(DDoS攻撃)を仕掛けるというものである。ただし日本語版環境のWindows NT/2000+IISの場合は、Code Redの攻撃を受けた時点でWebサーバ(IISのサービス)が異常停止するという例も見受けられる(ここ最近、起動して数時間でIISのサービスがダウンするというのは、Code Redのせいだと考えてよいだろう)。
Code Redワームの被害について
このワームは、IISに対してワームのコードを含んだHTTPコマンドを送り付けて、バッファ・オーバーフロー攻撃をしかけるというものである。IISをターゲットとしているため、一般的にはIISを稼働させているWindows NT/2000 Serverでなければその影響は受けず、クライアント用途のPCなどは大丈夫であると言われている。しかし他のシステムに侵入するために無差別にインターネット上のWebサーバへの接続を試みるため、次のようなさまざまなトラブルが各所で発生している。
-
感染先を求めて無差別に接続要求を出すため、回線が混雑し、同じISPを使っている(回線を共有している)ほかのユーザーの通信もその影響を受ける。最悪の場合は、通信がほとんどできなくなる。これに対しては、ユーザー(影響を受けているユーザー)の側では有効な対策はなく、Code Redに感染しているサーバが対策されるのを待つしかない。
-
IIS以外のWebサーバでも、バージョンによっては、長いHTTP要求を受けてハングアップしたり、動作が不安定になったりする。特に、Webで操作できるようになっているルータ機器などがハングアップする事例が多数報告されている。これはそのサーバ・ソフトウェアのセキュリティ・ホールであるので、直すためには最新のバージョンに入れ替えたり、パッチを当てたりする必要がある。
-
Webサーバでなくても、通信に含まれるHTTP要求を解釈するようなネットワーク機器(Proxyサーバなど)でも、不正な長いHTTP要求を受けて、ハングアップしたり、動作が不安定になったりする。この場合もファームウェアのアップデートなどを行う必要がある。
-
インターネットに接続されていて、グローバルIPアドレスを持っているすべての機器(サーバやルータ、コンピュータなど)は、その攻撃の対象となる。ただしWebサーバのポートはクローズしているので、実際には被害はないが(TCPの接続要求が拒否されるだけ)、ネットワークの帯域がそのために無用に消費され、ネットワークのパフォーマンスが下がることになる。これはCode Redが根絶されるまで有効な対策はないと思われる。
-
あらゆるIPアドレスを攻撃の対象としており、実際にネットワーク機器やマシンが接続されていないIPアドレスに対しても接続要求を出している。そのため、有効な宛先のないパケットが多数生成されることになり、ネットワークの帯域が無用に消費される。これもCode Redが根絶されるまで有効な対策はないと思われる。
-
HTTP要求を使った攻撃であるため、パケット・フィルタリングではブロックすることはできず、Webサーバ側で対策が必要となる(実際には不正な要求であるので、単に無視すればよい)。
-
現状では、十分な管理の行き届いていない環境のIISサーバが多く感染している。つまり、専任の管理者がいないような小さな組織のIISサーバや、個人ユーザーの所有しているIISサーバが多数感染しており、このようなケースでは、所有者も何が起こっているかをまったく把握していないことが多い。そのため、Code Redに感染したサーバが急に根絶されることはないと考えられる(つまりこのような状態が完全に収束するのは期待薄ということ)。
- Code Redにより、ファイアウォールのログに非常に多数のHTTPアクセス記録が残る。そのため、Code Red以外の攻撃ログを見落としてしまう可能性がある。
このワームは、HTTPサービスのポート(TCPの80番ポート)に対してワームのコードを含んだHTTPコマンドを送り付けて、バッファ・オーバーフロー攻撃をしかけるが、機器によってはそのHTTP要求を内部へ取り込む時点でバッファ・オーバーフローを起こしてしまい、システムがハングアップしてしまう。例えば、Web経由で操作できるようになっているルータ(ISDNダイヤルアップ・ルータやブロードバンド・ルータなど)がその影響を受ける可能性がある。本来ならば、インターネット側からはアクセスできないように設定したり、きちんとパケット・フィルタなどをかけておくべきなのだが、ユーザーによってはそのことをまったく知らずに使っていたり、パスワードで保護しているから大丈夫などと考えていたりする。しかしHTTP要求そのものがバッファ・オーバーフローを起こすほど巨大で不正なものであれば、パスワードを解釈する以前に、HTTPの読み込み時点でシステムがハングアップしてしまい、ルータを再起動する必要に迫られる。このような現象はログファイルには残らないので(ログを記録する前にシステムがハングアップしてしまうから)、原因を追及するのが難しい。
知人の会社でも、「今日はひんぱんにルータがハングするのだけれども、なぜだか分かりませんか?」と弊社に問い合わせてきたところがある。弊社でも同じISP(東京めたりっく通信)のDSL回線を導入しているので、同様の症状が出ていないかどうか、聞いてきたのである。東京めたりっく通信が使用しているDSLルータは、ISP側からルータをリモート監視するために、外部からWebで操作できるようになっている。もちろんパスワードを付けて保護されてはいるのだが、何分バッファ・オーバーフロー攻撃に対する対処は行われていなかったようだ(不正な要求なのだから単にエラーを返せばよいのだが)。とりあえずは、インターネット側からのHTTPポートへのアクセスを禁止する方法で対処したようである(トラブル情報ページの「2001年8月1日20時〜」の情報を参照)。これと同様のことは、あちこちのプロバイダでも起こっている(特にDSLのような常時接続環境で多発している)。8月になって(もしくは7月の20日頃から)ルータがハングアップするというような事態がちょくちょく発生しているユーザーは、一度設定を自分で確認していただきたい。ちなみに弊社で導入していたのはSDSL回線であったので、ルータの仕様が異なり(もともと外部からはアクセスできない)、ルータがハングアップするという事態は避けられたようである。このほかにも、「ヤマハRTルータ(RT80iおよびRTA50i)のWWWサーバの脆弱性に関する情報」のように、Code Redの影響を受けているルータもある。
以上はルータの話であったが、ルータ以外でもHTTPを解釈するような機器は同様の影響を受ける可能性がある。例えばHTTP要求をリダイレクトしたり、キャッシュしたりするようなファイアウォールやProxyサーバ(Webサーバを公開するのに使われる、リバースProxyサーバなど)、高機能なルータなどが該当する。例えば「Cisco Security Advisory: "Code Red" Worm - Customer Impact」のように、特定のルータやソフトウェアがCode Redの影響を受け、動作が不安定になったり、ハングアップしたりするようである。これ以外にも、HTTPのアクセス要求を直接受けるような機器(Webカメラなど)はCode Redによって何らかの不具合がないかどうかを確認しておく必要があるだろう。また当然、IIS以外のWebサーバでもきちんとCode RedによるHTTPアクセスを無視したり、ブロックしたりしているかどうかを確認しておく必要がある。
Code Redワームとは?
Code Redワームとは、すでに述べたように、Windows NT/Windows 2000上で動作するIIS 4.0/5.0のセキュリティ・ホールを突いた分散型DoS攻撃のためのワームである*1。2000年7月中旬頃に活動を開始して1日で30万台程度に感染し、現在でもまだ20万台以上のシステムが感染しているとされている。特に、専任のシステム管理者がいないような小さな会社などのIISサーバや、個人でDSL回線やCATV回線を使って立てているようなIISサーバは、十分なセキュリティ対策も施されていないことが多く、その分、感染しやすくなっている。またCode Redワーム自体もすでに複数のバージョンが確認されており、DDoS攻撃の対象も変化している。
*1 ワーム(worm。虫、寄生虫など)は、ウイルスと似ているが、特にネットワークを使って複製、増殖するプログラムを指す。もともとはネットワークの管理など、有益な目的に使われることも想定されていたが、現在ではウイルスのように、クラックのために使われるものを指す場合がほとんどである。ワームの語源は、ジョン・ブラナーのSF小説『衝撃波を乗り切れ』に出てくるtapewormにちなんでいる。tapewormは、ネットワークへ送り込まれて自己増殖、複製するプログラムで、専制的な政府が管理するネットワークを破壊するために作られた。ここから、このタイプのウイルスをワームと呼ぶようになった。 |
システムへの侵入は、IISのセキュリティ・ホール(バッファ・オーバーフロー攻撃)を使って行われる。とりあえず以下の例をみていただこう。これはCode
Redに対するセキュリティ対策を施したIISのログファイルから、アタックされている部分を抜き出したものである。外部から頻繁に侵入を試みている様子が分かるだろう。8月6日現在では、(1つのIPアドレスにつき)1時間に10回以上は世界のどこからか攻撃を受けている、というような状況である。そしてこのペースはわずかずつではあるが増加傾向にある。
[注意] |
これは、Code Red対策を施したIISサーバのログである。対策を施していない場合は、日本語版Windows 2000上のIISサーバは、このようなログを残さずに単にIISのサービスが異常終了してしまう場合もある。 |
これを見れば分かると思うが、Code RedではHTTPのGET要求を使って、「/default.ida」というファイルを要求しているだけである。ただし「XXXX……… %u0078%u0000%u00=a」もしくは「NNNN……… %u0078%u0000%u00=a」という非常に長い引数文字列(360バイト程度)が付加されている。「/default.ida」というファイルに付けられた「.ida(Internet Data Administration )」というファイル拡張子は、Indexing Service(全文検索エンジン)に対するISAPI Extension(idq.dll)を使うためのものである。そのため、このGET要求を処理する場合はidq.dllが起動されるが、デフォルトでは、この中のURL処理部分にバッファ・オーバーフローをチェックするコードが欠けており、悪意のあるパラメータを使えば、バッファ・オーバーフロー攻撃を仕掛けることができる。先の引数のうち、最後の方にある意味ありげな数字列はスタック中の戻りアドレス(サブルーチンからの戻り先のアドレス情報)を上書きするためのものである。実際のGET要求では、この引数に続いて、Code Redワームのバイナリ・コードが付加されており(そのため、GET要求のサイズは全部で4Kbytesほどある)、戻りアドレスを操作することにより、ワームの先頭部分へジャンプするようになっている。
なお、単に先頭の「GET /default.ida?XXXXXXXXXXXXX……」だけをtelnetなどで80番ポートへ接続して送信しても、戻り先がないので、IISは異常終了してしまい、ワームとしては機能しない。しかし、異常終了すること自体がすでにWebサーバとしては問題なので、単にWebサーバの脆弱性を検査するだけならばこの方法でも十分である。管理しているWebサーバに対してこのような長い文字列を送信し、脆弱性がないかどうかを検査しておいていただきたい(テストによってIISやWebサーバが異常終了するようなら、そのサーバはバッファ・オーバーフローに対する対策が加えられていないことになる)。
このワームでは実際にIndexing Serviceを使うわけではないので、システムにIISと、Indexing Serviceがインストールしてあり、「.ida」に対するidq.dllへのファイル・マッピングが設定されていれば、Indexing Serviceを起動していなくても感染してしまう。
Code Redワームの動作は、侵入したシステムの時刻に基づいて、次の3つのフェーズに分けられる(各システムの内蔵クロックがずれている場合は活動時間がずれる可能性がある)。
1.増殖フェーズ
毎月1日から19日はこの増殖フェーズになる。このフェーズでは、ランダムなIPアドレスに向けてTCPの80番ポート(HTTPポート)への接続要求を発行し、コネクションが確立すれば(つまりWebサービスが稼働していれば)、ワームのコードを含むHTTPのGET要求を送信する。相手のサーバがIISかどうかや、Windowsシステムであるかどうかなどは関係ない。とにかくひたすら、マルチスレッドで同時並行的に無差別にWebサービスへの接続を試みるので、これが結果的にインターネット全体のトラフィックを高めるという結果を招いている。ネットワークの帯域幅にもよるが、その増殖能力は、1時間に数万〜数十万IPアドレスに向けてトライできるほどだと言われている(単にTCP接続して、GETコマンドを送るだけだから、この程度は可能だろう)。なお、このとき相手先がすでにCode
Redに感染しているかどうかは関係なく、感染処理が行われる。また、Code Redはメモリ上に常駐するだけなので、システムをリブートすると除去されるが、攻撃を受けると再度感染してしまうので、きちんとセキュリティ・パッチを適用する必要がある。
2.攻撃フェーズ
毎月20日から27日は実際にDDoS攻撃を仕掛けるフェーズになる。Code Redの最初のバージョンは、固定的なIPアドレスに対する攻撃がハードコーディングされていた。当初はこのIPアドレスは米ホワイトハウス(http://www.whitehouse.gov/)を指していたが、先月のCode
Red起動前にホワイトハウスのIPアドレスが変更されたので、難を逃れたようである。現在ではDNSを引くような変種に進化しているようなので、何が起こるかはまだ予断を許さないというところであろうか。
3.休止フェーズ
毎月28日〜月末までは休止フェーズであり、ワームはシステムに潜入したまま翌月になるのを待つ。
進化するCode Redワーム
Code Redワームにはすでに何種類かの亜種が確認されているが、8月4日の夕方頃からは特にCode Red IIなどと呼ばれるものが見つかっている。先の例で、引数が「XXXXX……」となっているのがそうである。これは、攻撃先のIPアドレスの範囲を、最初に感染したノードの近辺に集中するように走査するタイプであり、より効率的に多数の相手へ感染することが可能になっている(最初のバージョンは、ほぼランダムにIPアドレスを選んでいるので、存在しないノードへのアタックも多かった)。また、バックドアを仕掛けたりする機能も持っているようであり、今後も各種の亜種の派生が予想される。
Code Redワーム対策
Code Redで使用しているのは単なるGETコマンドであり、これだけを禁止することはできない(GETを禁止すると、Webサーバとして機能しなくなる)。そのため、できる対策はIISシステムに次に述べるセキュリティ・パッチを適用して、バッファ・オーバーフロー攻撃を受けないようにすることである。また、Webサーバ上でIndexing Serviceによるサービスを提供しないのであれば、そのマッピング(.idaや.idqのマッピング)も削除しておく。ファイルのマッピングはサーバ単位だけでなく、Webサイト単位でも可能なので、必要なサイト以外では不要なマッピングをすべて削除する。IISをインストールするとデフォルトではこれ以外にも多くのマッピングが用意されるので、それらも以下の指示に従って削除しておくことが望ましい。
Code Redはその危険性が高いところから、マイクロソフトのセキュリティ・ページにおいて特別に情報がまとめられているので、それらを参考に対策を施しておいていただきたい。
- Code Red による深刻な問題に対する防護策と対処方法についての説明
- Windows 2000 Professional 用 Code Red ワーム対策ガイド
- 緊急:Code Redワームに対する警告
- "Code Red" IISワームに関する情報
- Index Server ISAPI エクステンションの未チェックのバッファにより Web サーバーが攻撃される (MS01-033)
またCode Redの変種で、システムにバックドアを仕掛けるというCode Red IIに感染したシステムから、悪意のあるファイルを取り除くツールが8月10日にマイクロソフトから提供された。
具体的には、次のようにする。
-
対策途中での感染を防ぐため、システムをネットワークから切断する(ネットワーク・ケーブルをはずす)。
-
上のCode Red IIワーム排除ツールをダウンロードし、Code Red IIによるバックドアがすでに存在する場合に備えてこれを排除する(次に述べるCode Red II対策用パッチを適用するだけでは、バックドアは排除されないため)。
-
「MS01-033」のページから Windows 2000用 パッチ(PC/AT互換機用) か Windows 2000用パッチ(NEC PC-9800用)、Windows NT 4.0用パッチ をダウンロードしてシステムに適用する。
-
メモリ上に常駐しているコードを除去するためにも、パッチを適用した後はシステムをリブートする。システムがリブートしたら、ネットワーク・ケーブルをつなぐ。
Windows 2000 Professionalシステムに対する対策作業は、前述のマイクロソフトのドキュメント(Windows 2000 Professional 用 Code Red ワーム対策ガイド)が詳しいので参照されたい。
ところで、最初の「緊急 : Code Red ワームに対する警告」では「日本時間 8 月 1 日 午前 9 時までにご対応ください 」と書いてあるので、ひょっとすると「8月1日」を過ぎるともう影響はないと考えるかもしれないが、それは正しくないということに注意されたい。先に解説したように、毎月1日になると活動を開始するということであり、常に危険性があることには変わりない。必ずこのセキュリティ対策を施すようにしていただきたい。
Code Red関連情報 |
|
更新履歴 | |||
|
「Insider's Eye」 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|