Curveball 単純だが恐ろしいバグ

組織のセキュリティ対策, 脅威情報
2020.1.22

2020年になったばかりですが、セキュリティ業界はわずか2週間でMicrosoftの年初初のパッチ CVE-2020-0601の修正によって揺り動かされました。バグは、国家安全保障局（NSA）からMicrosoftに警告されました。当初は「重要」とだけ見なされていましたが、このバグがWebサイトの保護とファイルの検証に依存する信頼の概念全体を根本的に損なうことを誰もがすぐに理解できました。

この脆弱性はECC（楕円曲線暗号）に依存しています。ECCは、ファイルに埋め込まれた証明書とWebページのセキュリティ保護に使用される証明書の両方を含む、証明書にデジタル署名する非常に一般的な方法です。信頼できる情報交換のための公開鍵と秘密鍵を生成する値の数学的な組み合わせを表します。今のところ、詳細な情報を無視して、ECCでは、開いているファイルまたはアクセスするWebページが、よく知られた信頼できる機関によって署名されていることを検証できます。その信頼が破られると、悪意のある攻撃者は署名されたファイルやWebサイトを「偽造」し、あたかもそれらがまだ信頼されている、または正当に署名されているかのように見せかけることができます。この欠陥は、Microsoftライブラリcrypt32.dllにあり、2つの脆弱な機能があります。これらの関数は暗号化された公開鍵の値のみを検証し、ECC曲線自体のパラメーターは検証しないという点で、わかりやすいバグです。つまり、攻撃者が秘密鍵と対応する曲線の適切な数学的組み合わせを見つけることができる場合、信頼できる認証局と同じ公開鍵値を生成できます。また、これは脆弱な機能によってチェックされる唯一の値であるため、「悪意のある」または無効なパラメーターは無視され、攻撃者が認証プロセスをバイパスすることを可能にします。

脆弱性の情報をつかむとすぐに、McAfeeのAdvanced Threat Researchチームは、バグを作動させ、最終的にお客様を保護するための幅広い製品にわたって保護を作成できる実用的な概念実証（PoC）の作成に着手しました。

（共謀理論は別として）政府と民間部門が協力して、脆弱性が悪用される前に脆弱性を報告、修正、公開するという事実を推奨するために、少し詳しく見ていきましょう。また、MicrosoftのActive Protections Programを確認します。このプログラムは、脆弱性に関する基本的な詳細を提供し、サイバーセキュリティの実践者が分析を少しでも有利に開始できるようにします。

以下は、バグの作業エクスプロイトを分析、リバースエンジニアリング、開発するために行った作業の基本的な技術詳細とタイムラインを示しています。このブログは、主にファイル署名証明書に関する調査に焦点を当てています。Webベクトルのより詳細な分析については、この投稿を参照してください。

1 PoC（概念実証）の作成
2 マカフィーの対応

PoC（概念実証）の作成

攻撃をシミュレートするための出発点は、問題の場所を明確に理解することでした。攻撃者は、ECC Product Root Certificate Authority 2018などのMicrosoft ECCルートCAと同じ公開鍵を使用しますが、「パラメーター」が異なるECCルート証明書を偽造する可能性があり、信頼できるMicrosoft CAとして認識されます。 APIは公開鍵を使用して証明書を識別しますが、提供されたパラメーターが信頼された公開鍵に付随するパラメーターと一致したことを確認できません。

APIの失敗を利用してパラメーター（これら2つなど）を検証し、攻撃者がこのタイプの脆弱性を悪用する暗号化攻撃の多くの例があります。無効なパラメーターに関するヒアリングは、すぐに警告が促されます。

労力を最小限に抑えるための重要な最初のステップは、適切なレベルの抽象化と注意が必要な詳細を見つけることです。バグに関する最小限の詳細は、公開鍵と曲線のパラメーターを参照し、特定の署名の詳細については何も参照しません。そのため、楕円曲線（EC）暗号化で公開/秘密鍵を生成する方法と曲線を定義する方法について読むだけで十分でしょう。

このウィキペディアの記事の最初の部分では、知っておくべきほとんどのことを定義しています。曲線上にあり、別のポイントを生成するために使用されるポイントGがあります。公開/秘密キーのペアを作成するには、乱数k（秘密キー）を取得し、それにGを掛けて公開キー（Q）を取得します。したがって、Q = k * Gです。これがどのように機能するかは、スカラー倍算が期待どおりに動作する限り、この目的にとって実際には重要ではありません。ここでの考え方は、QとGを知っているとkを回復するのは難しいが、kとGを知っているとQを計算するのは非常に簡単だということです。

バグの観点からこれを言い換えると、ECCが同じQを返すように、異なるパラメーター（新しい曲線、またはおそらく新しいG）を持つ新しいk ‘（新しい秘密キー）を見つけたいと思います。最も簡単な解決策は、ターゲット公開鍵（G ’= Q）と等しい新しいジェネレーターG’を検討することです。このように、k ’= 1（1に等しい秘密鍵）を使用すると、制約（新しい秘密鍵を見つけて同じ公開鍵を保持する）を満たすk’G’ = Qが得られます。

次のステップでは、使用する曲線を指定しながら、実際にカスタムG ’を指定できるかどうかを確認します。 Microsoftのドキュメントではこれらの詳細について特に明確ではありませんが、最も一般的な暗号化ライブラリの1つであるOpenSSLには、EC鍵ペアと証明書の生成方法を説明するページがあります。次のコマンドは、Microsoft ECCルートCAが使用するP384曲線の標準パラメーターを表示します。

楕円曲線パラメーター値

パラメーターの1つがジェネレーターであることがわかります。したがって、パラメーターを変更することは可能です。

ここで、明示的なパラメーターを使用して新しい鍵ペアを作成し（したがって、曲線の標準名を単に埋め込むのではなく、すべてのパラメーターがキーファイルに含まれます）、仮説に従って変更する必要があります。 Generator G ‘をMicrosoft証明書のQに置き換え、秘密鍵k’を1に置き換え、最後に、Microsoft証明書のQによって生成したばかりの証明書の公開鍵Q ‘を置き換えます。

変更が機能し、変更された鍵が有効なものであることを確認するために、OpenSSLを使用してテキストファイルに署名し、その署名を正常に検証します。

テキストファイルに署名し、変更したキーペア（k ’= 1、G’ = Q、Q ’= Q）を使用して署名を検証

そこから、いくつかのチュートリアルに従って、OpenSSLを使用して署名証明書を作成し、signtoolでカスタムバイナリに署名しました。最終的に、有効な証明書で署名されているように見える署名済みの実行可能ファイルが表示されます。

Microsoft ECCルートCAによって署名されたように見える偽造/偽造証明書

SysinternalのSigChecker64.exeとRohitabのAPI Monitor（皮肉なことにHTTPSを使用していないサイト上にあります）をPoCを使用してパッチを当てていないシステムで使用すると、これらの関数の戻り値によって動作の脆弱性を明確に見ることが可能です。

Rohitab APIモニター-証明書検証のためのAPI呼び出し

業界全体の脆弱性は、非技術的なユーザーでもクリティカルマスを獲得し、可視性を高めているようです。そして、一度プロセスの比較的遅い段階で脆弱性の「かわいい」名前が現れました。可視性は進歩にとって重要であり、潜在的な影響に対する理解と健全な尊重は、企業や個人がパッチを迅速に適用して脅威ベクトルを劇的に削減するかどうかの重要な要因です。これは、非常に簡単に悪用できるバグであり、野生ではすぐに悪用の影響を受ける可能性が高いため、さらに重要です。