abraxas/prometheus-bearer-redirectPrometheus v3.15.0 – Hoch – Remote – Offenlegung von Anmeldedaten – remote_write google_iam/azuread leitet Bearer bei hostübergreifenden 3xx weiter
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · prometheus-bearer-redirect
Klasse: Credential-Leak Reichweite: Remote
Prometheus v3.15.0 (5241a27) - CNCF / Prometheus
prometheus/common v0.71.0 entfernt bereits Scrape-/HTTPClientConfig-Credentials bei Cross-Host-Redirects (isCrossHostRedirect, #901). NewWriteClient baut diesen Client zuerst und umhüllt dann azuread.NewAzureADRoundTripper oder googleiam.NewRoundTripper außerhalb des Strippings. follow_redirects ist weiterhin standardmäßig true.
Wenn die konfigurierte remote_write-URL per 301/302/307 auf einen anderen Host weiterleitet, sendet Prometheus Authorization: Bearer plus das Azure-AD- oder GCP-monitoring.write-Token an diesen Host. Go hat den kopierten Header bereits verworfen. Diese RoundTripper setzen ihn erneut.
Kein CVE-2026-42151 (client_secret-Dump auf /-/config). Die Standard-prometheus.yml hat kein remote_write. Dies ist gated auf azuread: oder google_iam:.
| ID | noch kein CVE |
| Klasse | Credential-Leak (remote_write Bearer bei Cross-Host-3xx) |
| Reichweite | Remote (ausgehend von Prometheus zu einem 3xx-Ziel) |
| 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 |
| Produkt | Prometheus |
| Betroffen | v3.15.0 (5241a27fe3c6983549fccc32f6e65917408c63cd), Image prom/prometheus:v3.15.0 |
| Auth | config-gated remote_write mit azuread: oder google_iam: |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1 |
Der Operator hat remote_write mit azuread: oder google_iam:. Die RW-URL oder ein Hop, auf den sie per 3xx weiterleitet, ist ein Host, den der Angreifer kontrolliert.
| Privileg | Methode / Sink | Lab-belegt oder abgeleitet |
|---|---|---|
Den aktiven GCP-monitoring.write-Bearer bei einem Cross-Host-3xx auslesen | google_iam remote_write POST, 307 zu einem anderen Host | Lab-belegt. Oracle POST /write erhielt Authorization: Bearer lab-gcp-PROMETHEUS-BEARER-REDIRECT-WITNESS |
Derselbe Leak für azuread | azureADRoundTripper.RoundTrip setzt immer Header.Set("Authorization", "Bearer "+token) ohne isCrossHostRedirect | Abgeleitet aus dem Pin-Quellcode. Dieselbe Wrap-Stelle in NewWriteClient. Das Lab nutzte google_iam, daher wurde Azure nicht aufgerufen |
| Dieses Token gegen Azure Monitor / GCP Monitoring als diese Identität wiederverwenden | Das Token ist eine echte Cloud-Credential, wenn diese Auth-Blöcke konfiguriert sind | Abgeleitet. Das Lab erzeugte ein Stub-Token; Azure oder GCP wurden nicht aufgerufen |
| Scrape / oauth2 / basic / bearer auf demselben Pin | HTTPClientConfig-RoundTripper aus common v0.71.0 | Lab-belegt geschlossen. oauth2-Scrape-GET folgte 302 zum selben Oracle ohne Authorization |
| Standard-OSS | remote_write leer | Geschlossen |
remote_write.headers setzt Authorization | abgelehnt | Geschlossen |
/-/config gibt client_secret aus | CVE-2026-42151; Feld ist auf diesem Pin als Secret typisiert | Geschlossen |
| Prometheus-Admin / Lifecycle | Flags standardmäßig aus | Geschlossen |
| RCE / eine Shell | nicht dieser Rest | Geschlossen |
Ich habe den prometheus/prometheus-Tag v3.15.0 nach der 3.11/3.12-Welle aus Secret-Redaction und Snappy-Cap gepinnt. Neunzehn Hunts. Standard-OSS: Admin-API, Lifecycle-HTTP, Remote-Write-Receiver und OTLP-Receiver aus. Common #901 ist in v0.71.0. Der Rest sind die beiden remote_write-Wrapper, die außerhalb dieses Clients liegen.
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 ist google.golang.org/api/transport/http -> oauth2.Transport, das bei jedem Hop SetAuthHeader aufruft.
Bereits dokumentierte Irrwege: CVE-2026-42151 erneut einreichen; Scrape-oauth2 als weiterhin leckend behandeln (ist es nicht); dies als High bei Standardinstallation bezeichnen (ist es nicht - remote_write ist leer, bis man es aktiviert). Theater: eine Reverse Shell. Das Oracle ist ein Bearer auf dem weitergeleiteten POST.
python3 prometheus-bearer-redirect-Abraxas-Labs.py
oder
cd lab
./run.sh
Nur Loopback: Prometheus http://127.0.0.1:19380, Oracle http://127.0.0.1:19381. Image prom/prometheus:v3.15.0. run.sh schreibt eine Lab-gcp-sa.json mit token_uri: http://hop:8080/token, damit google_iam nie mit Google spricht.
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
Azure AD / Google IAM Bearer überspringen, wenn isCrossHostRedirect(req) gilt, genau wie in common #901. Authorization nicht erneut setzen, nachdem Go es bei einem Cross-Host-3xx verworfen hat.
5241a27fe3c6983549fccc32f6e65917408c63cd)storage/remote/client.go · storage/remote/azuread/azuread.go · storage/remote/googleiam/googleiam.goGNU Affero GPL v3.0. Siehe LICENSE. Nur Loopback-Lab. Keine Gewährleistung.