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
Write-up: https://abraxaslabs.tech/research/prometheus-bearer-redirect
Klasse: Offenlegung von Anmeldedaten Reichweite: Remote
Prometheus v3.15.0 (5241a27) - CNCF / Prometheus
prometheus/common v0.71.0 entfernt bereits Scrape-/HTTPClientConfig-Anmeldedaten bei hostübergreifenden Redirects (isCrossHostRedirect, #901). NewWriteClient erstellt diesen Client zuerst und umschließt dann azuread.NewAzureADRoundTripper oder googleiam.NewRoundTripper außerhalb dieser Entfernung. 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 sowie 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 (Dump von client_secret unter /-/config). Das Standard-prometheus.yml enthält kein remote_write. Dies ist an azuread: oder google_iam: gebunden.
| ID | noch kein CVE |
| Klasse | Offenlegung von Anmeldedaten (remote_write Bearer bei hostübergreifendem 3xx) |
| Reichweite | Remote (ausgehend von Prometheus zu einem 3xx-Ziel) |
| CWE | CWE-201 |
| CVSS | Hoch: 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 | konfigurationsgebundenes remote_write mit azuread: oder google_iam: |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1 |
Der Betreiber hat remote_write mit azuread: oder google_iam: konfiguriert. Die RW-URL oder ein Zwischenschritt, auf den sie per 3xx weiterleitet, ist ein Host, den der Angreifer kontrolliert.
| Berechtigung | Methode / Sink | Im Lab nachgewiesen oder abgeleitet |
|---|---|---|
Den aktiven GCP-monitoring.write-Bearer bei einem hostübergreifenden 3xx auslesen | google_iam remote_write POST, 307 zu einem anderen Host | Im Lab nachgewiesen. Oracle POST /write erhielt Authorization: Bearer lab-gcp-PROMETHEUS-BEARER-REDIRECT-WITNESS |
Derselbe Leak für azuread | azureADRoundTripper.RoundTrip setzt stets Header.Set("Authorization", "Bearer "+token) ohne isCrossHostRedirect | Aus dem Quellcode der Version abgeleitet. Dieselbe Wrap-Stelle in NewWriteClient. Das Lab verwendete google_iam, daher wurde Azure nicht aufgerufen |
| Dieses Token als diese Identität gegen Azure Monitor / GCP Monitoring wiederverwenden | Das Token ist eine echte Cloud-Anmeldedaten, wenn diese Auth-Blöcke konfiguriert sind | Abgeleitet. Das Lab erzeugte ein Stub-Token; Azure oder GCP wurden nicht aufgerufen |
| Scrape / oauth2 / basic / bearer bei derselben Version | HTTPClientConfig-RoundTripper aus common v0.71.0 | Im Lab als geschlossen nachgewiesen. oauth2-Scrape-GET folgte einem 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; das Feld ist bei dieser Version als Secret typisiert | Geschlossen |
| Prometheus-Admin / Lifecycle | Flags standardmäßig aus | Geschlossen |
| RCE / eine Shell | nicht dieser Überrest | Geschlossen |
Ich habe das Tag v3.15.0 von prometheus/prometheus nach der Welle der Secret-Redaction und Snappy-Cap in 3.11/3.12 festgelegt. Neunzehn Untersuchungen. Standard-OSS: Admin-API, Lifecycle-HTTP, Remote-Write-Receiver und OTLP-Receiver aus. Common #901 ist in v0.71.0 enthalten. Der Überrest 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 SetAuthHeaders aufruft.
Bereits festgehaltene Fehlversuche: erneutes Einreichen von CVE-2026-42151; das Scrape-oauth2 weiterhin als leckend zu behandeln (das ist es nicht); dies als High bei Standardinstallation zu bezeichnen (das ist es nicht - remote_write ist leer, bis man es aktiviert). Theater: eine Reverse Shell. Das Orakel ist ein Bearer beim umgeleiteten 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-Datei gcp-sa.json mit token_uri: http://hop:8080/token, damit google_iam niemals mit Google kommuniziert.
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
Das Anhängen von Azure AD / Google IAM Bearer überspringen, wenn isCrossHostRedirect(req) gilt, wie bei common #901. Authorization nach einem hostübergreifenden 3xx nicht erneut setzen, nachdem Go es entfernt 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.