かくれ遊び

Nov 03, 2023

2022年10月21日

パート 1 では、Intel SGX エンクレーブとは何か、そしてそれがランサムウェア作成者にどのような利益をもたらすかについて説明しました。 パート 2 では、仮説的な段階的な実装を検討し、この方法の制限について概説します。

このライブ攻撃デモを見て、CrowdStrike Falcon® プラットフォームと CrowdStrike Falcon Complete™ マネージド検出および対応チームがどのようにランサムウェアから保護するかを確認してください。

このセクションでは、非対称暗号化にエンクレーブを使用するランサムウェアの例を段階的に構築します。 ランサムウェアは 2 つの部分に分かれています。

ここで示すコードの抽出は、アプリケーションの通常のコア (main.c) またはエンクレーブ (enclave.c) から取得されます。 エンクレーブは RSA キーのペアを生成し、秘密キーを封印し、Intel SGX API を使用してエンクレーブ内の被害者のデータを暗号化します。 これがどのように行われるか、またアプリケーションのコアがエンクレーブとどのように対話するかを見てみましょう。

まず、アプリケーションの通常のコアが、エンクレーブの作成とセットアップなど、ランサムウェアの実行に必要なリソースを初期化します。 エンクレーブをロードするには、sgx_urts.lib.1 の関数 sgx_create_enclave() を使用します。関数のプロトタイプは次のとおりです。

この関数の引数は、コンパイル モードや以前のロードに関する情報など、エンクレーブ属性の一部を表します。 たとえば、sgx_launch_token_t はエンクレーブ起動トークンを表す不透明な構造です。 トークン情報は、エンクレーブの実行全体を通じてエンクレーブに関する情報を保持し、将来のエンクレーブのロードを容易にするために保存できます。

図 1. エンクレーブを作成するコードの抜粋 (クリックして拡大)

エンクレーブがロードされると、アプリケーションの通常のコアは ECALL を実行して鍵生成プロセスを開始できます。

エンクレーブ内では、キーの生成は sgx_tcrypto.lib と呼ばれる Intel SGX SDK に基づいて行われます。 これは、エンクレーブから直接呼び出すことができる文書化された API です。 内部では、API はインテルが開発した他の暗号化ライブラリ、統合パフォーマンス プリミティブ (インテル® IPP) およびインテル® ソフトウェア ガード エクステンション SSL 暗号化ライブラリ (インテル® SGX SSL)2 に基づいています。どちらも OpenSSL に基づいています。 。

このプロセスの最初のステップは、関数 sgx_create_rsa_key_pair() を使用して、エンクレーブから秘密鍵と公開鍵の RSA コンポーネントを生成することです。 これは、キーを作成する関数呼び出しの前に実行される予備呼び出しであり、事前定義された RSA キーのモジュラス サイズと公開指数に準拠するコンポーネントを生成するために使用されます。

図 2. RSA キー コンポーネントを生成するコードの抜粋 (クリックして拡大)

これらの RSA キー コンポーネントから、関数 sgx_create_rsa_pub1_key() を使用して、被害者のファイルの暗号化に使用される RSA 公開キーを生成します。

図 3. RSA 公開キーを作成するコードの抜粋 (クリックして拡大)

次の論理的なステップアップは、通常、公開キーの場合と同様に、秘密キーを生成することです。 ただし、この場合、秘密キーはまだ必要ありません。秘密キーは、被害者がランサムウェア作成者の要求に応じた場合にのみ、解読目的で使用されるからです。 現時点では、将来の取得に備えて秘密キー コンポーネントを安全に保存して非表示にするだけで済みます。 この目的を達成するために、データ シーリング方式を使用して、OS の通常のメモリにクリアテキストとして表示されることなく、秘密キーがディスクに書き込まれ、暗号化されて保存されるようにします。

これを行う 1 つの方法は、秘密キーを生成し、それをディスク上に直接封印することですが、この方法では進めません。 以下に示す秘密キーを生成するインテル SGX SDK3 の関数プロトタイプを考えてみましょう。

秘密キーの値は void** に書き込まれますが、内部で使用される実際の構造は、OpenSSL ライブラリに由来する複雑な構造である EVP_PKEY 構造であることに注意してください。

図 4. openssl ライブラリからの EVP_PKEY 構造を定義するコードの抜粋 (クリックして拡大)

したがって、秘密キーを封印したい場合は、EVP_PKEY 構造体を使用する必要があります。 それにもかかわらず、Enclave の開発アーキテクチャは外部ライブラリを容易にインポートするように設計されていないため、Open SSL ライブラリを直接使用するのは面倒です。 それ以外の場合は、構造を最初から再作成することもできますが、これには複数の解析操作が必要になります。 秘密キーを適切な構造に保存することが複雑であることを考慮すると、秘密キーのコンポーネントを保存して、後の段階で秘密キーを構築する方がはるかに簡単です。 このプロセスをサポートするために、秘密キー コンポーネントを収集するための構造を作成しました。

図 5. PrivateKey 構造を定義するコードの抜粋 (クリックして拡大)

これで、将来の復号化に備えて秘密鍵コンポーネントを封印する手段が得られました。 キーコンポーネントを生成したときに生成されたのと同じ値を使用し、それらをカスタム PrivKeyComp 構造体の適切なフィールドに割り当てます。 構造が正しく設定されたら、sgx_tservice.lib.4 の sgx_seal_data_ex() を使用して秘密鍵コンポーネントをシールできます。

図 6. RSA 秘密鍵コンポーネントを保護するコードの抜粋 (クリックして拡大)

ここでは、sgx_seal_data() の拡張バージョンである sgx_seal_data_ex() を使用します。これにより、MRENCLAVE ポリシーの使用が可能になります。 このポリシーを選択したのは、同じエンクレーブの作成者によって署名された他のエンクレーブが封印されたデータにアクセスできないことが保証されるためです。 攻撃者のエンクレーブ署名が盗まれた場合、データの封印を解除するために使用される可能性があります。

秘密キー コンポーネントは、封印されるとアプリケーションの通常のコアに戻され、ディスクに書き込むことができます。

この時点から、被害者のデータを暗号化するには 2 つのオプションがあります。 最初のオプションは、公開キーをアプリケーションの通常のコアに返し、エンクレーブの外で被害者のファイルを暗号化することです。 もう 1 つのオプションは、公開キーをエンクレーブ内に保持し、Intel SGX API の関数を使用して被害者のデータを暗号化することです。 後者は、エンクレーブ外での従来の暗号化プロセスよりも複雑ですが、この方法を使用して SGX プログラミングの可能性を示します。

アプリケーションの信頼できない部分は、被害者のファイルを開いて読み取ることを担当します。 エンクレーブ内で生成される暗号化されたデータを取得するには、アプリケーションの通常のコアで出力バッファーを初期化する必要があります。 そうしないと、保護されたメモリ内で生成されたバッファを信頼できない領域に送信できなくなります。

暗号化は関数 sgx_rsa_pub_encrypt_sha256() で行われ、SHA-256 を使用した RSA-OAEP 暗号化スキームを実行します。 これにより、RSA 法 n のサイズに制限されたバッファーの暗号化およびエンコード操作が計算され、結果として同じ長さのバッファーが得られます。 この場合、RSA モジュラス n が 256 バイトであるとすると、sgx_rsa_pub_encrypt_sha256() の出力バッファーの長さは 256 バイトになります。5 そのため、暗号化されたデータを保持する出力バッファーに 256 バイトのバッファーを割り当てます。

次に、この出力バッファを、暗号化するデータを含むバッファとともに送信します。

図 7. ファイルのコンテンツを暗号化するコードのメインコードからの抜粋 (クリックして拡大)

エンクレーブはバッファを受け取り、以前に生成された公開キーを使用して暗号化を実行します。 これは 3 つのステップで行われます。 最初のステップでは、sgx_rsa_pub_encrypt_sha256() を呼び出して、結果として得られる暗号化バッファのサイズを取得します。 サイズが返されたら、それが 256 バイト (出力バッファに割り当てたサイズ) に対応しているかどうかを確認します。 一致する場合、sgx_rsa_pub_encrypt_sha256() への 2 回目の呼び出しを実行して、出力バッファ内の暗号化されたデータを取得します。

図 8. エンクレーブからのファイルのコンテンツを暗号化するコードの抜粋 (クリックして拡大)

最後に、アプリケーションの通常のコアは、エンクレーブから返された暗号化されたコンテンツで元のファイルのコンテンツをオーバーライドします。

同じロジックが復号化プロセスにも適用されます。 シールされたデータはエンクレーブに送信され、エンクレーブは sgx_unseal_data() でシールを解除し、秘密キー コンポーネントを PrivKeyComp グローバル変数に保存します。 暗号化されたデータはエンクレーブに送信され、グローバル変数 PrivKeyComp を sgx_create_rsa_priv2_key() のパラメーターとして使用して秘密キーを構築し、関数 sgx_rsa_priv_decrypt_sha256() でデータを復号化します。 解読されたデータはアプリケーションの通常のコアに返され、暗号化されたファイルが元の平文で上書きされます。

私たちが確立したように、エンクレーブの使用には、ランサムウェアのターゲットが復号キーを取得できないようにするなど、大きな利点があります。 ただし、この戦術にはかなりの制限もあり、ランサムウェア攻撃における蔓延が限定的であることが説明されています。

まず、エンクレーブには厳密なハードウェア仕様があります。 SGX は独自のテクノロジーであるため、Intel CPU が必要です。 AMD には ARM TrustZone と呼ばれる同等のテクノロジがありますが、Intel SGX ライブラリに基づいてコンパイルされたコードは、Intel 以外の CPU では動作しません。 さらに、Intel は第 11 および第 12 コア プロセッサのデスクトップ世代ではこの機能を非推奨にしたため、特定の Intel CPU モデルのみが SGX をサポートしています。6 最終的なハードウェア要件として、Intel SGX 機能は BIOS から有効にする必要がありますが、これは BIOS によって有効にすることはできません。デフォルト。

これらすべての要件を考慮すると、ターゲットのシステムがエンクレーブを使用してバイナリを実行できる可能性は非常に低くなります。 さらに、感染したすべてのシステムで SGX テクノロジーの使用が有効になっているわけではないため、特に一般的なランサムウェア手法と比較すると、ターゲットへの感染に成功する可能性はかなり低くなります。

このブログの前半で、エンクレーブをリリース モードでコンパイルするには検証プロセスを完了する必要があると説明しました。 それにもかかわらず、必要なライブラリが悪意のあるバイナリとともにインポートされている場合、デバッグ モードでコンパイルされたエンクレーブは Intel SGX 対応マシン上で引き続き実行できます。 攻撃に必要なバイナリのサイズは、従来のランサムウェア バイナリのサイズよりもはるかに大きくなりますが、そのようなシナリオは考えられます。

さらに、攻撃者がエンクレーブをリリース モードで使用しようとする場合、エンクレーブが RSA キーのペアを生成し、データを暗号化および封印するためのバッファを受信するだけであるように見える場合、インテルの検証プロセスによって検出されない可能性があります。 このような状況では、インテルはエンクレーブが悪意のある目的に使用されているかどうかをどのように判断するのでしょうか?

グラーツ工科大学の研究者らは、「インテルは個々のエンクレーブを検査して署名するのではなく、任意のエンクレーブに署名するためにエンクレーブ開発者の裁量で使用される署名キーをホワイトリストに登録している」と主張しています7。彼らは、ある独立した学生の例を挙げています。署名キーを取得するインテルのプロセスが正常に完了しました。 これにより、マルウェア作成者が Intel のホワイトリスト登録プロセスを経てエンクレーブを使用できるかどうかという疑問が生じます。

ランサムウェア作成者にとってのもう 1 つの可能性は、正規の署名を盗むことです。 これにより攻撃はさらに複雑になりますが、過去にも行われていました。 この場合、攻撃が検出されてインテルに報告されるとすぐに、インテルは使用されているエンクレーブの署名をホワイトリストから取り消し、悪意のあるエンクレーブのロードを防ぎます。 署名が盗まれたものであるか、合法的に取得されたものであるかにかかわらず、ランサムウェア キャンペーンが開始されるとすぐに発見のリスクが急速に高まり、署名の有効期間の問題が生じます。

エンクレーブの使用をさらに柔軟にするために、インテルは 2018 年に代替の柔軟な起動制御をリリースしました。8 この機能により、サードパーティはインテルの検証プロセスをバイパスして、適切に構成されたマシンにどのエンクレーブをロードできるかを制御できます。 対象となるマシンが、各マシンの BIOS で構成された柔軟な起動制御機能をサポートし、有効にする必要があります。 このアプローチでは、感染前に BIOS にアクセスできることと、環境を構成するための管理者権限が必要ですが、どちらも攻撃を複雑にします。

エンクレーブ内では、コードは特定のコンテキストで実行されるため、通常の OS 環境よりも実行が遅くなります。 ランサムウェアの実行に時間がかかるほど、ユーザーが不審なアクティビティを警告され、それに対応する時間がなくなり、攻撃が成功する可能性がさらに危険にさらされます。

Intel は、サイドチャネル攻撃を SGX 脅威モデルの一部として考慮していません。 Intel® Software Guard Extensions 開発者ガイド 9 には、「インテル SGX はサイドチャネル攻撃からの明示的な保護を提供しません。サイドチャネル攻撃の懸念に対処するのはエンクレーブ開発者の責任です。」と記載されています。

これは、エンクレーブ内で何が起こっているかを観察し、解読キーを傍受する可能性がある方法があることを意味します。さらに、エンクレーブの使用は決して確実ではなく、過去に漏洩に成功していることを強調しています。これについては論文「SGAxe: How」で説明されています。 SGX は実際には失敗する。」10

ディスクに書き込まれた封印されたキーの安全性にも限界があります。

Intel の開発者ガイドには、「エンクレーブは、定義されている信頼できるスレッドの数に関係なく、信頼できないアプリケーションが特定の順序に従って ISV インターフェイス関数を呼び出すことを想定して設計してはなりません。エンクレーブが初期化されると、攻撃者は任意の関数を呼び出す可能性があります。」 ISV インターフェイス機能では、呼び出しを任意の順序で配置し、任意の入力パラメータを提供します。攻撃に対してエンクレーブを開くことを防ぐために、これらの策略を念頭に置いてください。」

Intel のコミュニティ フォーラムでの最近の質問では、異なるアプリケーションが同じエンクレーブを使用しているかどうかが質問され、これに対して Intel は、「ある信頼できないアプリが別のエンクレーブをロードすることを防ぐ組み込みの方法はありません。」12と答えました。ランサムウェア攻撃で使用されたバイナリと封印された秘密鍵があれば、少なくともデバッグ モードでは、エンクレーブと対話して秘密鍵の封印を解除するア​​プリケーションを再作成できる可能性があります。

実際には、このようなアプリケーションを作成するには、ECALL 定義を含むエンクレーブ .edl ファイルをインポートする必要があります。 このファイルが攻撃のバイナリにインポートされる可能性は低いため、唯一の選択肢は .edl ファイルを再構成することですが、攻撃者がエンクレーブ バイナリを難読化した場合、これはさらに複雑になる可能性があります。

秘密キーが MRSIGNER ポリシーを使用して封印されているシナリオでは、封印されたキーの安全性がさらに大きく問われます。 法医学捜査官がエンクレーブ作成者の署名を取得できれば、インテルのサポートを受けて同様に署名されたエンクレーブを再作成し、この新しいエンクレーブでデータの封印を解除できる可能性があります。 実際、データはエンクレーブ作成者の署名を使用して封印されているため、同じ署名を持つ別のエンクレーブがデータの封印を解除できます。

これらのそれぞれの制限により攻撃に制約が追加されますが、それらはすべて緩和できます。 SGX 機能を有効にすると、感染前のいくつかの手順で回避できます。 エンクレーブの使用を容易にするために、Intel はアクティベーション アプリ 13 をリリースしました。これにより、図 9 に示すように、ユーザーは「アクティベート」ボタンをクリックするだけで、互換性のある Intel Core ベースのプロセッサベースのプラットフォームで Intel SGX を有効にすることができます。は管理者権限で実行されますが、ソーシャル エンジニアリングのアプローチにより、被害者が正規のアプリケーションの 1 つのボタンをクリックするよう簡単に仕向けられる可能性があります。

図 9. インテル® ソフトウェア ガード エクステンション アクティベーション アプリのスクリーンショット (クリックして拡大)

標的のシステムで Intel SGX 機能が有効になっていると、攻撃者はデバッグ モードでコンパイルされたエンクレーブ バイナリを使用して署名要件をバイパスし、依存関係を攻撃に埋め込む可能性があります。 コードの実行を高速化するために、アプリケーションの通常のコア内でマルチスレッド実装または外部化された暗号化プロセスを使用できます。 さらに、攻撃後にエンクレーブ バイナリが感染システムから完全に削除された場合、攻撃者は、封印された秘密キーが許可されるまで封印が解除されないと確信できます。 最後に、サイドチャネル攻撃が感染前に設定される可能性は非常に低いため、エンクレーブを使用したランサムウェア攻撃を阻止できる可能性は非常に低いです。

インテル SGX テクノロジーは、開発者にコードを保護するユニークな機会を提供します。 私たちは、エンクレーブのアーキテクチャがどのように機密データの保護に役立つ環境を提供し、それを安全に操作するためのさまざまなメカニズム (シーリングなど) を組み込んでいるかを検討しました。

これは日常業務では有益ですが、ランサムウェア作成者による暗号キー管理の例のように、悪意のある目的に悪用される可能性もあります。 エンクレーブを使用すると、ランサムウェア作成者は安全かつ確実に暗号キーを生成できるため、ランサムウェア作成者が避けたい 2 つの最も一般的なシナリオ (復号キーの取得とオフライン ターゲットへの感染の防止) を攻撃の被害者が利用するのを防ぐことができます。

ランサムウェアによるエンクレーブの使用率が低いのは、Intel SGX によって課された技術的制限が主な原因です。 そのハードウェア要件と将来の CPU 世代での非推奨により、対象となるシステムがエンクレーブの実行に必要な条件をすべて満たせる可能性が低くなります。 さらに、実稼働モードでエンクレーブを解放するには、Intel の署名プロセスを通過する必要があります。このプロセスが正常に完了すると、一晩ですぐに取り消すことができる署名が得られ、ランサムウェアが実行される可能性がさらに低くなります。

私たちが実証したように、ランサムウェアの作成者は攻撃を調整するためにエンクレーブだけに依存することはできませんが、暗号キー管理にエンクレーブを使用することで恩恵を受ける可能性があります。 エンクレーブには正当な用途があるため、これらのランサムウェア攻撃に対する予防アプローチは、エンクレーブの負荷の検出のみに依存すべきではありません。

お客様が組織全体を継続的に可視化できるようにするという当社の取り組みの一環として、CrowdStrike Falcon センサーはエンクレーブの使用状況を可視化し、このデータをイベント テレメトリと並行して使用して、プロセスに悪意があるかどうかを判断し、検出された脅威に対応します。 結局のところ、飛び地は単なる手がかりに過ぎず、それ以上でもそれ以下でもありません。

業界をリードする CrowdStrike Falcon プラットフォームがランサムウェアなどの最新の脅威からどのように保護されるかをご自身の目で確認してください。 15 日間の無料トライアルを今すぐ始めてください。

今すぐサインアップして、CrowdStrike からの最新の通知と更新情報を受け取ります。

次世代のエンドポイント保護により、あらゆる段階で攻撃 (マルウェアのない侵入も含む) を検出、防止し、対応します。