abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · prometheus-bearer-redirect
解説記事: https://abraxaslabs.tech/research/prometheus-bearer-redirect
分類: 認証情報の漏洩 到達範囲: リモート
Prometheus v3.15.0 (5241a27) - CNCF / Prometheus
prometheus/common v0.71.0 は、クロスホストリダイレクト時に scrape / HTTPClientConfig の認証情報をすでに除去しています（isCrossHostRedirect、#901）。NewWriteClient はそのクライアントを先に構築し、その後で azuread.NewAzureADRoundTripper または googleiam.NewRoundTripper を除去処理の外側でラップします。follow_redirects は依然としてデフォルトで true です。
設定された remote_write URL が別ホストへ 301/302/307 リダイレクトすると、Prometheus は Authorization: Bearer と Azure AD または GCP の monitoring.write トークンをそのホストへ送信します。 Go はコピーされたヘッダーをすでに破棄していました。これらの RoundTripper がそれを再設定します。
CVE-2026-42151（/-/config での client_secret ダンプ）ではありません。デフォルトの prometheus.yml には remote_write がありません。これは azuread: または google_iam: が設定されている場合に限られます。
| ID | CVE 未割当 |
| 分類 | 認証情報の漏洩（クロスホスト 3xx 時の remote_write Bearer） |
| 到達範囲 | リモート（Prometheus から 3xx ターゲットへの外向き通信） |
| CWE | CWE-201 |
| CVSS | High: 8.6 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N |
| 製品 | Prometheus |
| 影響を受けるバージョン | v3.15.0 (5241a27fe3c6983549fccc32f6e65917408c63cd)、イメージ prom/prometheus:v3.15.0 |
| 認証 | 設定で有効化された remote_write（azuread: または google_iam: 付き） |
| ライセンス | GNU Affero GPL v3.0 |
| ラボ | 127.0.0.1 のみ |
運用者が azuread: または google_iam: 付きの remote_write を設定している。RW URL、またはその 3xx リダイレクト先のホストが攻撃者の管理下にある。
| 権限 | メソッド / シンク | ラボ実証済みか推測か |
|---|---|---|
クロスホスト 3xx 時に実際の GCP monitoring.write Bearer を読み取る | google_iam remote_write POST、別ホストへの 307 | ラボ実証済み。オラクルの POST /write が Authorization: Bearer lab-gcp-PROMETHEUS-BEARER-REDIRECT-WITNESS を受信した |
azuread でも同様の漏洩 | azureADRoundTripper.RoundTrip は常に Header.Set("Authorization", "Bearer "+token) を実行し、isCrossHostRedirect を伴わない | ピン留めしたソースからの推測。NewWriteClient 内の同じラップ箇所。ラボは google_iam を使用したため Azure は呼び出していない |
| そのトークンをその ID として Azure Monitor / GCP Monitoring に対してリプレイする | これらの認証ブロックが設定されている場合、トークンは実際のクラウド認証情報である | 推測。ラボはスタブトークンを生成したのみで、Azure や GCP は呼び出していない |
| 同じピンでの scrape / oauth2 / basic / bearer | common v0.71.0 の HTTPClientConfig RoundTripper | ラボ実証済みでクローズ。oauth2 scrape GET は同じオラクルへ 302 を追跡したが Authorization は付与されなかった |
| デフォルト OSS | remote_write は空 | クローズ |
remote_write.headers で Authorization を設定 | 拒否される | クローズ |
/-/config が client_secret をダンプ | CVE-2026-42151。このピンではフィールドは Secret 型 | クローズ |
| Prometheus の管理 / ライフサイクル | フラグはデフォルトでオフ | クローズ |
| RCE / シェル | この残存問題ではない | クローズ |
3.11/3.12 のシークレット秘匿化と snappy 上限の波の後、prometheus/prometheus のタグ v3.15.0 をピン留めしました。19 回の調査。デフォルト OSS では、admin API、ライフサイクル HTTP、remote-write レシーバー、OTLP レシーバーはオフです。Common #901 は v0.71.0 に含まれています。残存していたのは、そのクライアントの外側に位置する 2 つの remote_write ラッパーです。
func (rt *azureADRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
accessToken, err := rt.tokenProvider.getAccessToken(req.Context())
// ...
req.Header.Set("Authorization", bearerAccessToken)
return rt.next.RoundTrip(req)
}
googleiam.NewRoundTripper は google.golang.org/api/transport/http -> oauth2.Transport であり、これは各ホップで SetAuthHeader を実行します。
すでに記録済みの誤った判断: CVE-2026-42151 を再申請すること。scrape の oauth2 を依然として漏洩ありと扱うこと（そうではない）。これをデフォルトインストールでの High とすること（そうではない - remote_write は有効にするまで空である）。茶番: リバースシェル。オラクルはリダイレクトされた POST 上の Bearer である。
python3 prometheus-bearer-redirect-Abraxas-Labs.py
または
cd lab
./run.sh
ループバックのみ: Prometheus http://127.0.0.1:19380、oracle http://127.0.0.1:19381。イメージ prom/prometheus:v3.15.0。run.sh は token_uri: http://hop:8080/token を含むラボ用の gcp-sa.json を書き出すため、google_iam が Google と通信することはありません。
SUCCESS prometheus-bearer-redirect how=live rw-method=POST rw-bearer=yes token-has-witness=yes scrape-method=GET scrape-bearer=no PROMETHEUS-BEARER-REDIRECT-WITNESS
isCrossHostRedirect(req) の場合、Azure AD / Google IAM Bearer の付与をスキップします。これは common #901 と同様です。Go がクロスホストの 3xx で Authorization を削除した後、再度設定しないでください。
5241a27fe3c6983549fccc32f6e65917408c63cd)storage/remote/client.go · storage/remote/azuread/azuread.go · storage/remote/googleiam/googleiam.goGNU Affero GPL v3.0。LICENSE を参照してください。ループバックラボ専用です。保証はありません。