ところで、パッケージアプリのセキュリティは？：川口洋のセキュリティ・プライベート・アイズ（10）

» 2008年12月16日 10時00分公開

　皆さんこんにちは、川口です。先日、会社の裏道を歩いていると、ELEMENTS BARという、とても良い雰囲気のお店を見つけました。気になったのでランチを食べに行ってみたところ、店内はのんびりできる雰囲気で、ご飯もおいしかったです。会社の裏にあるこのお店は以前からあったはずなのに、何もないはずだと思い込んでいてすてきなお店を完全に見落としていました。今回のコラムは、そんな“意外と見落としがち”なことを取り上げます。

注目が集まるWebアプリケーションの脆弱性、でも……

　第8回のコラム「クッキーに隠されたSQLインジェクション、対策は？」にはたくさんのはてなブックマークがつきました。システムごとに個別に開発されているWebアプリケーション（以下、カスタムアプリケーション）のセキュリティに関する注目が集まっていることを実感しました。

　最近ではJSOCで検知しているインシデントもカスタムアプリケーションに対するものが多くなってきており、攻撃者のターゲットがカスタムアプリケーションの脆弱（ぜいじゃく）性に移ってきたといえるでしょう。しかし、攻撃者のターゲットはカスタムアプリケーションに移ったとはいえ、特定の企業や個人が開発、販売しているパッケージアプリケーションの脆弱（ぜいじゃく）性が狙われなくなったわけではありません。

図1　重要インシデントにおけるパッケージアプリケーションの比率（JSOC調べ）

　以下のデータは2006年から2008年の間にJSOCで検知している重要インシデントを、パッケージアプリケーションに関連するものとそうでないものに分類したものです。

　図1によると、重要インシデントの75％の項目はパッケージアプリケーションの脆弱性を狙った攻撃によって発生したものなのです。

　現在も多く攻撃が行われている脆弱性は以下のものです。

ASN .1 の脆弱性により、コードが実行される (828028) (MS04-007)
WINS の脆弱性により、リモートでコードが実行される (870763) (MS04-045)
OpenSSL Client Masterkey Overflowの脆弱性
Symantec Client Security and Symantec AntiVirus Elevation of Privilege
（ほか、さまざまなアプリケーション）

　どれも2006年以前に公開された脆弱性を狙った攻撃ばかりで、本稿執筆時点から見ても相当古い脆弱性といえます。セキュリティ事故が起こる企業に限って、これらの古い脆弱性に対応できていないことが多いのです。

　パッケージアプリケーションの脆弱性といえば、2008年10月にマイクロソフトから緊急のセキュリティ情報が公開された「Server サービスの脆弱性により、リモートでコードが実行される（958644）（MS08-067）」が記憶に新しいでしょう。この脆弱性を狙うためには445/tcpにアクセスする必要がありますが、インターネットからこの脆弱性を狙った攻撃はほとんど発生していません。これはBlasterワーム以降、ほとんどの企業ではインターネットから社内LANに対する445/tcpへのアクセスをファイアウォールで遮断しているためです。

【関連記事】

川口洋のセキュリティ・プライベート・アイズ（7）
夏が来れば思い出す……
http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/007.html

　しかし、どこの経路からかボットに感染したパソコンが社内のネットワークに対して感染活動を繰り返し、大規模な感染事故も数件発生しています。ひとたび社内にボットが入り込むと、この脆弱性を狙って社内のすべてのパソコンに感染する恐れがあります。まだパッチを適用していない企業はいまのうちにパッチを適用しましょう。

パッケージアプリケーションの脆弱性を狙った攻撃の現状

　攻撃者側の事情を考えてみましょう。攻撃者がパッケージアプリケーションの脆弱性を狙うためには、脆弱性があるサーバを調査する必要があります。例えば、0.01％の確率で脆弱性があるサーバが稼働している場合、100万台のサーバを調査することができれば100台のサーバを攻略できることになります。攻撃者は脆弱性を調査・攻撃する活動を自動化することで世界中の公開サーバを攻撃の対象としています。特にボットには自動化された機能が実装されているため、攻撃者にとってはお手軽に世界中のサーバに対して攻撃することが可能なのです。

　特定のサーバに侵入したい攻撃者以外にとっては、脆弱性があるサーバに侵入できれば、どこのサーバでもよいわけです。管理者が普段から脆弱性に迅速に対応していたとしても、たった1台のサーバにパッチを適用していなかったばかりに攻撃者に侵入されてしまうのです。常に脆弱性がない状態に保たなければならないサーバ管理者側としては非常に不利な戦いです。

攻撃者から見るパッケージアプリケーションの“特徴”

　攻撃者にとって、パッケージアプリケーションには好都合な事情があります。それは脆弱性の潜在性に関係しています。

　パッケージアプリケーションはある時点において脆弱性に対応するパッチを適用したとしても、再び脆弱性が報告されることが珍しくありません。せっかくパッチを適用した直後に新しい脆弱性情報が公開されて、やるせない思いをした方も多いでしょう。そして対応が遅れれば遅れるだけ、攻撃者に侵入する時間を与えてしまいます。管理者はいつ出るとも分からないパッケージアプリケーションの脆弱性情報を常に追い続ける必要があるのです。

　逆にカスタムアプリケーションはセキュリティ診断を実施し、脆弱性を修正した後は、アプリケーションの修正が行われない限り新しい脆弱性が発見されることは（若干の例外もありますが）ほとんどありません。つまり脆弱性診断を実施する頻度はパッケージアプリケーションとカスタムアプリケーションで大きく異なるということです。カスタムアプリケーションは開発、修正の都度セキュリティ診断を実施すべきですが、パッケージアプリケーションは脆弱性の公開のたびにセキュリティ診断を実施し、脆弱性が存在しないことを確認するべきです。

では、対策はどうするべきなのか？

　パッケージアプリケーションの脆弱性に対応するためには「脆弱性情報の収集」と「脆弱性診断」が必要です。

　脆弱性情報の収集にはJVNが便利です。JVNはJPCERT コーディネーションセンターと情報処理推進機構（IPA）が共同で運営している脆弱性関連情報とその対策情報を提供している日本語のポータルサイトです。Blasterワームが流行した5年前と比べ、このような日本語の情報が手に入りやすくなっており、各関係機関の取り組みに感謝しています。

　ただし、JVNもすべてのアプリケーションに対応しているとは限りません。マイナーなアプリケーションや日本で使われていないアプリケーションについては対応されないケースもあるでしょう。システムの担当者はJVNに加えて、システムで使用しているパッケージアプリケーションの開発ベンダの公式サイトを毎日確認するようにし、漏れがないように心掛けましょう。

　システムに存在する脆弱性を確認するためにはセキュリティ診断を実施することが有効です。市場にはセキュリティ診断のための製品・サービスがあり、多くの企業ではセキュリティ診断を実施していることでしょう。以下はJSOCのお客さまが、セキュリティ診断を実施した回数を示しています。

図2　半期ごとのセキュリティ診断の実施回数推移（JSOC調べ）

　図2をご覧になると分かるように、2007年下半期と比較し、2008 年上半期はセキュリティ診断が実施された回数が約30％増加しています。これはお客さまのセキュリティ意識が高まり、セキュリティ診断の重要性が認知されてきたものと考えます。しかし、セキュリティ診断が実施されるようになったといっても、ほとんどの企業が1年に1回の実施ぐらいです。つまりセキュリティ診断直後に発生した脆弱性にはほぼ1年間、その存在を認知できない可能性があるということです。

　定常的な脆弱性情報の収集およびパッチ適用作業から漏れてしまった脆弱性は存在そのものに気付くことができなくなってしまいます。自動化された攻撃からシステムを守るためには攻撃者に負けないスピードで脆弱性に対応する必要があります。潜在的な脆弱性をなくすために、脆弱性に関する情報を定常的に収集し、確認することが必要です。また、定期的または継続的な脆弱性診断を行うことも効果的でしょう。

　――とはいうものの、それが簡単にできないのが難しいところ。毎日、多数のセキュリティインシデントと戦うセキュリティアナリストとしては、せめてWindows Updateだけは毎月実行してほしいと願っています。残念ながら、Windows Updateの実行すらできていない環境も多くあります。風邪を引かない（ボットに感染しない）ために体を鍛えて（Windows Updateして）ほしいと願う毎日です。

　今回はなにげなく見つけたお店で1人ランチを食べていたときに思い浮かんだテーマを取り上げてみました。クローズアップされることが少なくなったパッケージアプリケーションの脆弱性対応が意外に抜け落ちていることで被害に遭うことについて警鐘を鳴らしたかったのです。

　最近、私は日本セキュリティオペレーション事業者協議会（Information Security Operation provider Group Japan、略称：ISOG-J）のセキュリティオペレーション技術ワーキンググループのリーダーをしています。技術ワーキンググループではセキュリティオペレーションにかかわる技術者の技術力の向上を目的としています。セキュリティオペレーションといってもかかわっている人の仕事の内容はさまざまであり、抱えている課題も違います。それぞれのセキュリティオペレーションの現場で奮闘している技術者の課題を解決し、技術力を向上していくことが日本のセキュリティシーンの未来のために必要です。

　それには、まずお互いの事情を理解しあうことが必要です。私はセキュリティオペレーション技術ワーキンググループのリーダーとして、日本のセキュリティシーンの未来のため、ワーキンググループメンバーと交流すべく今夜も飲みに行くのでした。