abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  prometheus-bearer-redirect

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 पहले ही कॉपी किए गए हेडर को हटा चुका है। ये RoundTrippers इसे फिर से सेट कर देते हैं।

यह 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	लैब-प्रमाणित। 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 के विरुद्ध रीप्ले करना	जब वे auth ब्लॉक कॉन्फ़िगर होते हैं तो टोकन एक वास्तविक क्लाउड क्रेडेंशियल होता है	अनुमानित। लैब ने एक स्टब टोकन बनाया; इसने Azure या GCP को कॉल नहीं किया
उसी पिन पर scrape / oauth2 / basic / bearer	common v0.71.0 से HTTPClientConfig RoundTrippers	लैब-प्रमाणित बंद। oauth2 scrape GET ने उसी oracle पर 302 का अनुसरण किया, बिना Authorization के
डिफ़ॉल्ट OSS	remote_write खाली	बंद
remote_write.headers में Authorization सेट करना	अस्वीकृत	बंद
/-/config द्वारा client_secret डंप करना	CVE-2026-42151; इस पिन पर फ़ील्ड Secret टाइप का है	बंद
Prometheus admin / lifecycle	फ्लैग डिफ़ॉल्ट रूप से बंद	बंद
RCE / एक शेल	यह बचा हुआ नहीं	बंद

मैंने इसे कैसे खोजा

मैंने 3.11/3.12 सीक्रेट-रिडैक्शन और snappy-cap लहर के बाद prometheus/prometheus टैग v3.15.0 को पिन किया। उन्नीस खोजें। डिफ़ॉल्ट OSS: admin API, lifecycle 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 को अभी भी लीकी मानना (यह नहीं है); इसे डिफ़ॉल्ट-इंस्टॉल High कहना (यह नहीं है - जब तक आप इसे चालू नहीं करते, remote_write खाली रहता है)। नाटक: एक रिवर्स शेल। 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। क्रॉस-होस्ट 3xx पर Go द्वारा Authorization हटाने के बाद इसे फिर से सेट न करें।

संदर्भ

• github.com/prometheus/prometheus टैग v3.15.0 (5241a27fe3c6983549fccc32f6e65917408c63cd)
• storage/remote/client.go · storage/remote/azuread/azuread.go · storage/remote/googleiam/googleiam.go
• prometheus/common #901
• निकटवर्ती पैच किया गया (यह रैप नहीं): CVE-2026-42151
• CWE-201

लाइसेंस

GNU Affero GPL v3.0। देखें LICENSE। केवल लूपबैक लैब। कोई वारंटी नहीं।