abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · 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 | 高危：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 重定向到另一台主机 | 实验验证。Oracle POST /write 收到了 Authorization: Bearer lab-gcp-PROMETHEUS-BEARER-REDIRECT-WITNESS |
azuread 的相同泄露 | azureADRoundTripper.RoundTrip 始终执行 Header.Set("Authorization", "Bearer "+token)，没有 isCrossHostRedirect | 根据固定版本源码推断。NewWriteClient 中相同的包装位置。实验使用了 google_iam，因此未调用 Azure |
| 以该身份对 Azure Monitor / GCP Monitoring 重放该令牌 | 当配置了这些认证块时，令牌是真实的云凭据 | 推断。实验铸造了一个桩令牌；未调用 Azure 或 GCP |
| 同一固定版本上的 scrape / oauth2 / basic / bearer | 来自 common v0.71.0 的 HTTPClientConfig RoundTripper | 实验验证已关闭。oauth2 scrape GET 跟随 302 到同一 oracle，没有 Authorization |
| 默认 OSS | remote_write 为空 | 已关闭 |
remote_write.headers 设置 Authorization | 被拒绝 | 已关闭 |
/-/config 转储 client_secret | CVE-2026-42151；该字段在此固定版本上类型为 Secret | 已关闭 |
| Prometheus 管理 / 生命周期 | 标志默认关闭 | 已关闭 |
| RCE / shell | 不是这个遗留问题 | 已关闭 |
在 3.11/3.12 密钥脱敏和 snappy 上限浪潮之后，我固定了 prometheus/prometheus 标签 v3.15.0。十九次搜寻。默认 OSS：admin API、生命周期 HTTP、remote-write receiver 和 OTLP receiver 均关闭。Common #901 已在 v0.71.0 中。遗留问题是位于该客户端之外的两个 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 仍然泄露（并非如此）；将此称为默认安装的高危（并非如此——在你开启之前 remote_write 为空）。表演：反向 shell。Oracle 是重定向 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 写入一个实验用 gcp-sa.json，其中 token_uri: http://hop:8080/token，因此 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。仅限回环实验环境。无担保。