Think of it this way, with an SSRF request, you can make requests "on-behalf" of the vulnerable server!
Thus the primary target of an SSRF request if an internal system that you normally wouldn't have access to, but since you can make requests "on-behalf" of the vulnerable server, since that vulnerable server has access to an internal system, you now can make a request to that other internal system. As an example you could
1.) Make SSRF attack request to internet facing Web Server X
2.) If vulnerable, Web Server X would turn around and run your scan/exploit attack against internal non-internet facing Application Server Y
Now the attack you run could vary from this like ...
- Recon (where you try to enumerate all the internal non-accessible devices)
- Scans (where you try identify vulnerabilities that exist on an internal non-accessible device)
- Exploit (where you try to exploit a vulnerabilty and compromise an internal non-accessible device)
All of those requests would come on behalf of the vulnerable server so it would appear as if the vulnerable web server is making the requests when in actuality the external attacker is making the requests.
For this particular vBulletin vulnerability, it can be mitigated by applying the appropriate patches.
At a higher level, to minimize the damage of an SSRF vulnerabilty in your environment, make sure you're applying network segmentation, firewall rules, ip filtering, least privilege, etc. so that even if the attacker finds an SSRF vulnerability and starts making requests on behalf of your vulnerable server, the attacker can only access, scan, and exploit the devices that the vulnerable server has access to ... which hopefully is a small subset of your actual internal environment.
More about neonprimetime
Top Blogs of all-time
- pagerank botnet sql injection walk-thru
- DOM XSS 101 Walk-Through
- An Invoice email and a Hot mess of Java
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
No comments:
Post a Comment