Detecting SSRF Using AWS Services

Server Side Request Forgery (SSRF) is a fun vulnerability, its impact ranges from information disclosure via service detection to root. There are lots of good resources about SSRF out there, acunetix has a good blog post for understanding what the vulnerability is while Orange Tsai shows what can be accomplished using the vulnerability.

Detecting SSRF can be tricky, especially when protections against it have been implemented. During a pentest and when checking for SSRF it is extremely helpful to have control of a public web server which can accept incoming requests to see if the target application can be forced to make an outbound call to your external server and determine which payloads caused that to happen. It's also important to be able to configure redirect responses, for example, http://smeegesec.com could give a 302 Redirect to http://localhost:80 which may bypass protections the target application/server has implemented. An easy (and FREE!) way of doing this is using Amazon Web Services free tier.

To assist with SSRF testing I configured and used:

• AWS EC2 Instance
• Amazon S3 Bucket w/ Static website hosting

Even if you have no AWS experience it's pretty easy to get started. I won't go into too much detail in this post on how to setup and configure everything but this should be more than enough to get going:

• AWS EC2 Setup
• Launch and Connect to AWS EC2 Instance
• Note: The correct inbound/outbound rules must be configured in the Security Group to allow communication to certain ports (ie. tcp/80)

Public Web Server using AWS EC2

Running a simple http server from AWS allows us to test the potentially vulnerable application to see if external requests are supported and the various URL formatting/encoding which is accepted.

• SSH to the ec2 instance: ssh -i "<key>.pem" ec2-user@<PublicDNS>
• Start a python web server from an empty temp directory: sudo python –m SimpleHTTPServer
• Navigate to the ec2 instance in your AWS to get the public IP address.
  
• You can now make calls to http://<public-ip>:<port> assuming the correct inbound/outbound rules have been configured to allow it.

Public Endpoint using Amazon S3 Bucket

S3 Buckets are useful as they are easy to configure and allow for customizable redirects. For instance, we can configure our S3 bucket endpoint to redirect to http://localhost:80 or similar.

• Create an Amazon S3 Bucket
• Select the bucket and enable “Properties > Static Web Hosting”
• Here you will see your endpoint URL listed at the top with two options:
  • Use this bucket to host a website – This option allows us to utilize custom routing rules to determine what type of redirect is performed. I uploaded a demo index.html file and implemented the following routing rules:
    

    <RoutingRules>
      <RoutingRule>
        <Redirect>
          <Protocol>http</Protocol>
          <HostName>127.0.0.1</HostName>
          <HttpRedirectCode>302</HttpRedirectCode>
        </Redirect>
      </RoutingRule>
    </RoutingRules>
    

    For additional information regarding routing rules, see: http://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html
  • Redirect Requests – Simply redirects ALL requests to a different domain using a 301 redirect code.

Restriction Bypasses

After attempting simple SSRF payloads such as “http://scanme.nmap.org:22”, “http://localhost:80”, “http://169.254.169.254” and to our public web server, there may be a need to bypass restrictions the application or server has in place to prevent SSRF (some target applications may even be nice enough to throw a common error when the URL is invalid).
The ip.py script can be used to take a URL and encode it in various ways. The script can be found here: https://github.com/cujanovic/SSRF-Testing/blob/master/ip.py. The script takes the input of an IP and Port in addition to a valid domain which the application/server would typically allow (if it allows your public web server we can again check which requests actually hit it): python ip.py 127.0.0.1 80 www.google.com
The output is around 240 payloads which can be used to check for SSRF. It would be very easy to take this output and use Burp Intruder to quickly determine which payloads may have been accepted.

These payloads can also be configured as a redirect endpoint in AWS (see above) which makes for lots of options to potentially bypass any SSRF restrictions.

Additional Resources

• https://github.com/cujanovic/SSRF-Testing
• http://blog.safebuff.com/2016/07/03/SSRF-Tips/
• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SSRF%20injection
• https://www.hackerone.com/blog-How-To-Server-Side-Request-Forgery-SSRF
• https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit
• https://cfdb.io/Web/Server-Side%20Request%20Forgery