attested-tls-poc に成り済まし弱点、悪用の確認は未公表
CCC Attestation SIG の試作実装 attested-tls-poc に、本物の環境が出した証明を中継して成り済ませる弱点が見つかりました。コミット 731ca82 以前を使っている組織が対象で、実際の攻撃での悪用は公表されていません。使用の有無と版を確認し、修正の取り込み状況を追ってください。
急ぎ度: 計画的に
実際の悪用は公表されておらず、対象は試作（PoC）実装で、攻撃には暗号鍵の抜き取りが前提になるためですが、本番系に組み込んでいる場合は優先度を上げてください。
関係があるか
Confidential Computing ConsortiumのAttestation SIGが公開しているattested-tls-pocを、検証用や自社システムの一部として取り込んでいる組織が対象です。機密コンピューティング環境の「証明」をTLSで使う仕組みを試している組織が当てはまります。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| CCC-Attestation attested-tls-poc | コミット731ca82ed533fc7a1092be980887ae2e34261da2以前 | 修正版の番号は公表されていません。修正を提案するプルリクエスト（#58）が公開されています。 |
確かめ方
- 1社内のリポジトリやビルド設定でattested-tls-pocを使っていないか検索します。サブモジュール、ベンダリング（ソースの取り込み）、フォークも対象に含めます。
- 2取り込んでいる場合は、チェックアウトしているコミットを確認し、731ca82ed533fc7a1092be980887ae2e34261da2以前かどうかを見ます。
- 3プルリクエスト #58の内容が、使っている版に取り込まれているかをリポジトリで確認します。
- 4リモート構成証明（attestation）の結果を信頼して通信相手を判断しているシステムがあれば、その実装がattested-tls-poc由来かを開発元に確認します。
何が起きたか
機密コンピューティングでは、サーバー側のプログラム（ワークロード）が「正規の保護された環境で動いている」ことを、Evidenceと呼ばれる証明データで相手に示します。attested-tls-pocは、この証明をTLSの接続手続きに組み込む試作実装です。今回の弱点は、接続の早い段階で出す証明が、そのTLS接続そのものと結び付けられていない点にあります。
結び付きがないため、証明を求める側（relying party）が確認用に送るnonce（使い捨ての値）を、攻撃者が本物の環境に転送し、返ってきた有効な証明をそのまま使い回せます。証明を求める側は、本物の環境が証明を出したと受け取り、攻撃者を正規のワークロードだと誤認します。
技術的には、attested TLS用の秘密鍵を攻撃者がすでに抜き取っていることが前提です。その鍵でTLS接続を成立させつつ、証明だけを本物から借りる形になります。分類はCWE-346（送信元の検証の不備）です。CVSS v3.1は7.4（高）、CVSS v4.0は9.1で、攻撃の複雑さは高いと評価されています。
攻撃の流れ
-
1
鍵の入手
攻撃者がattested TLSの秘密鍵をあらかじめ抜き取っています。
-
2
接続の開始
証明を求める側が攻撃者に接続し、確認用のnonceを送ります。
-
3
nonceの転送
攻撃者はそのnonceを、本物の環境（attester）にそのまま転送します。
-
4
証明の使い回し
本物が出した有効なEvidenceを、攻撃者が自分の接続の証明として返します。
-
5
成り済まし
証明を求める側は正規のワークロードと誤認し、送られたデータを攻撃者が受け取ります。
どう悪用されるか
認証や利用者の操作は不要とされていますが、前提条件は軽くありません。攻撃者は事前にattested TLSの秘密鍵を手に入れている必要があり、さらに本物の環境へnonceを転送して証明を得る必要があります。評価でも攻撃の複雑さは高いとされており、誰でも簡単に突ける弱点ではありません。
悪用された場合は、証明を求める側が偽のワークロードを正規のものと信じて通信します。送った機密データが攻撃者に渡り、攻撃者の返す応答を正しいものとして扱ってしまうおそれがあります。機密性と完全性への影響は高く、可用性への影響はないと評価されています。
実際の攻撃で悪用されたかどうかは、公表されていません。
今すぐやること
-
1
使用箇所を洗い出す
社内のリポジトリ、ビルド設定、コンテナイメージからattested-tls-pocの使用を探します。フォークや取り込み済みのコピーも見落とさないようにします。
-
2
コミットを確認する
使っているコピーのコミットを確認し、731ca82ed533fc7a1092be980887ae2e34261da2以前かどうかを見ます。
git -C attested-tls-poc rev-parse HEAD -
3
修正の取り込み状況を追う
プルリクエスト #58と、リポジトリ(CCC-Attestation/attested-tls-poc)の最新の状況を確認します。修正が取り込まれたら、その版へ更新します。
-
4
本番での利用を見直す
試作実装を本番系や機密データの通信に使っている場合は、利用範囲を見直し、修正が入るまで扱うデータや接続先を絞ることを検討します。
-
5
秘密鍵の保護を点検する
攻撃には鍵の抜き取りが前提になるため、鍵の保管場所とアクセス権を点検します。流出の疑いがあれば、鍵を更新します。
すぐ更新できないとき
公式な回避策は公表されていません。修正を取り込むまでは、試作実装を本番の機密通信に使わないこと、秘密鍵の保護を強めること、通信できる相手を限定することで、リスクを下げられます。
背景
リモート構成証明は、機密コンピューティングで「いま動いているものが、期待どおりの保護された環境か」を第三者が確かめるための仕組みです。クラウド上で機密データを扱う場面で、データを渡す前の信頼の根拠になります。証明をTLSと組み合わせるattested TLSは、その確認を通信路の確立と一体で行う方法として検討が進んでいます。
証明書類を別の接続に流用する中継攻撃は、認証の分野で以前から知られた問題です。確認用の値を受け渡すだけでは、証明が「この接続のもの」であることまでは保証されません。今回の弱点は、証明と接続の結び付けが足りないという、この種の古典的な課題にあたります。参照先には、中継攻撃の形式的な検討や関連するIETFドラフトも挙げられています。
よくある質問
Q.通常のHTTPSやTLSにも影響しますか。
Q.すでに攻撃されているのですか。
Q.CVSS v3.1が7.4、v4.0が9.1と差があるのはなぜですか。
まだ分かっていないこと
- 修正版の番号や、プルリクエスト #58が取り込まれたかどうかは、公表内容から分かりません。リポジトリで確認してください。
- attested-tls-pocを組み込んだ他の製品や実装がどの程度あるかは、現時点で明らかになっていません。
- 実際の攻撃で悪用されたかどうかは公表されていません。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| CCC-Attestation | attested-tls-poc |
731ca82ed533fc7a1092be980887ae2e34261da2 以前 |
— |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
CCC Attestation SIG attested-tls-poc through commit 731ca82 fails to bind early attestation Evidence to the TLS connection, allowing attackers to relay valid Evidence from a genuine attester. Attackers holding an extracted attested TLS private key can forward the relying party's nonce to a genuine attester and replay its Evidence to impersonate the attested workload and intercept data.
出典: GitHub Security Advisories (Global) NVD GitHub Advisory
参照URL
- advisory nvd.nist.gov
- advisory vulncheck.com
- advisory github.com
- package github.com
- patch github.com
- web datatracker.ietf.org
- web github.com
- web github.com
- web github.com
- web github.com
- web datatracker.ietf.org