# SSRF on https://whitehataudit.slack.com/account/photo

Slack's /account/photo endpoint fetched attacker-supplied URLs via libcurl, enabling SSRF with arbitrary ports and dangerous wrappers (gopher, dict, ldap, telnet, pop3).

- Payout: hidden
- Severity: high
- Program: Slack
- Found by: 4lemon
- Disclosed: 2014-12-21
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/14127
- Library page: https://bugbountylibrary.com/r/h1%3A14127
- Tags: area:web domain:web impact:internal-access kind:bounty platform:hackerone sev:high tech:curl technique:recon vuln:ssrf

**Target:** Web endpoint /account/photo image-fetch (libcurl backend)
**Root cause:** The photo-crop feature fetched a user-supplied url parameter server-side without restricting ports or disabling libcurl protocol wrappers.
**Steps:**
1. Send `POST /account/photo` with body `crumb=...&crop=1&url=dict%3A%2F%2F95.211.198.76%3A6666%2Fpicture-54679.jpg&cropbox=0%2C0%2C85`
2. Listen with `nc -lvv 6655` and observe Slackbot (AWS IP) connecting and issuing `GET /picture-54679.jpg`
3. Swap the scheme to `gopher://`, `dict://`, `ldap://`, `telnet://`, `pop3://` to confirm wrappers are enabled
4. Use response timing to port-scan internal hosts
**How found:** Noticed the crop feature accepted a url parameter and tested whether the server would fetch an attacker-controlled host, then probed which libcurl wrappers remained enabled.
**Exploitation:** Attacker controls the url parameter; Slack's backend (libcurl 7.22.0) connects to arbitrary host:port and speaks arbitrary protocols, allowing internal port scanning and interaction with internal services.
**Insight:** When an image-fetch/crop feature takes a url param, test non-http schemes (gopher, dict, ldap) and non-standard ports — libcurl wrappers often survive naive http-only validation.