Zero-Day Research: Ezgif Server Side Request Forgery

Web applications are quite powerful and diverse in their functionality. I can’t imagine anyone could have predicted how fast web technology could forge its way into every sector of business in the world. It seems as if every day a new type of widget, app, and social networking site are created to appeal to a new group of consumers. Driven by our urge to create something new and captivating, the forward push of web and mobile technology has without a doubt created the largest landscape for security and privacy abuse. As new software comes out, new vulnerabilities follow. Server Side Request Forgery is one of those web vulnerabilities that aren’t particularly new but have managed to stick around for the long haul.

Disclosure and Disclaimer

The Server Side Request Forgery vulnerability was responsibly disclosed to the Ezgif security team. This post was intended for web developers who are interested in keeping their applications secure and is for EDUCATIONAL PURPOSES ONLY. I do not condone illegal activity and cannot be held responsible for the misuse of this information.

What is Server Side Request Forgery?

According to the Open Web Application Security Project, “SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).”

Essentially this vulnerability class enables an attacker to convince a web server to reach out and grab content on the attacker’s behalf. Let’s break this down with an example using the following URL:

http://example.com?url=http://evilurl.com
  1. The attacker makes a request to http://example.com?url=http://evilurl.com.
  2. The web server extracts the value of the URL parameter (http://evilurl.com).
  3. The web server makes an HTTP request of its own, reaching out to http://evilurl.com and downloading the necessary content from that page.
  4. The web server displays the downloaded content back to the attacker.

Why is Server Side Request Forgery a Security Bug?

SSRF is a security issue because the attacker can convince the web server to leak sensitive information they typically would not have access to. The best way to understand this is to give a few scenarios using the example URL from above:

Scenario 1: Using alternate URL schemes to download certificates, SSH Keys, passwords, and other sensitive files.

http://example.com?url=file:///etc/passwd
http://example.com?url=ldap://localhost:11211/%0astats%0aquit

Scenario 2: Port scanning internal networks.

http://example.com?url=http://localhost:22
http://example.com?url=http://localhost:443
http://example.com?url=http://localhost:445

Scenario 3: Accessing data on cloud instances

http://example.com?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

These examples only scratch the surface of what’s possible with SSRF. For substantial list of possibilities, check out Payloads All The Things.

Ezgif Server Side Request Forgery

While I was converting a GIF to an MP4 file I discovered an SSRF vulnerability in the file upload page of Ezgif’s website. Any time you allow a user to upload from a URL without sanitizing the input you run the risk of SSRF.

To confirm this vulnerability we set up a publicly routable reverse proxy, input the address of our reverse proxy, and wait for the request to come through.

Mitigations

OWASP regularly posts mitigations for SSRF vulnerabilities. A snippet of those mitigations can be seen below: