Server-Side Request Forgery [CWE-918] — The Hacktivists

Server-Side Request Forgery or SSRF describes a case where the attacker can leverage the ability of a web application to perform unauthorized requests to internal or external systems.

Table of Content
1. Description
2. Potential impact
3. Affected software
4. Exploitation Examples
5. Severity and CVSS Scoring

1. Description
………………………………

Server-side request forgery or SSRF leverages the ability of a web application to perform unauthorized requests to internal or external systems.

If the web application contains functionality that sends requests to other servers and the attacker can interfere with it, it is possible to turn your web server into a proxy.

Depending on the configuration of the webserver, an attacker can reach systems that are otherwise behind a firewall, or access private resources on the localhost itself.

2. Potential impact
………………………………

The severity can vary from low to critical, depending on what the affected functionality can reach, either internally or externally.

Internal Service Interaction:

This is due to the vulnerable web application being used to interact with certain internal services, which in certain cases do not require authentication. Such examples are MongoDB and Redis. The impact can vary from minor information disclosure to database access, and even to remote code execution.

Information Disclosure:

Information disclosure via a port scan of internal hosts and enumeration of returned service banners is a common example. In some cases, the verbose error message will be returned to indicate the status of the port, in other cases a time-based approach must be used.

If the web application is being hosted via a hosting provider, it is possible to disclose its instance metadata, such as public SSH keys, credentials, and private IP address blocks.

Local File Disclosure:

The vulnerability can also be used in some cases to read the contents of local files on the webserver. This is achieved by using an alternate handler: ‘file://’. This can also lead to web application source code, configuration files, and various other sensitive files being read by an attacker.

Phishing:

SSRF can be used in conjunction with HTTP redirects to redirect a victim to a malicious web page. This can be used to serve malware, to harvesting credentials.

3. Affected software
………………………………

Any code residing on the webserver that an attacker can manipulate to insert arbitrary locations. This includes base web application functionality or third-party components.

4. Exploitation Examples
……………………………………..

Case One: A typical exploitation scenario for web applications hosted on hosting provider platforms such as Amazon EC2 and Digital Ocean is to request the instance metadata service of each provider, which returns information about the hosted instance, such as the private IP subnet, OpenSSH public keys, and account details.

An example request is as follows, the ‘url’ HTTP GET parameter is part of a vulnerable script that queries a remote URL and returns its contents to the page, in this case, it will return the Amazon EC2 instance’s public OpenSSH key:

GET /search.php/?url=http://[host]/latest/meta-data/public-keys/0/openssh-key HTTP/1.1
Host: companyx.com
Content-Type: text/html

Case Two: Another common example is for the vulnerable application to be used to read local files that the webserver has the relevant access rights to. Examples could be database credentials, web application source code, SSH keys, or configuration files.

The format of the following example request is the same as above. In this case, it will return the ‘/etc/passwd’ UNIX file, revealing the users of the underlying system. Note that the ‘file://’ handler is used instead of ‘https://', this references local files:

GET /search.php/?url=file:///etc/passwd HTTP/1.1
Host: companyx.com
Content-Type: text/html

5. Severity and CVSS Scoring
……………………………………..

The nature of what can be determined and accessed via the SSRF vulnerability will dictate the overall CVSS score. A few examples are shown below:

If a level of privilege is required to exploit the vulnerability, and the SSRF vulnerability can be used to access the cloud host instance metadata and return credentials that can be used to access the instance, it should be scored as follows:

8.8 [CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H] — High severity.

If no privilege is required, and the SSRF vulnerability can be used to determine open ports on the webserver hosting the web application and other internal subnets, it should be scored as follows:

5.3 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N] — Medium severity.

If no privilege is required, and the SSRF vulnerability can be used to read local files from the webserver (in this example, files that reveal sensitive information), it should be scored as follows:

7.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N] — High Severity

Credits: https://www.immuniweb.com/