an exploit of Server-side request forgery (SSRF)
Note this project is done...
Our instagram page
.
Our youtube chanel
.
Our twitter page
In this section, we'll explain what server-side request forgery is, describe some common examples, and explain how to find and exploit various kinds of SSRF vulnerabilities.
Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make requests to an unintended location.
In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.
Server-Side Request Forgery, also known as SSRF refers to an attack which lets an attacker send crafted requests from the back-end server of a vulnerable web application.
SSRF is commonly used by attackers to target internal networks that are behind firewalls and can not be reached from the external network.
SSRF vulnerabilities occur when the attacker has full or partial control of the request sent by the web application. If the vulnerable web application processes the user-supplied URLs then the application is vulnerable to SSRF attacks.
Cross-Site Port Attack (XSPA) is also a part of SSRF. In XSPA, an attacker can scan the open port of a targeted web server with the help of a vulnerable web application which is processing the user’s URL.
SSRF attacks often exploit trust relationships to escalate an attack from the vulnerable application and perform unauthorized actions. These trust relationships might exist in relation to the server itself, or in relation to other back-end systems within the same organization.
If the user-supplied URL is processed and the back-end response is not sanitised then the attack can lead to several impacts like:
-
Port scanning: A user can scan the port of a particular website through the vulnerable web application which is processing the user’s URL.
-
Fingerprinting intranet.
-
Attacking internal or external web applications.
-
Reading local web server files using the file:/// protocol handler.
-
In some cases, a successful SSRF attack can even lead to Remote Code Execution (RCE).
In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. This will typically involve supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter).
For example, consider a shopping application that lets the user view whether an item is in stock in a particular store. To provide the stock information, the application must query various back-end REST APIs, dependent on the product and store in question. The function is implemented by passing the URL to the relevant back-end API endpoint via a front-end HTTP request. So when a user views the stock status for an item, their browser makes a request like this:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
This causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user.
In this situation, an attacker can modify the request to specify a URL local to the server itself. For example:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/admin
Here, the server will fetch the contents of the /admin URL and return it to the user.
Now of course, the attacker could just visit the /admin URL directly. But the administrative functionality is ordinarily accessible only to suitable authenticated users. So an attacker who simply visits the URL directly won't see anything of interest. However, when the request to the /admin URL comes from the local machine itself, the normal access controls are bypassed. The application grants full access to the administrative functionality, because the request appears to originate from a trusted location.
Why do applications behave in this way, and implicitly trust requests that come from the local machine? This can arise for various reasons:
- The access control check might be implemented in a different component that sits in front of the application server. When a connection is made back to the server itself, the check is bypassed.
- For disaster recovery purposes, the application might allow administrative access without logging in, to any user coming from the local machine. This provides a way for an administrator to recover the system in the event they lose their credentials. The assumption here is that only a fully trusted user would be coming directly from the server itself.
- The administrative interface might be listening on a different port number than the main application, and so might not be reachable directly by users. These kind of trust relationships, where requests originating from the local machine are handled differently than ordinary requests, is often what makes SSRF into a critical vulnerability.
Another type of trust relationship that often arises with server-side request forgery is where the application server is able to interact with other back-end systems that are not directly reachable by users. These systems often have non-routable private IP addresses. Since the back-end systems are normally protected by the network topology, they often have a weaker security posture. In many cases, internal back-end systems contain sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems.
In the preceding example, suppose there is an administrative interface at the back-end URL https://192.168.0.68/admin. Here, an attacker can exploit the SSRF vulnerability to access the administrative interface by submitting the following request:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/admin
It is common to see applications containing SSRF behavior together with defenses aimed at preventing malicious exploitation. Often, these defenses can be circumvented.
Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent the filter using various techniques:
- Using an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.
- Registering your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose.
- Obfuscating blocked strings using URL encoding or case variation.
- Providing a URL that you control, which subsequently redirects to the target URL. Try using different redirect codes, as well as different protocols for the target URL. For example, switching from an http: to https: URL during the redirect has been shown to bypass some anti-SSRF filters.
Some applications only allow input that matches, begins with, or contains, a whitelist of permitted values. In this situation, you can sometimes circumvent the filter by exploiting inconsistencies in URL parsing.
The URL specification contains a number of features that are liable to be overlooked when implementing ad hoc parsing and validation of URLs:
- You can embed credentials in a URL before the hostname, using the @ character. For example:
https://expected-host:fakepassword@evil-host
- You can use the # character to indicate a URL fragment. For example:
https://evil-host#expected-host
- You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example:
https://expected-host.evil-host
- You can URL-encode characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request. Note that you can also try double-encoding characters; some servers recursively URL-decode the input they receive, which can lead to further discrepancies.
- You can use combinations of these techniques together.
an exploit of Server-side request forgery (SSRF)
- alibaba
- aws
- consul
- docker
- gce
- mysql
- networkscan
- portscan
- readfiles
- redis
- socksproxy
- digitalocean
- httpcollaborator
- smtp
- zabbix
- smbhash
- fastcgi
- custom
- github
- template
- tomcat
- memcache
- postgres
Whilst I was the main developer of this project, this project couldn't of even started without the help of these open source projects, special thanks to:
This is an example of how you may give instructions on setting up your project locally. To get a local copy up and running follow these simple example steps.
This program has no pre-requisites
- Clone the repo
git clone https://github.com/errorfiathck/ssrf-exploit.git- cd to directory
cd ssrf-exploit- Once on your system, you'll need to install the Python dependencies.
pip3 install -r requirements.txt- run the script as example:
python3 ssrf-exploit --help- Have fun!