Gumblarがあぶり出す 「空虚なセキュリティ対策」：川口洋のセキュリティ・プライベート・アイズ（23）

　皆さんこんにちは、川口です。先日、私はインターネット協会主催の「現在の日本のセキュリティ〜ブラックハットジャパンその後〜」にて、有名なセキュリティ会社社長3人に囲まれ、パネリストとしてお話をさせていただきました。議題は「セキュリティ屋の使命」「PtoP」「人材」「Gumblar」です。このコラムの読者の方が何人も参加していたり、2年前のBlack Hat Japanでお会いした方に再会したり、貴重な経験をすることができました。

ブラックハットジャパン、その後

　2008年、Black Hat Japanでお話しさせていただいたころと比べて、セキュリティインシデントの傾向は大きく変化しています。ちょうどあのころはSQLインジェクションが増加し続けている中、新しい攻撃手法が次々と登場した時期でした。特に2008年12月にSQLインジェクション攻撃が急増したときは、このまま攻撃が増加し続ければ、われわれJSOCではさばききれないのではないかと本気で心配したものでした。

　さて、現在のSQLインジェクションの攻撃状況はどうでしょうか。JSOCで検知しているSQLインジェクションの傾向は以下の通りです。

SQLインジェクション攻撃検知数（2009年12月まで） | LAC via kwout

　2008年12月に急増したSQLインジェクションは、2009年2月を境に減少しています。これはこの時期に攻撃を行っていたボットが1月30日に停止するようにプログラミングされており、多くのボットが2月以降は攻撃を停止したためです。このときは攻撃が減少してくれてほっとした記憶があります。

　その後の攻撃件数は2008年前半と同じ程度で推移しています。いまもSQLインジェクションは継続的に行われていますが、特に目新しいトピックはありません。2009年以降のウェブサービスに対する攻撃としては、SQLインジェクションより「Tomcat」「phpMyAdmin」「Zen Cart」への攻撃が注目を集めました。

　いずれも件数は少ないながらも被害が発生していますが、2009年に最も注目を集めたのは「Gumblar」（ガンブラー）でしょう。

　2008年は「組織の正面玄関」であるWebサイトの欠陥を突かれて改ざんされていましたが、2009年からは「組織の裏口」である管理者用アカウントを悪用されて改ざんされるようになりました。そのため、2009年はお客様から「SQLインジェクションって最近どうなの？」と聞かれるより「最近GENOウイルスどうですか？」「Gumblarはどのくらい流行してますか？」と質問される機会が多くなりました。

図1　2008年〜2010年、脅威の変遷

　2010年、大手サイトの改ざん事件の報道が行われたこともあり、Gumblarは一気に世間の注目を集め、新聞やテレビで取り上げられる機会が増えました。新聞やテレビで取り上げられるようになるとお客様の組織で「うちは大丈夫なのか？」と、“上層部の偉い人”が騒ぎだす傾向があります。その結果、お客様はWebサイトの外部委託先の管理に奔走したり、慌ててFTPサーバのログを確認したりすることになります。

あぶり出される組織の問題

　このとき、あぶり出されてくるのは「組織のセキュリティ対策」への考え方です。

　言葉は悪いですが、お客様からは「建前のセキュリティ対策」をたくさん検討した結果、「簡単に『Gumblar対策しています』と説明したい」という雰囲気がありありと伝わってきます。顕著な例として、改ざん事件が相次ぐと、ファイルの改ざん検知システムを導入する組織がでてきます。Webサーバ上のファイルの改ざんをチェックすること自体はよいのですが、導入後3カ月くらいすると、まともに運用されなくなる組織もあります。「運用」が必要な対策を「建前」のセキュリティ対策として導入するから、「現場の運用」になじまないのです。そして、せっかく導入した仕組みが形骸化してしまう結果になります。

　組織の構造が問題になることもあります。Gumblarに対しては「Webサイト更新用端末の対策」と「FTPサーバ側の対策」が可能です。これに加えて「ネットワーク側での対策」も行うことができます。大きな組織の中ではこれらの対策を行う部門が分かれています。さらにそれぞれの部門が外部のシステムインテグレーション業者やネットワークインテグレーション業者、セキュリティベンダと契約してシステムを構築、運用しています。

　単体の攻撃であれば、その部門の中で外部の企業と協力して対策をすることで対応できました。しかし、Gumblarのように「脆弱性があるポイント」と「改ざんされるポイント」が異なる攻撃には、単一の対策ポイントでは対応することができません。外部の企業は基本的に「契約の範囲の中」で対応できることを検討しますが、それが全体最適になっているとは限りません。本来はサーバ側で対応するべきことが、ネットワーク側で強引な対応していることもあります。

　この場合、サーバ担当の企業の運用状況を知らないネットワーク担当の企業は、その対策をお客様に提言することもできません。この場合は、システムを保持する企業が主体的に対策のバランスを考えて実行する能力が求められます

　また、会社間の関係も問題になります。今回改ざん事件が報道された多くの企業では、Webサイトの運用を外部委託していたものと思われます。同様にWebサイトの運用を外部委託している企業は、今回の相次ぐ改ざん事件の報道を受けて、委託先企業のセキュリティ対策状況を確認していることでしょう。このこと自体は問題はありませんが、自社のセキュリティ対策をそのまま委託先企業に求めてはいないでしょうか。

　委託を受ける条件として、委託元企業のセキュリティ基準を満たすことが含まれている場合もありますが、果たしてそれは実行可能な基準でしょうか。Webサイトの運用を委託されている企業自体は大きな組織かもしれませんが、その委託先としては中小のデザイナー事務所が請け負っている場合場合もあります。実施できないセキュリティ対策を求めた結果、その対策が形骸化された状態になっていないか心配です。

　Webサイトの開発者としては、Gumblarの被害に遭わないよう開発を行うことは当然ですが、Webサイトの運用者はそのポイントだけに依存してはいけません。開発者がGumblarに感染する可能性があるものと想定し、FTPサーバのセキュリティ対策も行う必要があります。

重要なのは現場へのフィッティング

　セキュリティインシデントの対策の話になると「すべてのパッチを適用すること」「許可したIPアドレスからのみ接続可能にすること」「不正な動作の監視をすること」など「正論」のセキュリティ対策が列挙されます。対策を記述する側としては、対策を実行する側の環境をすべて把握することができない以上、このような書き方になってしまうのは仕方ありません。

　しかし、私はこれらの「正論」のセキュリティ対策ができない環境をたくさん見てきました。「業務アプリケーションの都合でアップデートできない」「予算がないから、アップデートできない」「セキュリティシステムを運用できる人がいない」などなど。われわれセキュリティ屋が「正論」のセキュリティ対策を語れるのは当然ですが、それをどのようにビジネスの現場、ITの現場に落とし込んでいくかを考えなければなりません。

　それにはセキュリティ屋だけではなく、そのほかのさまざまな関係者と一緒に頭を使って、汗をかく必要があります。そのためにも、セキュリティ屋とビジネスの現場の相互理解が必要です。

　私はビジネスの現場のセキュリティのあり方を語るために、今夜も飲みに行くのでした。