| ＠IT > Security&Trust > 事例から学ぶWebサイトの脆弱点とその対応 |
 特集 インターネットセキュリティシステムズ テクニカルサポート部 2002/3/30 ブローダバンド化が進み、インターネット上に企業・個人事業ともに自社のサイトを展開している場合が多い。しかし一方で、その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はCD Universeが使用していたアプリケーション上のセキュリティ問題を利用した。そこには通常われわれが目にすることのないアプリケーション上のセキュリティ問題が関係していたとされる。 Maxusは実際の侵入手口を公開することはしていないが、CyberCashはSETファイルに重要な情報をプレーンテキストで残していることと、マイクロソフト製品のセキュリティ上の脆弱点により容易にMDBファイルを参照できたと主張している。 CD Universeのシステム構成は、クレジットカードのトランザクション処理を行うCyberCashのICVerifyとSQL Serverを使用していたとされている。しかし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サーバを攻撃できるといっても、しょせん手動での攻撃だった。しかしこれらのワームは、無差別に自動的に攻撃するところが、それまでのWeb改ざん事件とは大きく異なっている。 そして従来とは最も大きく異なり、インターネットコミュニティに対する脅威となった点が、本当に“対象が無差別”になったことである。いままではたとえセキュリティ対策を怠っていたとしても、「うちの組織は目立たないから大丈夫」などとうそぶくことができた。しかしこれらのワームが、全世界すべてのWebサーバやホストが攻撃対象であることを宣言してしまったのである。
●sadmind/IISワームによる攻撃
の手法で攻撃を行う。このワームの特徴としては、SolarisをIIS攻撃の踏み台として利用することであり、広範囲な攻撃を可能としている。 sadmind/IISの攻撃対象になったSolarisはroot権限を奪取される、IISは任意のプログラムを実行されるという脆弱点がそれぞれに存在するため、新たな攻撃を受ける危険性が高い。 ●Code Redワームによる攻撃 2001年7月にCERT勧告が発行されたこのワームは、sadmind/IISとは異なり、IISからIISに広がるワームであり、さらにホワイトハウスのサイトに対するDoS攻撃機能まで組み込まれたものとして有名になった。その感染過程は、
というものである。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より勧告が出されたワームで、その被害の大きさは記憶に新しいところだと思う。それまでのワームと決定的に異なる点は、現在取り得るさまざまな脆弱点を駆使して感染することである。その感染形態は下記のようにいくつか存在する。
電子メールによる感染は、それまでのウイルスがOutlookもしくはOutlook Expressを悪用した感染方法とまったく同じである。しかしそれ以外の方法は、Nimda自身が脆弱点やバックドアをスキャンし、感染を広げていくものである。特にWebページに感染スクリプトを埋め込む点はユニークなものだ。埋め込まれるスクリプトは下記のようなものである。
window.openメソッドでオープンしているreadme.emlが、Nimda自身である。readme.emlをオープンしてしまうとNimdaに感染してしまう。 Nimdaに感染したPCは脆弱なIISを探すため、大量のHTTP GET要求を生成し始める。そのためネットワークによってはバンド幅がNimdaによって消費尽くされてしまい、ほかのサービスが実行不可能なDoS状態に陥ってしまうことがある。 攻撃されたIISのアクセスログには下記のようなHTTP GET要求が記録される。
5行目以下がIISの脆弱点に対する攻撃用HTTP GET要求、4行目まではバックドアに対するアクセスである。これらの結果エラーが発生しなければ脆弱点が存在するものとしてその後の攻撃を継続する。 ●ウイルスとワームの違い ウイルスが感染に使用する手法は、あくまで“受動的”なものであり、メールを不用意に開くなど何らかの人間の操作が必要となる。しかしワームは“能動的”に他者に対して攻撃を仕掛け、自分自身を感染させていく。Nimdaはウイルス的な感染ルートとワーム的な感染ルートの両方を持ったもので、その意味でワームとウイルスの垣根を取り払ってしまったものであった。
インターネット上に直接SQL Serverサービスをオープンしているケースは非常にまれであると想像されるが、まったくないとは断言できない。筆者の知る限り、該当するFTPサーバとIRCサーバが迅速に閉鎖されたこともあり、実害はほとんど出ていないようである。 ●法的責任を問われることにもなりかねない Web改ざん事件の場合、一般的な意識としては、“顔に泥を塗られた”もしくは“野良犬にかまれた”程度の印象にとどまるのではないだろうか。しかしCD Universeのように、顧客の大切なクレジットカード情報が盗難されたうえに、その事実をきちんと告知しなかった場合、信用の失墜という事態が起こることは目に見えている。 事実「もうCD Universeでは買い物はしない」といっている顧客もいた。今回のケースでは幸運にもCD Universeが閉鎖するまでには至らなかったが、顧客から訴訟を起こされる危険性もあった。では盗まれた情報に、クレジットカード情報だけではなく、個人の疾病履歴など多くの情報が含まれていた場合はどうなってしまっただろうか。米国の場合、情報の保護義務に関する法律が存在し、保護義務の対象となる情報が漏えいした場合、義務を怠ったとしてその企業が法的責任を問われることになる。おそらく集団訴訟を起こされ、企業の存続が成り立たなくなってしまう危険性がさらに高くなる。
ではWebサイトを運営するに当たり、セキュリティ上の問題をどのようにとらえるべきなのか、ここで考えてみよう。最悪のリスクといえば、先ほど挙げた保護責任があるような重要な情報を預かり、それが盗まれたことによって発生する訴訟や法的責任の追及などにより、企業の存続が脅かされることである。つまり預かっている情報は何としてでも保護しなければならない。 盗まれないようにするか、あるいは万が一盗まれたとしても暗号化などにより再利用を不可能にしなければならない。つまりWebサイトの究極のセキュリティポリシーは、“預かっている情報は死守する”である。これが守られない場合、企業の存続を脅かす危険性が発生することになる。 ●Webサイトが攻撃される構造的な問題
の大きく分けて3つのサーバ機能を使用する、n層クライアントサーバの構成を取ることが非常に多い。 これらの各要素に存在するセキュリティ上の脆弱点により、過去ネットワークの奥深くにあり、外部からは手が出せないと思われていたデータベースに対してまで侵入が可能になってしまっている。なぜ可能なのか？ それはシステム自体に、Webサーバ、アプリケーションサーバ、データベースサーバの順番で到達する正規のパスが必ず存在し、そのパスはファイアウォールでもブロックされていないからだ。 そして、攻撃者は下記のようなステップで、データベースサーバに到達する。
しかもこれらの攻撃はファイアウォールをスルーするHTTPなどを利用して行うことも可能であるため、何もしなければ防御する手立てがない。 もしそれぞれのサーバが脆弱であれば、攻撃されっぱなしの状態になってしまう。いずれのサーバも人間が開発した単なるソフトウェアである。残念なことにそれぞれにセキュリティ上の脆弱点が必ず存在するといっても過言ではない（少なくとも現状は）。 アプリケーションサーバの場合、サーバ自体というよりもそこで実行されるWebアプリケーションそのものにおいて、構成方法や使用する技術において、脆弱点自体が変わってしまう。いい換えれば、わざわざ脆弱なアプリケーションを作ることも可能なのである。 データベースには、本来“死守すべき預かり情報”が存在しているため、データベースへの侵入が発生しないようにシステムを構築する必要がある。そうしなければ“預かり情報は死守する”ことができない。 では“預かり情報を死守する”ために、各サーバやWebアプリケーションに存在する脆弱点を取り上げ、それらを踏まえたうえでの必要なシステム構築の考え方や、その手法について説明する。
|
 |
|||||||||||||||||||||||||||||
