Insider's Eye 管理者のジレンマを突いて爆発的に繁殖したSQL Slammer
デジタルアドバンテージ 2003/01/28

---

　2003年1月25日 土曜日、週末のネットが突然の機能不全に陥った。原因はSQL Slammer（slammerは「ブタ箱」の意味）と呼ばれる新種のコンピュータ・ワームが短時間に爆発的に感染を広げ、感染したコンピュータが帯域いっぱいに感染パケットをインターネットに向けて発信したためだ。詳しい原因はいまなお調査中だが、SQL Slammerの影響により、米国ではオンライン・バンキングなどが一時使用不能に陥り、韓国ではオンライン・ショッピングやチケット予約などのインターネット・サービス全体がアクセス不能になったという。

　日本国内では、25日の14時すぎをピークとして、SQL Slammerの感染パケットがネットワークを駆け巡った。この様子については、セキュリティ・ソリューション提供企業であるインターネット セキュリティ システムズのWebサイトにある感染パケットの検出結果を見るとよく分かる。

・SQL Slammerワームに関するインターネット セキュリティ システムズのページ

　SQL Slammerは、SQL Server 2000（およびそのデータベース・エンジン部分であるMicrosoft Desktop Engine 2000）を組み込んだコンピュータで、2002年7月に報告されたセキュリティ情報番号MS02-039のセキュリティ・ホールをふさいでいないものをターゲットとして感染を広げる。このセキュリティ・ホールを修正する単独のHotFix（修正プログラム）を適用しているか、またはこれを含む累積的な修正プログラム（MS02-061）ないし先ごろ発表されたSQL Server Service Pack 3を適用しているコンピュータは感染しない。つまりセキュリティ・ホールを修正するHotFixは半年も前に提供されていたにもかかわらず、これを適用していないコンピュータが少なくなかったということだ。

　感染パケットのトラフィックは一段落したように見えるが、再燃しないという保証はない。対象となるSQL Server 2000とMSDE 2000を使っている可能性がある場合は、マイクロソフトの情報ページなどを参照して、HotFix適用の必要性の確認と、必要ならHotFixの適用をすみやかに実施する必要がある。以下、関連情報サイトの情報をまとめておこう。

・SQL Slammerワームに関する情報ページ（マイクロソフト）
・セキュリティ情報 MS02-039（マイクロソフト）
・SQL Slammerワーム情報（シマンテック）
・SQL Slammerワーム情報（トレンドマイクロ）

　SQL Slammerの被害はどうしてこれほどまでに広がったのか？ HotFixを正しく適用しない管理者の怠慢として片付けるのは簡単だが、事態はそれほど単純でもなさそうだ。より強固なWindowsセキュリティを維持するために、今回の一件を教訓として生かすにはどうすればよいか。まずはSQL Slammerワームの技術的背景を踏まえたうえで考察してみよう。

SQL Slammerワームとは

　今回のワームは、SQL Server 2000およびSQL Server 2000 Desktop Engine（MSDE 2000）を対象に活動するワームであり、これらのソフトウェア（以後まとめてSQL Serverとする。MSDE 2000も含むので注意）が提供している「解決サービス」用のUDPポート（1434番）にワーム・プログラムを送り込んで感染活動を行う。SQL Server 2000の解決サービスにはバッファ・オーバーフローの脆弱性があり、このポートにワーム・プログラムを含むパケットを送り込むと、SQL Serverのコンテキストでプログラムを実行させることができる。

　今回のSQL Slammerワームは400bytes弱の小さなプログラムであり、1度感染するとすぐに活動を開始する。具体的には、ランダムなIPアドレスに向けて、自己のワーム・コードを含む感染パケットを送信し始める。以前のCodeRedやNimdaと違い、送信する量には制限を設けていないようだ。CPUさえ速ければネットワークの帯域いっぱいまでパケットを送信することができるので（例えば100Mbpsならば1秒間に1万パケット以上）、ブロードバンド接続が一般化した現在では、非常に多くのパケットがネットワーク上を行き交うことになる。あて先IPアドレスは完全にランダムなので、これがネットワークの帯域を消費しきるだけでなく、あて先不明のパケットが大量に生成されてルータなどに過負荷を与えたり、たとえどこかのホストへ到達したとしても、（SQL Serverを実行していないほとんどのマシンでは）あて先ポートが利用できないのでエラーとなって戻ってきたりする（ファイアウォールなどでブロックしていない限り、あて先ポートがない場合は、ICMPのエラー・メッセージが戻ってくるようになっていることが多い）。これらの大量のパケットにより、ネットワークが混雑して応答速度が遅くなったり、ルータなどの機器が過負荷でダウンしたりした。

　このワームは、ファイルやシステムを壊すわけではなく、単にオンメモリで感染して活動するだけなので、システムを再起動すれば消滅するし、再起動後に新たに活動を開始することもない。しかしパケットを受け取るとまた感染するので、根本的に解決するには、SQL Serverそのものをアンインストールして使用を停止するか、脆弱性をふさぐためのパッチやサービスパックを適用するしかない（SQL Serverが停止していれば感染しない）。もちろん、ファイアウォールでインターネットからのUDPの1434番への通信をブロックするという対策も必要であるが、もしこのポートを公開していたとすると、そのこと自体がすでに間違いであろう。SQLサービス（の管理用ポート）をインターネットに向けて直接公開する必要などないからだ。

　今回の事例を見ても分かるように、感染したSQL Serverの数は少なくなかった。これらのコンピュータがどうやって感染したかは今後の分析などを待つ必要があるが、インターネットから直接感染したと考えるのが自然だろう。SQL ServerやMSDE 2000は、何も基幹業務システムだけでなく、Visual StudioやOffice製品（Visioなど）のほか、各種グループウェアや会計ソフトウェア、システム・ツールなど、さまざまなサードパーティ製のソフトウェアでもデータベース・エンジンとして使用されている。そのためユーザーがSQL ServerやMSDEを使っていると認識していなくても、感染する可能性は十分ある。今回は、そのような製品からも感染が広まったと思われる。また、現在ではブロードバンド接続が普及しているが、ダイヤルアップ・モデムと同じような感覚で、ファイアウォールなしでDSLモデムなどをシステムに接続しているユーザーも多いだろう。常時接続が普及し、感染の可能性のあるSQL Serverが増えたことも被害が大きくなった要因と考えられる。

SQL Serverの脆弱性のチェック

　SQL Serverに脆弱性が含まれているかどうかは、「解決サービス」を提供しているモジュール（ssnetlib.dll）の日付を確認するしかない。「SQL Server 2000 解決サービスのバッファのオーバーランにより、コードが実行される (Q323875) (MS02-039)」で提供されている新しいモジュールの日付になっているかどうかを確認する。

　これ以外の方法として、eEye Digital Security社から無償で提供されている「Retina Sapphire SQL Worm Scanner」というツールを使って、ネットワーク内をスキャンするという方法もある。

Retina Sapphire SQL Worm Scanner

ネットワーク経由でLAN上のコンピュータをスキャンし、SQLに脆弱性があるかどうかを報告するツール。eEye Digital Security社から無償で提供されている（詳細はこちら）。探索するIPアドレスを指定して、［Scan］ボタンを押すと、SQLに接続し、脆弱性があるかどうかを調べて報告してくれる。ここでは3台のコンピュータが報告されている。

開始IPアドレスとスキャンする台数。 　 スキャンを開始するにはこれをクリックする。 　 脆弱性が見つかったコンピュータ。

SQL Slammer対策

　このワームは、SQL Server 2000およびMSDE（SQL Server 2000 Desktop Engine）に存在する脆弱性をターゲットとしている。この脆弱性はすでに昨年の時点で「SQL Server 2000 解決サービスのバッファのオーバーランにより、コードが実行される (Q323875) (MS02-039)」として発表され、これを修正するHotFixもリリースされているので、これをインストールすれば再感染を防ぐことができる。ただしこれを適用するためには、SQL ServerにSP2を適用していないといけない。また、その後に発表されているSQL用の累積パッチ（「SQL Server Web タスクで権限が昇格する (Q316333) (MS02-061)」）もしくは、Service Pack 3（SP3）をインストールすることによっても対策することができるので、可能ならSP3を適用した方がよいだろう（※MSDE用のSP3は1月27日付けで提供が開始された）。

HotFixはなぜ適用されないのか？

　前述したとおり、今回のSQL Slammerワームの感染は、半年前に提供されたHotFix（MS02-039）か、その後200年10月提供された累積的修正プログラム（MS02-061）、または2003年1月に提供されたSQL Server 2000 SP3のいずれかを適用していれば防止できた。しかし被害が広がったのは、これらの対応を放ったらかしにした管理者の責任だと決め付けるのはあまりに短絡的だ。今回の教訓を生かすには、この背景について考えてみる必要があるだろう。

　今回のHotFix適用が進まなかった背景には、次のような事情があるものと思われる。

■Windows UpdateおよびSoftware Update ServicesはSQL Serverには非対応
　マイクロソフトは、HotFixなどの配布と適用を進めるために、Windows Updateというインターネット・サービスを提供している。これは自動更新機能も持っており、インターネットに常時接続しているコンピュータなら、適用が必要な新しいHotFixが提供されると、修正プログラムが自動的にダウンロードされ、ユーザーが許可すればインストールが開始される（この自動更新機能に加え、通常のWebページによるダンロード・サービスもある）。

　このWindows Updateの自動更新を利用するには、個々のユーザーが自分のコンピュータに対する管理者権限を持つ必要がある。しかし企業の管理者は、このような構成を望まないことが多い。これに対しマイクロソフトが無償提供しているものがSoftware Update Services（SUS）である。これは、Windows Updateのしくみをベースに企業向けに改変したもので、社内に設置したSUSサーバに対し、グループ・ポリシーを使って各クライアントからHotFixをダウンロードさせ、適用させる。

　一見すると便利な機能なのだが、Windows Updateは主に個人ユーザーを対象としたサービスであり、SQL ServerやExchange Server（メッセージング・システム）などといったサーバ向け製品のHotFixについては対応していない。上記のHotFixは一切表示されない。Windows Updateのしくみを応用したSUSでも、サポートされるHofFixの事情は同じである。従ってWindows UpdateやSUSを利用するだけでは、今回のSQL Slammerの感染を防止できなかった。HotFix情報を別に入手し、必要なHotFixを手作業でダウンロードして適用しなければならなかった。

■HotFixの適用が容易でない
　MS02-039のHotFixをダウンロードして適用してみると分かることだが、このHotFixは必要なファイルがアーカイブされているだけで、簡単なインストール・プログラムなどは提供されておらず、ファイルを解凍して、手作業でファイルをコピーする必要がある。作業は非常に面倒だ。

■セキュリティ情報が分かりにくい
　適用作業がどんなに面倒でも、必要とあらば作業すればよい。しかしSQL Server 2000を明示的にインストールしたのではなく、ほかの製品とともにMSDE 2000をインストールしてこれを使用しているユーザーは、自分がMS02-039の適用対象であることも認識できなかった可能性が高い。例えば編集部では、Visual Studio .NET Enterprise EditionとともにMSDEがインストールできることを確認しているが、くだんのセキュリティ情報には、「Visual Studio .NET」とは一言も書かれていない。よほど注意していなければ、自分に関係するHotFixとは分からないだろう。

■適用時の副作用が心配
　そして今回のHotFixにかぎらず、あらゆるHotFixやService Packに対して、管理者が悩まされるジレンマがここにある。HotFixを適用すると、システム・ファイルが書き換えられる可能性が高く、たとえそれが正しい変更であったとしても、それによって、これまで使えていたプログラムが影響を受けないという保証はない（事実、＠ITのアンケートなどを見ると、HotFixの適用によって、アプリケーションなどが正常に使えなくなったという報告が幾つかあげられている）。HotFixを適用しなければセキュリティ・ホールを放置することになるが、かといってうっかり適用すると、業務に支障が出る不安もぬぐえない。管理者はこのようなジレンマに置かれているわけだ。手間もお金もかかるが、この問題を回避するには、HotFixの適用を判断するためのテスト環境などを用意する必要があるかもしれない。

HotFixマネジメントを見直すべき時期がきた

　今回の一件で明らかになったのは、もはやHotFixマネジメントは、管理者の空き時間に片手間に作業するものではなく、自分のシステムを守るために、れっきとした仕事として位置付けて、管理作業メニューに組み込む必要があるということだ。また必要なら、HotFixの適用によって業務に支障をきたさないように、テスト環境を用意する必要があるかもしれない。

　SQL Slammerは、ネットワーク・トラフィックに及ぼした影響は甚大だったが、ファイルを削除するなどの破壊行為には及ばない単純な作りだった。しかし次のワームは、さらに巧妙に感染を広げ、より深刻にネットワークやシステムに被害を及ぼすかもしれない。こうした未来の被害を防止できるかどうか、ネットワーク管理者の対応が問われている。

「Insider's Eye」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）