I've made over 100k on SSRF vulnerabilities.
They aren't always as simple as pointing it at localhost or AWS Metadata service.
Here are some tricks I've picked up over the past 5 years of web app testing:
They aren't always as simple as pointing it at localhost or AWS Metadata service.
Here are some tricks I've picked up over the past 5 years of web app testing:
* Check all schemes (http, https, file, ftp, gopher, etc)
Sometimes there are restrictions in-place on http that are not there in https or vice versa. See link below.
Or, if you can hit schemes like file or FTP -> local filesystem access.
github.com
Sometimes there are restrictions in-place on http that are not there in https or vice versa. See link below.
Or, if you can hit schemes like file or FTP -> local filesystem access.
github.com
* Open Redirect (when the target is limited)
When the target of a SSRF-ish request is limited to a particular domain, you can often bypass this with redirects. You can check if an endpoint is vulnerable by hitting a redir within the app and seeing if it follows.
When the target of a SSRF-ish request is limited to a particular domain, you can often bypass this with redirects. You can check if an endpoint is vulnerable by hitting a redir within the app and seeing if it follows.
* Try all redirect status codes (301, 302, 303, 307, 308, ect)
When you are hitting your own server with the request, try redirecting to sensitive locations using all of the HTTP redirect status codes. I've seen many times where some will work and others will not.
When you are hitting your own server with the request, try redirecting to sensitive locations using all of the HTTP redirect status codes. I've seen many times where some will work and others will not.
* Alternative URL structuring
This is a BIG one. You must know how the URL is formatted.
Biggest wins normally come from using the @ symbol, backslashes where unexpected, and smuggling stuff in after the : in the ports section.
This is a BIG one. You must know how the URL is formatted.
Biggest wins normally come from using the @ symbol, backslashes where unexpected, and smuggling stuff in after the : in the ports section.
* URL encoding (1x,2x,3x)
Using multiple layers of URL encoding can allow for bypassing of restrictions. I normally just check 1 or 2 layers, but I've seen a report recently where only 3 worked. Not a big deal to encode one more time.
Using multiple layers of URL encoding can allow for bypassing of restrictions. I normally just check 1 or 2 layers, but I've seen a report recently where only 3 worked. Not a big deal to encode one more time.
* "." regex validation issue
A regex /a.test.com/ also matches aXtest[.]com. If a target for an SSRF is limiting you to a specific domain, then try to insert any char where the "." is. If it goes through, you buy the domain and point it where ever you want. Boom.
A regex /a.test.com/ also matches aXtest[.]com. If a target for an SSRF is limiting you to a specific domain, then try to insert any char where the "." is. If it goes through, you buy the domain and point it where ever you want. Boom.
* DNS rebinding
This is a bit more challenging of a technique, but a good one nonetheless. When a target is resolving the domain to make sure that it's not pointing to localhost or other internal domains, you may be able to bypass this with DNS rebinding. Great attack.
This is a bit more challenging of a technique, but a good one nonetheless. When a target is resolving the domain to make sure that it's not pointing to localhost or other internal domains, you may be able to bypass this with DNS rebinding. Great attack.
* Hitting semi-internal hosts
While you may not be able to hit localhost or other private IP space, try hitting servers that are in the DMZ which are not accessible externally, but when requested from inside the network don't have the same protections.
While you may not be able to hit localhost or other private IP space, try hitting servers that are in the DMZ which are not accessible externally, but when requested from inside the network don't have the same protections.
* Time-based enumeration of subnets due to routing timeouts
You can try to enumerate which local IP subnets you can access by a timing attack. If there is a routing issue, it often takes longer to timeout. If it returns back quickly, then you may have found a valid subnet.
You can try to enumerate which local IP subnets you can access by a timing attack. If there is a routing issue, it often takes longer to timeout. If it returns back quickly, then you may have found a valid subnet.
* Use different localhost addresses (0.0.0.0, 127.0.0.2, etc)
Sometimes there is just a simple blacklist in place to prevent SSRF. In cases like this, it's trivial to bypass these by using alternative IP addresses.
Sometimes there is just a simple blacklist in place to prevent SSRF. In cases like this, it's trivial to bypass these by using alternative IP addresses.
* IPv6 addresses
Sometimes you can use IPv6 addresses to bypass restrictions on which IPs you can communicate with.
Sometimes you can use IPv6 addresses to bypass restrictions on which IPs you can communicate with.
* Octal and other alternative IP encodings
Many people dont know that you can encode IPs in all sorts of ways. Check out this article to see how you may be able to bypass SSRF limitations with these funky encodings:
hacksparrow.com
Many people dont know that you can encode IPs in all sorts of ways. Check out this article to see how you may be able to bypass SSRF limitations with these funky encodings:
hacksparrow.com
That's it for now. LMK if I missed anything!
Retweet the first tweet if any:
Retweet the first tweet if any:
Loading suggestions...