virtualization.info 日本語

virtualization.infoによる新しいセキュリティコラムの第2回目だ。本シリーズは実世界における仮想インフラのセキュリティリスクから始まり、先週の第1回は具体的に仮想マシンのテンプレートに関連したリスクについて述べた。
今回の話題は、仮想インフラ管理インターフェースのリスクだ。

仮想化業界で働くセキュリティ専門家の大半にはたった1つだけ悪夢がある。ゲスト・ツー・ホストの悪用だ。
これはつまり、ゲスト仮想マシン（管理権限さえ不要かもしれない）から攻撃を仕掛けてホストシステムを乗っ取ってしまうという、ほとんど魔法に近い攻撃だ。これは今のところ最もおそれられている状況で、あらゆる恐怖を具体化していて、仮想化に対して懐疑的な人々からは「だから言っただろう」的なコメントが相次いでいる。
われわれは既にこのような事件をCloudburstエクスプロイトコードで少なくとも1回は目にしているが、その影響は特定のデスクトップ指向製品に限定されており、大企業では安全が守られ、セキュリティ管理者らは不思議がっている。
このような攻撃は至高の目標であり、技術観点から見た真の問題だと考えられている。研究者らは、極めて高度な攻撃がハードウェアの問題を悪用し、ローレベルの命令セットのセキュリティを無効にしていることを明らかにしている。

しかし、（仮想化セキュリティのスキーマ全体にあることは確かだが）これらの懸念や攻撃はあまりにも誇張されすぎているというのが私見だ。
これまでは、サポートと管理インフラの脆弱性という、仮想化環境にとって最も重要な脅威だと考えられるものを本気で分析した人は皆無に等しかった。
ハイパーバイザーが複雑な部品からなるソフトウェアで、攻撃するのが極めて難しいことはよく知られている。これらは簡単に最小限の内容に抑えることができ（その大半はほんの数千行で書けると言われてきた）、そのほとんどはセキュリティやソフトウェアエンジニアリングの高いスキルを持つ筋金入りのコーダーによって書かれており、やや無名のOS（Nemesis-XENのケースを参照）上で動作する。

どの仮想化ソフトウェアにもこのことが当てはまるわけではないが、うるさいDoS（サービス拒否）の副作用のリスクを負うことなく企業環境で「安全」に使える信頼性の高いエクスプロイトコードを開発するのははもちろんのこと、これらのシステムで脆弱性を見つけるのにもたいていの攻撃者はかなり苦労する。
だが、侵略者たちは強化されたアーキテクチャの弱点につけ込むことが大好きだ。仮想化の場合、管理機能を提供したり、メインではない機能をサポートする部分が弱点になるケースが多い。

仮想化ベンダーがリリースしたセキュリティ勧告を見ると、この主張を裏付ける例がいくつかある。たとえば、VMware ESXはホストシステムの悪用と乗っ取りにつながるリモート攻撃を受けやすい。この脆弱性（2つのバッファオーバーフロー）は、ESXiとESXの両方のOpenwsmanコンポーネントのなかにあり、リモートからコードを実行できるようになり、それに伴いホストやゲストが乗っ取られてしまう（本シリーズではこれについて今後探求していく）。

ハイパーバイザーのベンダー各社が基本サービスのコードの大半を書き直していても、核となる機能については標準技術を利用していることを忘れてはならない。OpenwsmanのバグはNovell SUSEセキュリティチームによって見つかっており、そうでなければ仮想化技術とは関係がない。
つまり、仮想化以外の問題が突然仮想化に特化したセキュリティにとって非常に興味深いものになっているのだ。

だが、まだある。ウェブインターフェースだ。
セキュリティ業界が良く分かっているように、ここ最近はウェブアプリケーションが過去最大の攻撃源となっている。セキュリティがこのように低い原因については諸説あるが、われわれはそれを当然のこととして分析する。多くの（大半の）ウェブアプリケーションはセキュリティ問題の影響を受ける。コードベースを大幅に変えることなく数年前から存在している有名な監査付きアプリケーションもしかりだ。新しい攻撃が開発され（数カ月前のHTTP Parameter Pollutionのことはだれも知らなかった）、既知のアタックベクトルが洗練されているため、かなり安全なウェブアプリケーションでも新しいリスクにさらされる可能性を秘めている。
その上、複雑であるために障害が発生しやすいアプリケーションスタックは攻撃者のメインターゲットになることが多い。アプリケーションサーバをターゲットにしたエクスプロイトコードが増えつつあり、このようなソフトウェアで決定的なバグが発見される間隔は業界平均と比較して極めて短い。

まさにこのような環境にあるのが管理ウェブインターフェースだ。大半の仮想化ベンダーは、仮想マシンの起動やシャットダウンなど、核となる最低限の管理作業を実行できるウェブインターフェースを（仮想化ソリューションのコア部分もしくは外部「プラグイン」、アプライアンス、あるいは同様の成果物として）提供している。
これらのインターフェースは、完全なアプリケーションサーバスタック上で動作するウェブアプリケーションにほかならない。アプリケーションを提供する一部デーモンはすべてもしくは一部をカスタマイズすることができるが、大体の場合は、標準的なウェブとアプリケーションサーバしか目にしない。さらに、ウェブやアプリケーションサーバの運用といった難しい作業を処理するカスタムコードの方が大半の標準ソリューションのなかでもセキュリティが低いとされている点は指摘しておきたい。

では、実世界に存在する侵略者はどこを攻撃してくるのだろうか？おそらく、今のところ最も簡単に餌食になるウェブベースの管理インターフェースや基盤のスタックにある問題を狙ってくるだろう。
大半のベンダー各社が管理ネットワーク上の管理コンソールへのアクセスを制限するようユーザに強く求めていることは確かだが、このベストプラクティスはまだ実際の脅威による裏付けがなく、大部分は無視されている。
残念ながら、先ごろのXENCenterウェブ悪用など、管理インターフェースに対する攻撃は発生頻度が高まっており、企業や組織にとってさらに脅威なのは、これらの大半が古いバージョンにも影響を与える点だ。仮想化ベンダーがすみやかにパッチでTomcatなどのセキュリティの問題に対処しても、アップグレードがテストされ導入される間にも特定の脆弱性が残っている。これまでの経験から、ベンダー各社はウェブベースの管理インターフェースを動かすアプリケーションサーバのセキュリティ修正のリリースまでに、開発者が最初にそれを投入してから5カ月を要している。

これは「現在」において大きな問題なのだろうか？ネットワークからはインターフェースに一切アクセスできないようにすべきなのだろうか？絶対にそうすべきである。
ウェブアプリを狙うゼロデイ攻撃（明らかにされておらず、そのためパッチも用意されていないバグを利用するためコミュニティーに知られていない攻撃） の方がネットワークデーモンを狙った流行遅れのエクスプロイトコードより格段に一般的で、アプリケーションサーバに影響を与えるバグや新しいウェブアプリケーション攻撃テクニックの開示から、動作するエクスプロイトコードが開発されるまでの期間は非常に短い。...

仮想化のユーザは可能性の低い、もしくは極めて複雑な攻撃を心配することは（少なくとも平均的スキルの攻撃者が利用できるようになるまで）やめて、侵略者に悪用されやすいインターフェースの部分に対応していくべきだ。
あと2回ほどエクスプロイトコードが登場すれば、ウェブベースの仮想化管理インターフェースに対応するワームも出てくることだろう。

ラベル: Security