ドイツの研究者であるJuraj Somorovsky氏、Mario Heiderich氏、Meiko Jensen氏、Jörg Schwenk氏、Nils Gruschka氏、Luigi Lo Iacono氏があなたのクラウドはすべて私たちの物 – クラウド管理インターフェイスのセキュリティ分析と題した報告書でAmazon AWSとEucalyptusのセキュリティ脆弱性について説明している。この報告書によれば、Amazon AWSとEucalyptusには攻撃者が被害者のアカウントや関連するデータを完全に制御できてしまう可能性のある脆弱性があった。この報告書はSOAPインターフェイスを利用したXMLシグネチャ攻撃について論じているが、加えて2つのクロスサイトスクリプティングによる、管理画面からのアカウントハッキングの脆弱性についても指摘している。これらの脆弱性は公開される前にAmazonとEucalyptusによって修正されている。
典型的なXMLシグネチャ攻撃では、
オリジナルのSOAPボディ要素を、SOAPセキュリティヘッダー内の新しく追加した偽のラッパー要素に移行します。このとき移行されたボディはまだ識別子属性Id="body"を使ったシグネチャに参照されています。この時点では暗号化されたシグネチャは有効です。ボディ要素自体は変更されていない(位置が変わっただけ)からです。その後、SOAPメッセージのXMLスキーマを適正化するため、攻撃者は移行したSOAPの識別子を変更します(この例ではId="attack")。こうして空のSOAPボディが偽のコンテンツで満たされ、攻撃者が定義した処理は実行できるようになります。シグネチャの検証は成功するからです。
典型的なXMLシグネチャ攻撃でAWSとEucalyptusを攻撃する場合、最低でも2つの方法がある。ひとつは時間制約がある方法だ。この攻撃の前提条件は容易に満たすことが出来る。攻撃者に必要なのは有効な署名あるSOAPリクエストメッセージだけで、これは、AWSの開発者がサポートフォーラムで支援を要求するポストから入手できる。著者らはこのようなセキュリティホールの原因として、SOAPの処理フレームワークでのタスクモジュールの分離を非難する。タスクのモジュラリティのため、同じXMLドキュメントが異なるモジュールの異なる方法で評価され、メッセージ全体の完全性が検査されない。著者らが推奨するのは、
最良の対策はシグネチャ検証の関数とビジネスロジックの間のインターフェイスを強化することです。この方法ではシグネチャを検証した結果として、Boolean値とは別に署名したデータの位置に関する情報が得られます。その後、ビジネスロジック側は処理対象のデータが署名されているかどうか検証します。
また、著者らは2つのスクリプト注入攻撃も明らかにしている。ひとつはAWSマネジメントコンソールのユーザだけが攻撃対象で、もうひとつはAmazonのショップの画面とAWSの間で共有される認証情報の脆弱性を突く。最初の脆弱性はユーザがAmazonが発行するX.509証明書をダウンロードする時に使うリンクのGETパラメータを利用する。しかし、この攻撃を成功させるための条件は比較的難しい。スクリプトを注入してサーバのロジックをバイパスしてHTML標準の文字列をエンコードするためにUTF-7エンコーディングが必要で、かつ、特定のIEのバージョンを使う必要がある。ふたつ目のクロスサイトスクリプティングによる攻撃は、Amazonsのショップ画面に初めてログインした時にAWSで初期化されるログインセッションを攻撃する。これはシンプルで効果的な攻撃だ。
攻撃者は新しい商品やユーザが生成したタグなどの要素についてのディスカッショントピックを作成します。このディスカッショントピックのヘッドラインは正しいエンコーディングでないと拒絶されますが、ここに任意のHTMLコードを注入する余地が生まれます。スクリプトタグや他の有効なマークアップを注入してユーザエージェントがwww.amazon.comドメインでJavaScriptを実行することができてしまうのです。
著者らはAmazonとEucalyptusのセキュリティ担当者と協力し、この報告書が発表される前に問題は修正された。しかし、Eucalyptusやその他のプライベートクラウドの場合、まだ問題が残る。
この脆弱性に対する修正を適用する場合問題なのが、Eucalyptusが様々な公開されたいないサーバに配置されているということです。それゆえ、Eucalyptusの管理者は手動でサーバのバージョンを上げなければなりません。インストールされている環境が多いので(Eucalyptusによれば25,000を超える顧客がいます)、短期間ですべてのサーバに修正が適用されるかどうかは疑問です。これは間違いなくプライベートクラウドインフラの最大の問題点のひとつです。
結論として、著者らはこれらのすべての既存のクラウドに存在する可能性のある脆弱性に対する攻撃の影響範囲について明らかにしている。このような広範囲な影響を与えることから、最低でもサインアップする前に報告書に書かれているような、"ブラックボックス"的手法を採用する必要がある。
このようなシステムの複雑さは潜在的な脆弱性の巨大な温床を作ります。近い将来、クラウドを制御するインターフェイスは組織犯罪の格好の標的になり得ます。私たちが発見した脆弱性の最も恐ろしい点は、これらの脆弱性は単一のサーバや企業だけでなく、クラウドのユーザ全体に影響を与えることです。さらに、クラウド制御インターフェイスに対するクロスサイトスクリプティングはクラウドのセキュリティ全体に大きな影響を及ぼします。