MCSクラウドプラットフォームのセキュリティ監査

スカイシップの夕暮れ アーティスト: SeerLight

どのようなサービスを構築する場合でも、セキュリティに対する継続的な取り組みが必ず含まれます。 セキュリティは、製品セキュリティの継続的な分析と改善、脆弱性に関するニュースの監視などを含む継続的なプロセスです。 監査も含めて。 監査は社内と外部の専門家によって実行されます。専門家はプロジェクトに没頭しておらず、広い心を持っているため、セキュリティを徹底的に支援できます。

この記事は、Mail.ru クラウド ソリューション (MCS) チームのクラウド サービスのテストを支援した外部専門家の最も率直な見解と、彼らが発見した内容について説明しています。 MCSは「外部勢力」として、情報セキュリティ分野で高い専門知識を持つデジタルセキュリティ社を選んだ。 そしてこの記事では、独自のクラウド サービスを作成するときに同じ被害を避けるために、外部監査の一環として見つかったいくつかの興味深い脆弱性を分析します。

Описаниепродукта

Mail.ru クラウド ソリューション (MCS) クラウド上に仮想インフラを構築するためのプラットフォームです。 これには、IaaS、PaaS、および開発者向けの既製のアプリケーション イメージのマーケットプレイスが含まれます。 MCS アーキテクチャを考慮すると、次の領域で製品の安全性を確認する必要がありました。

• 仮想化環境のインフラストラクチャの保護: ハイパーバイザー、ルーティング、ファイアウォール。
• 顧客の仮想インフラストラクチャの保護: SDN のネットワーク、プライベート ネットワークを含む相互の分離。
• OpenStack とそのオープン コンポーネント。
• 当社独自の設計のS3。
• IAM: ロールモデルを備えたマルチテナント プロジェクト。
• ビジョン (コンピューター ビジョン): 画像を操作する場合の API と脆弱性。
• Web インターフェースと古典的な Web 攻撃。
• PaaS コンポーネントの脆弱性。
• すべてのコンポーネントの API。

おそらくこれは、さらなる歴史にとって重要なことのすべてです。

どのような作業が行われ、なぜそれが必要だったのでしょうか?

セキュリティ監査は、個人データの漏洩、機密情報の変更、サービスの可用性の中断につながる可能性のある脆弱性や構成エラーを特定することを目的としています。

平均 1 ～ 2 か月かかるこの作業中、監査人は潜在的な攻撃者の行動を繰り返し、選択したサービスのクライアント部分とサーバー部分の脆弱性を探します。 MCS クラウド プラットフォームの監査の観点から、次の目標が特定されました。

1. サービスにおける認証の分析。 このコンポーネントの脆弱性は、他の人のアカウントに即座に侵入するのに役立ちます。
2. 異なるアカウント間のロールモデルとアクセス制御を研究しています。 攻撃者にとって、他人の仮想マシンにアクセスできることは望ましい目標です。
3. クライアント側の脆弱性。 XSS/CSRF/CRLF/など悪意のあるリンクを通じて他のユーザーを攻撃することは可能ですか?
4. サーバー側の脆弱性: RCE およびあらゆる種類のインジェクション (SQL/XXE/SSRF など)。 サーバーの脆弱性は一般に発見するのがより困難ですが、一度に多くのユーザーの侵害につながります。
5. ネットワークレベルでのユーザーセグメント分離の分析。 攻撃者にとって、分離が欠けていると、他のユーザーに対する攻撃対象領域が大幅に増加します。
6. ビジネスロジック分析。 企業を騙して無料で仮想マシンを作成することは可能でしょうか?

このプロジェクトでは、作業は「グレーボックス」モデルに従って実行されました。監査人は一般ユーザーの権限でサービスと対話しましたが、API のソースコードを部分的に所有し、開発者と詳細を明確にする機会がありました。 これは通常、最も便利であると同時に、非常に現実的な作業モデルです。内部情報は依然として攻撃者によって収集される可能性があり、それは時間の問題です。

見つかった脆弱性

監査人がさまざまなペイロード (攻撃の実行に使用されるペイロード) をランダムな場所に送信し始める前に、物事がどのように機能し、どのような機能が提供されるかを理解する必要があります。 調査対象の場所のほとんどには脆弱性がないため、これは無駄な作業であると思われるかもしれません。 ただし、アプリケーションの構造とその動作ロジックを理解することによってのみ、最も複雑な攻撃ベクトルを見つけることが可能になります。

怪しいと思われる場所、または何らかの点で他の場所と大きく異なる場所を見つけることが重要です。 こうして最初の危険な脆弱性が発見されました。

アイドル

IDOR (Insecure Direct Object Reference) 脆弱性は、ビジネス ロジックで最も一般的な脆弱性の XNUMX つであり、実際にはアクセスが許可されていないオブジェクトに誰かがアクセスできるようになります。 IDOR の脆弱性により、さまざまなレベルの重要度のユーザーに関する情報が取得される可能性が生じます。

IDOR オプションの XNUMX つは、システム オブジェクト (ユーザー、銀行口座、ショッピング カート内の商品) へのアクセス識別子を操作することによって、これらのオブジェクトに対するアクションを実行することです。 これは最も予測不可能な結果を​​もたらします。 たとえば、資金の送信者のアカウントを置き換える可能性があり、これを通じて他のユーザーから資金を盗むことができます。

MCS の場合、監査人は安全でない識別子に関連する IDOR 脆弱性を発見したところです。 ユーザーの個人アカウントでは、オブジェクトへのアクセスに UUID 識別子が使用されていましたが、セキュリティ専門家が言うように、これは非常に安全ではない (つまり、ブルート フォース攻撃から保護されている) ように見えました。 しかし、特定のエンティティでは、アプリケーションのユーザーに関する情報を取得するために通常の予測可能な数値が使用されていることが判明しました。 ユーザー ID を XNUMX つ変更して再度リクエストを送信することで、ACL (アクセス制御リスト、プロセスとユーザーのデータ アクセス ルール) を回避して情報を取得できたことが推測できると思います。

サーバー側要求偽造（SSRF）

オープンソース製品の良い点は、発生する問題の詳細な技術的説明と、運が良ければ解決策の説明を備えた膨大な数のフォーラムがあることです。 しかし、このコインには裏返しがあり、既知の脆弱性も詳細に説明されています。 たとえば、OpenStack フォーラムには脆弱性に関する素晴らしい説明があります。 [XSS] и [SSRF]、何らかの理由で誰も修正を急いでいません。

アプリケーションの一般的な機能は、ユーザーがサーバーにリンクを送信し、サーバーがクリックする機能です (たとえば、指定されたソースから画像をダウンロードする)。 セキュリティ ツールがリンク自体、またはサーバーからユーザーに返される応答をフィルタリングしない場合、そのような機能は攻撃者によって簡単に使用される可能性があります。

SSRF の脆弱性は、攻撃の開発を大幅に進める可能性があります。 攻撃者は以下を取得する可能性があります。

• 攻撃されたローカル ネットワークへのアクセスが制限されます。たとえば、特定のネットワーク セグメント経由でのみ、特定のプロトコルを使用します。
• アプリケーション レベルからトランスポート レベルへのダウングレードが可能な場合は、ローカル ネットワークへの完全なアクセスが可能になり、その結果、アプリケーション レベルでの完全な負荷管理が可能になります。
• サーバー上のローカル ファイルを読み取るためのアクセス (file:/// スキームがサポートされている場合)。
• имногоедругое。

OpenStack では SSRF 脆弱性が以前から知られていましたが、これは本質的に「ブラインド」です。サーバーに接続しても、サーバーからの応答は受信されませんが、リクエストの結果に応じて、さまざまな種類のエラー/遅延が発生します。 。 これに基づいて、内部ネットワーク上のホストでポート スキャンを実行できますが、その後のすべての結果を過小評価してはなりません。 たとえば、製品には企業ネットワークからのみアクセスできるバックオフィス API が含まれている場合があります。 ドキュメントがあれば (内部関係者のことを忘れないでください)、攻撃者は SSRF を使用して内部メソッドにアクセスできます。 たとえば、何らかの方法で有用な URL のおおよそのリストを取得できた場合、SSRF を使用すると、それらを参照してリクエストを実行できます。比較的言えば、アカウントからアカウントへの送金や制限の変更などです。

OpenStack で SSRF の脆弱性が発見されたのはこれが初めてではありません。 以前は、VM ISO イメージを直接リンクからダウンロードすることができましたが、これも同様の結果を引き起こしていました。 この機能は現在 OpenStack から削除されています。 どうやらコミュニティでは、これが問題に対する最も簡単で信頼できる解決策であると考えられていました。

とで これ HackerOne サービス (h1) から公開されているレポートによると、インスタンスのメタデータを読み取る機能を備えたブラインドではなくなった SSRF の悪用により、Shopify インフラストラクチャ全体への Root アクセスが可能になります。

MCS では、同様の機能を持つ XNUMX か所で SSRF 脆弱性が発見されましたが、ファイアウォールやその他の保護により悪用することはほとんど不可能でした。 いずれにせよ、MCS チームはコミュニティを待たずにこの問題を解決しました。

シェルをロードする代わりに XSS

何百もの研究が書かれているにもかかわらず、毎年 XSS (クロスサイト スクリプティング) 攻撃が最も多く発生しています。 よく遭遇する Web の脆弱性 (または 攻撃？）。

ファイルのアップロードは、セキュリティ研究者にとってお気に入りの場所です。 任意のスクリプト (asp/jsp/php) をロードして、ペンテスターの用語で「ロード シェル」と呼ばれる OS コマンドを実行できることがよくわかります。 しかし、このような脆弱性の人気は両方向に作用しており、それらは記憶され、それに対する救済策が開発されているため、最近では「シェルが読み込まれる」可能性はゼロになる傾向にあります。

攻撃チーム (デジタル セキュリティが代表) は幸運でした。 OK、サーバー側の MCS では、ダウンロードされたファイルの内容がチェックされ、画像のみが許可されました。 しかし、SVG も画像です。 SVG 画像はどのように危険なのでしょうか? JavaScript スニペットを埋め込むことができるからです。

ダウンロードされたファイルは MCS サービスのすべてのユーザーが利用できることが判明しました。これは、他のクラウド ユーザー、つまり管理者を攻撃する可能性があることを意味します。

フィッシングログインフォームに対する XSS 攻撃の例

XSS 攻撃悪用の例:

• 読み込まれたスクリプトがリソース API にすぐにアクセスできるのに、なぜセッションを盗もうとするのでしょうか (特に、現在では HTTP のみの Cookie がどこにでもあり、js スクリプトを使用して盗難から保護されているため)。 この場合、ペイロードは XHR リクエストを使用してサーバー構成を変更することができます。たとえば、攻撃者の公開 SSH キーを追加し、サーバーへの SSH アクセスを取得します。
• CSP ポリシー (コンテンツ保護ポリシー) で JavaScript の挿入が禁止されている場合、攻撃者は JavaScript を使用せずに済む可能性があります。 純粋な HTML を使用して、サイト用の偽のログイン フォームを作成し、この高度なフィッシングを通じて管理者のパスワードを盗みます。ユーザーのフィッシング ページは最終的に同じ URL になるため、ユーザーがそれを検出するのはより困難になります。
• 最後に、攻撃者は、 クライアントの DoS — Cookie を 4 KB より大きく設定します。 ユーザーはリンクを XNUMX 回開くだけでよく、ユーザーが特にブラウザをクリーンアップしようと考えるまで、サイト全体にアクセスできなくなります。ほとんどの場合、Web サーバーはそのようなクライアントの受け入れを拒否します。

別の検出された XSS の例を見てみましょう。今回はより巧妙なエクスプロイトが使用されています。 MCS サービスを使用すると、ファイアウォール設定をグループに結合できます。 グループ名は XSS が検出された場所です。 その特徴は、ルールのリストを表示するときではなく、グループを削除するときにベクターがすぐにトリガーされないことです。

つまり、攻撃者が名前に「load」を含むファイアウォール ルールを作成し、管理者がしばらくしてそれに気づき、削除プロセスを開始するというシナリオであることが判明しました。 そして、これが悪意のある JS が機能する場所です。

MCS 開発者向けに、ダウンロードした SVG 画像の XSS から保護するために (放棄できない場合)、デジタル セキュリティ チームは次のことを推奨しました。

• ユーザーがアップロードしたファイルは、「Cookie」とは関係のない別のドメインに配置します。 スクリプトは別のドメインのコンテキストで実行され、MCS に脅威を与えることはありません。
• サーバーの HTTP 応答で、「Content-disposition:attachment」ヘッダーを送信します。 その後、ファイルはブラウザによってダウンロードされ、実行されません。

さらに、開発者が XSS 悪用のリスクを軽減するために利用できる方法が数多くあります。

• 「HTTP のみ」フラグを使用すると、悪意のある JavaScript がセッション「Cookie」ヘッダーにアクセスできないようにできます。
• 正しく実装された CSP ポリシー 攻撃者が XSS を悪用することがはるかに困難になります。
• Angular や React などの最新のテンプレート エンジンは、ユーザー データをユーザーのブラウザーに出力する前に自動的にサニタイズします。

二要素認証の脆弱性

アカウントのセキュリティを向上させるために、ユーザーは常に 2FA (二要素認証) を有効にすることをお勧めします。 実際、これは、ユーザーの資格情報が侵害された場合に、攻撃者がサービスにアクセスするのを防ぐ効果的な方法です。

しかし、2 番目の認証要素を使用すると、常にアカウントの安全性が保証されるのでしょうか? XNUMXFA の実装には次のセキュリティ上の問題があります。

• OTP コード (ワンタイム コード) の総当たり検索。 操作が単純であるにもかかわらず、OTP のブルート フォースに対する保護が欠如しているなどのエラーが大企業でも発生します。 スラックケース, フェイスブックのケース.
• 生成アルゴリズムが弱い (次のコードを予測する機能など)。
• 次のような論理エラー (電話機で他人の OTP をリクエストできる機能など) было ショッピファイから。

MCS の場合、2FA は Google Authenticator に基づいて実装されており、 デュオ。 プロトコル自体はすでに実証済みですが、アプリケーション側のコード検証の実装はチェックする価値があります。

MCS 2FA はいくつかの場所で使用されます。

• ユーザーを認証するとき。 ブルート フォースに対する保護機能があります。ユーザーはワンタイム パスワードの入力を数回試行するだけで、その後は入力がしばらくブロックされます。 これにより、OTP がブルートフォースで選択される可能性がブロックされます。
• 2FA を実行するためのオフライン バックアップ コードを生成するとき、およびそれを無効にするとき。 ここでは、ブルート フォース保護は実装されていないため、アカウントのパスワードとアクティブなセッションがあれば、バックアップ コードを再生成したり、2FA を完全に無効にしたりすることが可能でした。

バックアップ コードが OTP アプリケーションによって生成されたものと同じ文字列値の範囲にあったことを考慮すると、短時間でコードが見つかる可能性ははるかに高くなります。

「Burp: Intruder」ツールを使用して 2FA を無効にする OTP を選択するプロセス

結果

全体として、MCS は製品として安全であるようです。 監査中、侵入テスト チームはクライアント VM とそのデータにアクセスできず、見つかった脆弱性は MCS チームによってすぐに修正されました。

ただし、セキュリティは継続的な作業であることに注意することが重要です。 サービスは静的なものではなく、常に進化しています。 また、完全に脆弱性のない製品を開発することは不可能です。 しかし、時間内にそれらを発見し、再発の可能性を最小限に抑えることはできます。

現在、MCS の前述の脆弱性はすべてすでに修正されています。 そして、新しいものの数を最小限に抑え、その寿命を短縮するために、プラットフォーム チームは次のことを続けています。

• 外部企業による定期的な監査を実施します。
• 参加をサポートし、発展させる Mail.ru グループのバグ報奨金プログラム内;
• セキュリティに従事します。 🙂

出所： habr.com