Burritoにterraform plan不正実行の脆弱性、修正版あり
Kubernetes上でTerraformを自動実行するBurritoに、署名のないWebhookを受け付けて、外部から計画（terraform plan）を走らせられる脆弱性が見つかりました。webhookSecretを設定していないBurrito 0.13.0未満の環境が対象で、修正版は0.13.0です。バージョンの確認と更新を先に進め、受け口がどこから見えているかも合わせて点検してください。
急ぎ度: 早めに
CVSS v3は9.9で認証も不要ですが、実際の悪用は確認されておらず、修正版0.13.0がすでに出ているため、早めの更新を勧めます。
関係があるか
BurritoをKubernetesクラスターで動かし、GitHubまたはGitLabのリポジトリとWebhookで連携している組織が対象です。TerraformRepositoryの認証情報にwebhookSecretがない、または空のままになっている環境で影響を受けます。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| Burrito（padok-team/burrito） | 0.13.0未満。TerraformRepositoryの認証情報でwebhookSecretが未設定または空の場合 | 0.13.0 |
確かめ方
- 1Burritoの各コンポーネント（burrito-serverなど）のイメージタグを確認し、0.13.0未満かどうかを見る。
- 2TerraformRepositoryが参照している認証情報のSecretに、webhookSecretのキーがあり、値が空でないかを確認する。git認証やポーリング用に作った認証情報も対象になる。
- 3burrito-serverの/api/webhookに、社内ネットワークやインターネットのどこから到達できるかを、Ingressやファイアウォールの設定で確認する。
何が起きたか
Burritoのburrito-serverは、GitHubやGitLabからのWebhookを受け取る口を持っています。この口が署名のない通知もそのまま受け入れてしまい、本物の通知を装って、承認されていないterraform planを動かせる状態になっていました。
webhookSecretは認証情報の設定項目のうち任意で、空のままでも登録できます。Webhookの検証に使われているライブラリは、秘密の値が空だと署名やトークンの検証を行わないため、偽の通知がそのまま処理されます。偽の通知でTerraformPullRequestというカスタムリソースを作ったり消したりでき、ブランチ名・ベースブランチ・IDも送った側が決められます。
GitHubのpull_requestイベントでは、コントローラーが実在するプルリクエスト番号から変更ファイルを取得しますが、通知に書かれたブランチがそのプルリクエストのものかどうかは照合していません。このため、実在するプルリクエストと、同じリポジトリの別ブランチを組み合わせた通知で、本来の対象と無関係なブランチに対する計画が走ります。
攻撃の流れ
-
1
受け口に到達
burrito-serverのWebhook受け口にネットワーク経由で届く位置に立つ。
-
2
偽の通知を送信
追跡中リポジトリのURLを手がかりに、署名のないGitHubまたはGitLabの通知を送る。
-
3
リソースを作成
送り手が決めた値で、TerraformPullRequestが作られたり消されたりする。
-
4
planが実行
Burritoが保存しているgitとクラウドの認証情報を使い、意図しないブランチでterraform planが走る。
-
5
結果が漏れる
計画の内容が本物のプルリクエストのコメントに投稿され、別ブランチのインフラ変更が見えてしまう。
どう悪用されるか
認証は要りません。burrito-serverのエンドポイントにネットワークから届き、追跡されているリポジトリのURLを知っていれば足ります。利用者の操作も不要で、前提となる設定は、webhookSecretが未設定か空であることです。
被害は、まずTerraformPullRequestの不正な作成と削除です。さらに、Burritoが持つgitとクラウドの認証情報を使った、意図しないterraform planが動きます。コードの解析では、その計画結果が本物のプルリクエストのコメント欄に投稿され、別ブランチのインフラ変更が他人に見えたうえ、投稿元も取り違えられると指摘されています。CVSSの可用性が高と評価されているのは、この計画の実行が負荷や妨害につながるためです。
ただし、これらの一時的なレイヤーでは自動適用が無効なので、この脆弱性だけでterraform applyは強制できません。一方、計画の実行中にはプロバイダーやデータソースのコードが動くことがあり、その影響は選ばれたブランチの中身で決まります。
今すぐやること
-
1
Burritoを0.13.0に更新する
修正版に更新します。Helmなどで導入している場合は、チャートの値を直したうえで、burrito-serverを含むすべてのコンポーネントのイメージが入れ替わったことを確認してください。
kubectl get deploy -A -o wide | grep -i burrito -
2
webhookSecretを全認証情報に設定する
更新と合わせて、TerraformRepositoryが参照するすべての認証情報に、空でないwebhookSecretを設定します。GitHubやGitLab側のWebhook設定にも同じ値を入れ、通知が届き続けることを確認してください。
-
3
不審な痕跡を確認する
身に覚えのないTerraformPullRequestや、意図しないブランチのplan実行がないか、リソースの作成履歴とBurritoのログを見ます。プルリクエストのコメントに、関係のない計画結果が投稿されていないかも確認してください。
-
4
受け口の公開範囲を見直す
burrito-serverのWebhook受け口を、GitHubやGitLabなど通知を送る側だけに絞れているかを確認します。
すぐ更新できないとき
すぐに更新できない場合は、全認証情報にwebhookSecretを設定し、GitHubやGitLab側にも同じ値を入れます。あわせて、burrito-serverのWebhook受け口へのアクセスを、通知を送る側のアドレスだけに制限してください。
背景
Burritoは、TerraformをKubernetesの上で自動実行するためのオペレーターです。プルリクエストごとに計画を実行して結果をコメントで返し、マージ後にapplyする流れを担います。そのため、gitの認証情報とクラウドの認証情報の両方を保持しています。
Webhookの受け口は、外部のサービスからの通知で処理を始める入口です。通常は共有の秘密の値で署名を検証し、通知が本物かどうかを確かめます。今回は、その秘密の値が任意の設定だったことが問題の出発点です。設定を省いても動いてしまうため、気づかないまま運用している環境があり得ます。
よくある質問
Q.webhookSecretをすでに設定している場合も、更新は必要ですか。
まだ分かっていないこと
- 実際の攻撃での悪用が確認されたかどうかは、公表されていません。
- 計画結果がプルリクエストのコメントに投稿される挙動は、コードの解析による指摘です。実環境での再現は示されていません。
- 0.13.0でどのような修正が入ったかの詳細は、ベンダーのアドバイザリと修正コミットで確認してください。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| padok-team | burrito | — | — |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Burrito is a Terraform Automation Collaboration Software (TACoS) Kubernetes operator. Prior to 0.13.0, POST /api/webhook accepts unsigned GitHub and GitLab events when a TerraformRepository's credentials omit webhookSecret or set it to an empty value, including credentials configured for git authentication and polling. Credential.WebhookSecret is optional, and go-playground/webhooks skips signature or token verification when the secret is empty. Anyone who can reach burrito-server's endpoint and knows a tracked repository's URL can forge events to create or delete TerraformPullRequest custom resources with attacker-chosen Branch, Base, and ID fields. For GitHub pull_request events, the controller fetches changed files using the real pull request number but does not cross-check the payload's branch against that pull request. Pairing a real, existing pull request number with an unrelated existing branch in the same repository can therefore cause an unauthorized terraform plan for affected layers using the operator's stored git and cloud credentials. Code analysis also indicates that the resulting plan can be posted to the real pull request's comment thread, exposing and misattributing another branch's infrastructure changes. Auto-apply is disabled for these temporary layers, so this vulnerability alone cannot force a terraform apply; plan-time provider and data-source code execution depends on the selected branch's contents. This issue is fixed in vers…
出典: CVE.org (CVE Program・cvelistV5) NVD
参照URL
- web github.com
- web github.com
- web github.com