abraxas/prometheus-bearer-redirectPrometheus v3.15.0 - Alta - Remoto - Fuga de credenciales - remote_write google_iam/azuread reenvía Bearer en 3xx entre hosts
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · prometheus-bearer-redirect
Análisis: https://abraxaslabs.tech/research/prometheus-bearer-redirect
Clase: Fuga de credenciales Alcance: Remoto
Prometheus v3.15.0 (5241a27) - CNCF / Prometheus
prometheus/common v0.71.0 ya elimina las credenciales de scrape / HTTPClientConfig en redirecciones entre hosts distintos (isCrossHostRedirect, #901). NewWriteClient construye primero ese cliente y luego envuelve azuread.NewAzureADRoundTripper o googleiam.NewRoundTripper por fuera de esa eliminación. follow_redirects sigue teniendo true por defecto.
Si la URL de remote_write configurada responde 301/302/307 hacia otro host, Prometheus envía Authorization: Bearer junto con el token monitoring.write de Azure AD o GCP a ese host. Go ya había descartado la cabecera copiada. Estos RoundTrippers la vuelven a establecer.
No es CVE-2026-42151 (volcado de client_secret en /-/config). El prometheus.yml por defecto no tiene remote_write. Esto está condicionado a azuread: o google_iam:.
| ID | aún sin CVE |
| Clase | Fuga de credenciales (Bearer de remote_write en 3xx entre hosts distintos) |
| Alcance | Remoto (saliente desde Prometheus hacia un objetivo 3xx) |
| CWE | CWE-201 |
| CVSS | Alto: 8.6 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N |
| Producto | Prometheus |
| Afectado | v3.15.0 (5241a27fe3c6983549fccc32f6e65917408c63cd), imagen prom/prometheus:v3.15.0 |
| Autenticación | remote_write condicionado por configuración con azuread: o google_iam: |
| Licencia | GNU Affero GPL v3.0 |
| Laboratorio | solo 127.0.0.1 |
El operador tiene remote_write con azuread: o google_iam:. La URL de RW, o un salto al que esta responde con 3xx, es un host controlado por el atacante.
| Privilegio | Método / destino | Demostrado en laboratorio o inferido |
|---|---|---|
Leer el Bearer monitoring.write de GCP en vivo en un 3xx entre hosts distintos | POST de google_iam remote_write, 307 hacia otro host | Demostrado en laboratorio. El oráculo POST /write recibió Authorization: Bearer lab-gcp-PROMETHEUS-BEARER-REDIRECT-WITNESS |
La misma fuga para azuread | azureADRoundTripper.RoundTrip siempre hace Header.Set("Authorization", "Bearer "+token) sin isCrossHostRedirect | Inferido a partir del código fijado. El mismo punto de envoltura en NewWriteClient. El laboratorio usó google_iam, por lo que no invocó Azure |
| Reutilizar ese token contra Azure Monitor / GCP Monitoring con esa identidad | El token es una credencial de nube real cuando esos bloques de autenticación están configurados | Inferido. El laboratorio generó un token simulado; no invocó Azure ni GCP |
| Scrape / oauth2 / basic / bearer en el mismo código fijado | RoundTrippers de HTTPClientConfig de common v0.71.0 | Demostrado cerrado en laboratorio. El GET de scrape oauth2 siguió un 302 hacia el mismo oráculo sin Authorization |
| OSS por defecto | remote_write vacío | Cerrado |
remote_write.headers estableciendo Authorization | rechazado | Cerrado |
/-/config volcando client_secret | CVE-2026-42151; el campo está tipado como Secret en este código fijado | Cerrado |
| Admin / ciclo de vida de Prometheus | flags desactivados por defecto | Cerrado |
| RCE / una shell | no es este remanente | Cerrado |
Fijé la etiqueta v3.15.0 de prometheus/prometheus tras la oleada de redacción de secretos y límites de snappy de 3.11/3.12. Diecinueve búsquedas. OSS por defecto: API de admin, ciclo de vida HTTP, receptor de remote-write y receptor OTLP desactivados. Common #901 está en v0.71.0. El remanente son los dos envoltorios de remote_write que quedan fuera de ese cliente.
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 es google.golang.org/api/transport/http -> oauth2.Transport, que aplica SetAuthHeader en cada salto.
Errores ya registrados: volver a presentar CVE-2026-42151; tratar el oauth2 de scrape como aún con fuga (no lo es); llamar a esto un Alto de instalación por defecto (no lo es - remote_write está vacío hasta que lo activas). Teatro: una reverse shell. El oráculo es un Bearer en el POST redirigido.
python3 prometheus-bearer-redirect-Abraxas-Labs.py
o
cd lab
./run.sh
Solo loopback: Prometheus http://127.0.0.1:19380, oracle http://127.0.0.1:19381. Imagen prom/prometheus:v3.15.0. run.sh escribe un gcp-sa.json de laboratorio con token_uri: http://hop:8080/token para que google_iam nunca hable con 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
Omitir la inclusión del Bearer de Azure AD / Google IAM cuando isCrossHostRedirect(req), igual que en common #901. No volver a establecer Authorization después de que Go lo haya eliminado en un 3xx entre hosts distintos.
5241a27fe3c6983549fccc32f6e65917408c63cd)storage/remote/client.go · storage/remote/azuread/azuread.go · storage/remote/googleiam/googleiam.goGNU Affero GPL v3.0. Consulte LICENSE. Solo para laboratorio en loopback. Sin garantía.