git-sync が直面する問題：Kubernetes のコマンドインジェクションの欠陥に関する調査
エグゼクティブサマリー
Akamai の研究者である Tomer Peled は、Kubernetes の付随プロジェクトである git-sync にコマンドインジェクションを可能にする設計上の欠陥があることを発見しました。彼は DEF CON 2024 でこの調査結果を発表する予定です。
この設計上の欠陥により、ポッド内の任意のファイルのデータ窃取（ サービス・アカウント ・トークンを含む）か、 git_sync ユーザー権限によるコマンド実行のいずれかが発生する可能性があります。
この脆弱性を悪用するために攻撃者が実行する必要があるのは、クラスターに YAML ファイルを適用することだけです。これは、低い権限で実行できる操作です。
この脆弱性は、あらゆるプラットフォーム（Amazon Elastic Kubernetes Service（EKS）、Azure Kubernetes Service（AKS）、Google Kubernetes Engine（GKE）、 Linode を含む）の Kubernetes のデフォルトインストールで悪用される可能性があります。
このブログ記事では、 概念実証 （PoC）の YAML ファイルと、潜在的な影響を示すデモを提供します。
この設計上の欠陥は CVE が割り当てられていないため、パッチが存在せず、 悪用可能なままです。
Kubernetes チームは、Akamai がこの調査を共有して、この攻撃ベクトルに対する意識の向上を図るよう勧めました。
はじめに
Kubernetes がコマンドインジェクションの脆弱性に直面するのは、これが初めてではありません。2023 年だけでも同様の脆弱性が 7 つ発見されており、そのうちのいくつかは Akamai が発見した脆弱性です。入力のサニタイズに関する懸念があったため、Akamai は付随的な攻撃ベクトルをより深く調べ、この攻撃ベクトルは Kubernetes のメインプロジェクトに固有のものなのか、それともより広範なものなのかを調査しました。Kubernetes に関連するいくつかの付随プロジェクトに脆弱性が隠れている可能性があります。その 1 つが、 git-syncです。
git-sync プロジェクトの目的は、CI／CD ソリューションを使用して手動で変更を行うのではなく、ポッドと git リポジトリーを接続して、サイト／サーバー間の変更を自動的に同期することです。たとえば、ユーザーはこの機能を使用して、nginx ポッドを介して公開したいファイルを含むリポジトリーに nginx ポッドをリンクできます。
このブログ記事では、設計上の欠陥の詳細、それを可能にする Kubernetes ソースコードの問題、およびいくつかの緩和策を取り上げます。また、Akamai の調査結果に対する Kubernetes の対応 についても説明します。
攻撃ベクトルの詳細
git-sync の使用方法に関するページを見ると、可能な設定パラメーターが多数サポートされており、ユーザーが git-sync をニーズに合わせてカスタマイズできることがわかります。そのため、攻撃者が悪用できる大きなアタックサーフェスが発生する可能性があります（図 1）。
図 1：git-sync のパラメーターの一部
Kubernetes フレームワークでは、Container Network Interface の構成からポッド管理、さらにはシークレット処理まで、基本的にすべてに YAML ファイルが使用されます。そのため、YAML 内に脆弱性があると非常に危険な状態に陥る可能性があります。この場合、git-sync を使用してリモートリポジトリー（すなわち攻撃者）に接続するためのポッドを作成できます。
図 2 は、git-sync を使用してポッドを展開する設定 YAML ファイルの例です。
図 2：git-sync を使用してポッドを展開する設定 YAML ファイル
潜在的な攻撃ベクトルとして、 GITSYNC_GIT と GITSYNC_PASSWORDの 2 つのパラメーターが最も際立っていました。
git-sync の公式 文書によると、 GITSYNC_PASSWORD_FILE は、「 git 認証（--username を参照）に使用するパスワードまたはパーソナル・アクセス・トークン（github docs を参照）が読み込まれるファイル」です。これは、ポッド上の「accesstoken」やその他のファイルのデータ窃取が発生する可能性があることを示しています。
GITSYNC_GIT は（同じく 公式文書によると）、「実行する git コマンド」です（ PATH 検索の対象、主にテスト用）。デフォルトでは「git」に設定されています。つまり、 git の 代わりに 実行するバイナリーを選択でき、それを使用してクラスターでコードを実行できるということです。
攻撃チェーン案
上記の情報を念頭に置いて、私たちの説を証明していきます。攻撃者が悪用する可能性のある攻撃ベクトルがいくつかあるというのが私たちの考えです。
隠密のリモートコード実行
クラスターまたは名前空間に対する権限の低い（Create 権限を持つ）攻撃者は、バイナリーへのパスを含む悪性の YAML ファイルを適用し、git-sync 名でそれを実行する可能性があります。
バイナリーファイルはポッド内になければならず、そうするための方法がいくつかあります。たとえば、 Kubernetes プローブ、 Kubernetes ボリューム、または git-sync ポッドに付属する LOLBins などを利用します（図 3）。
図 3：LOLBins を使用した YAML の例
YAML ファイルを適用すると、ブルーチームのメンバーの目には、git-sync がリモートサーバーと通信しているように見えます。したがって、外部との通信が許されていると合理的に判断されます。これにより、攻撃者はコマンドを実行できるだけでなく、セキュリティ対策を回避できます。
図 4 は、git-sync ユーザーの下で XMRig クリプトマイナーを起動する可能性のある攻撃の POC です。
図 4：可能性のある XMRig クリプトマイナーの POC
このとき、ネットワーク管理者が既存のポッドと社内ネットワーク外の通信を監査すると、ほとんどの場合、git-sync ユーザーが外部サーバーと通信しているのを確認することになります。
データ窃取
Edit 権限を持つ攻撃者は、git-sync の展開を編集して、 GITSYNC_PASSWORD_FILE パラメーターを変更または追加し、 ポッド上の任意のファイルに向けることができます。これにより、git リポジトリーへの次回の接続での認証手段として、git-sync がそのファイルを送信します。
また、攻撃者が git リポジトリーの場所を変更し、擬似リポジトリーサーバーを設定した場合は、次にポッド内で git-sync プロセスを展開したときに、 GITSYNC_PASSWORD_FILE パラメーター内のファイルがポッドから攻撃者のマシンへ送信されます。 GITSYNC_PASSWORD_FILEに必要なファイルパスや権限に制限はありません。
ハイリスクの窃取が行われることは想像に難くありません。次の事項について考えてみましょう。攻撃者はこの手法を使用してポッドのアクセストークンを取得することにより、git-sync ポッドを装ってクラスターとやり取りできます（図 5）。
図 5：可能性のある GITSYNC_PASSWORD_FILE 攻撃の POC
調査結果の開示と Kubernetes の対応
Akamai は当初、2023 年 12 月に Kubernetes チームに調査結果を開示しました。Kubernetes チームとの話し合いの後、 YAML の編集は高い権限で実行できる操作と見なされる ため、この調査結果はセキュリティのしきい値を超えていないと判断されました。しかし、私たちの見解では、ポッドでの編集操作は特権的と見なされますが、この手法を使用すればラテラルムーブメント（横方向の移動）が可能です。また、完全性が損なわれるという懸念もありました。攻撃者は、正当な git-sync ユーザーであるかのように情報を盗むことができます。
GITSYNC_GITについて、Kubernetes チームはこのタイプのアクションに必要な権限が低いことを認めましたが、低い権限で実行できる操作が有害なふるまいにつながるとは考えませんでした。しかし、前述の設計上の欠陥により、攻撃者はアイデンティティを偽装しながらコマンドを実行できると考えられます。また、有害なふるまいを妨げるものは、クラスターに対する低い権限しかありません。 この攻撃フローは、クラスター内に事前に承認された git-sync 通信のある組織では特に危険です。
いずれのケースに関しても、Kubernetes はこの非常に有益な調査結果をオンラインで共有することを推奨しました。その理由は、「ユーザーに公開するサーフェスについて慎重に考えることを管理者に促すために役立つ」からだそうです。
緩和策
このブログ記事で説明した攻撃手法を Kubernetes チームは脆弱性であると見なさないため、パッチは適用されません。そのため、これらの「機能」によってもたらされるアタックサーフェスを減らすために、可能な緩和策をいくつか推奨します。
まず、組織から発せられる通信の監視を強化します。具体的には Kubernetes ポッドからの通信です。きめ細かい監視が可能である場合は、git-sync ポッドに特に注意してください。
次に、git-sync ポッドを監査し、実行中のコマンドを確認することが推奨されます。これは、次のコマンドを使用して実行できます。
kubectl describe pod <git-sync-pod>
たとえば、図 4 のクリプトマイナーでこのコマンドを実行すると、 –git 引数が表示されます。これが検知されると、危険と見なされるはずです。特に引数の値が「git」でない場合はそうです（図 6）。
図 6：図 4 のクリプトマイナーでこの監査コマンドを実行
この監査は一般的なセキュリティ対策として好ましいため、git-sync ポッドだけでなく、すべてのポッドに対してこのコマンドを実行することを推奨します。
また、Akamai は攻撃ベクトル案の 1 つを検知できる OPA ルールを作成しました。その攻撃ベクトルでは、攻撃によって git バイナリーが悪性ペイロードに置き換えられます。
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "<Deployment/Pod>"
path := input.request.object.spec.env.name
contains(path, "GITSYNC_GIT")
msg := sprintf("Gitsync binary parameter detected, possible payload alteration, verify new binary ", [path])
}
結論
このブログ記事では、Kubernetes の付随プロジェクトである git-sync に存在する 2 つの攻撃ベクトルを示しました。どちらのベクトルも入力のサニタイズがないため、ユーザー入力のサニタイズに関する強力な防御が必要です。このような Kubernetes のサニタイズ問題は、 以前 に説明したとおり、git-sync に固有のものではありません。
ブルーチームのメンバーは、組織内の git-sync ユーザーに起因する異常なふるまいに注意を払う必要があります。これらの攻撃ベクトルは企業に非常に大きな影響を与える可能性があると考えられます。そのため、意識を向上させ、セキュリティ管理者が潜在的な危険を把握できるよう支援することが重要です。
Akamai Security Intelligence Group は、このような脅威を継続的に調査し、お客様やセキュリティコミュニティ全体に報告します。Akamai の現在の取り組みについてリアルタイムの最新情報をチェックするためには、 X（旧 Twitter）で Akamai をフォロー してください。
結論には賛同できませんが、Kubernetes チームによる対応と議論に感謝いたします。
