SERVER-SIDE REQUEST FORGERY

Server-side Request Forgery (SSRF) is a vulnerability that allows and attacker to cause the webserver to make an additional or edited HTTP request to the resource of the attackers choosing. There are two types of SSRF, the first is a regular SSRF where data is returned to the attacker and the second is a blind SSRF, but no information is returned to the attackers screen.


A successful SSRF can result in any of the following:
  • Access to unauthorised areas.
  • Access to confidential data.
  • Ability to Scale to internal networks.
  • Reveal authentication tokens/credentials.

Examples of SSRF:

In the below example, the attacker has complete control over the page requested by the web server. The attacker has requested the URL of some data for a user and it has been returned by the web server.



The below example shows that an attacker can combine a SSRF attack with a directory traversal vulnerability. More information on directory traversal can be found here.



In the below example the attacker can control the server's subdomain to which the request is made. Take note of the payload ending in &x= being used to stop the remaining path from being appended to the end of the attacker's URL and instead turns it into a parameter ?x= on the query string.



Going back to the original request, the attacker can instead force the web server to request a server of the attackers choice. By doing so, we can capture request headers that are sent to the attacker's specified domain. These headers could contain authentication credentials or API keys sent by website.thm



Here I am able to find the flag of http://server.website.thm by requesting server=server.website.thm/flag?id=9&x= . 



Finding an SSRF 

Potential SSRF vulnerabilities can be spotted in web applications in many different ways, here are four common examples:


Some of these examples are easier to exploit than others and a lot of trial and error will be required to find a working payload. For blind SSRF exploits, an external HTTP logging tool such as Burp Suite or https://requestbin.com/ will need to be used to monitor requests.


Defeating Common SSRF Defences

The two most common ways of defending against SSRF are Deny and Allow lists.

A Deny List is where all requests are accepted apart from resources specified in a list or a matching a particular pattern. The Deny list could include sensitive data, endpoints, IP addresses or domains. For example, names such as localhost and 127.0.0.1 may be included in a Deny List however an attacker may be able to bypass this by using alternative localhost references such code 0 , 0.0.0.0 or subdomains that have a DNS record which resolves to the IP Adress 12.7.0.0.1 such as 127.0.0.1.nip.io . 

Also, in a cloud environment, it would be beneficial to block access to the IP address 169.254.169.254 , which contains metadata for the deployed cloud server, including possibly sensitive information. An attacker can bypass this by registering a subdomain on their own domain with a DNS record that points to the IP Address 169.254.169.254.

An Allow List is where all requests are denied unless they appear on a list or match a particular pattern. For example, if the Allow list only accepts URLs that begin with https://example.com, an attacker can create a subdomain on the attackers domain name, such as https://example.com.attackers-domain.com. The application logic would now allow this input and let an attacker control the internal HTTP request

An Open Redirect is an endpoint on the server where the website visitor gets automatically redirected to another website address. Take for example the link code https://example.com/link?url=https://example-shop.com
. This endpoint was created to record the number of times visitors have clicked this link for advertising/marketing purposes. Imagine instead that there was an SSRF vulnerability with rules that only allowed URLs beginning with https://example.com/. an Attacker could utilise the above feature and redirect the internal HTTP request to a domain of the attackers choosing.

SSRF Practical

There is a detailed walkthrough of a SSRF exploit on a website at https://tryhackme.com/room/ssrfqi, please refer to this for steps taken.

Comments

Post a Comment

Popular posts from this blog

STARTUP

Image
  Startup is a TryHackMe room where there is a fictional new start up company called Spice Hut, their website is under development and they have some security concerns that they wish to test. I began by heading to the website and began manual enumeration of the site. The site had very minimal functionality, I checked the source code and found nothing of interest. There is a contact link, and I was hoping to be able to get an email address by following it, but it was empty. ' I then performed a Gobuster scan to look for any pages that I may be able to access. There is a page with the name files that is of particular interest.  Here I can see there is an FTP folder, upon opening it I can see that it is empty. I made a note of this as I may be able to upload files to it at a later stage, I then opened important.jpg which seemed to be of no particular interest, and notice.txt had the below text. I made a note of the name Maya, which could be a potential user or username in the future.
Read more

NMAP POST PORT SCANS

In this post we will talk about the steps that follow port-scanning, including service detection, OS detection, Nmap scripting engine and saving the scan results. Service Detection Once Nmap discovers open ports, they can be probed to detect running services and therefore for vulnerabilities. Adding the -sV option to an Nmap scan will collect and determine service and version information for the open ports. --version-intensity LEVEL will specify the intensity of the scan, with 0 being lowest and 9 being highest. Using -sV will force Nmap to use the TCP 3 way handshake. This is because Nmap needs to fully communicate with the target to get information and therefore cannot use the stealth scan -sS . NOTE : In order to run -sV we need root privileges.  OS Detection Nmap can detect the OS based on its behaviour and any telltale signs in its responses by using the -O option. Whilst the OS detection is very convenient, many factors affect its accuracy. In order to have an accurate
Read more

BURPSUITE IN-DEPTH

Image
NOTE: This post will be a much deeper and in-depth dive in to some of the functionality of Burp Suite. If you need a quicker overview, please visit my  Burp Suite Basics  post.  Repeater The repeater function of Burp Suite allows us to take a request captured by Proxy, edit it and send the same request repetitively. This makes repeater ideal for any manual poking around at an endpoint. Basic Usage: The repeater interface can be split in the 6 main sections. Refer to the image above: List of requests that are going through Repeater. Controls for the current request, these allow us to send/cancel a hanging request and go forwards/backwards in a request history. Request/Response view. Requests are edited in the Request view and Responses will show up in the Response view. Allows us to change the layout for the Request and Response view. The inspector allows us to break requests apart and analyse and edit them in a more intuitive way than the raw editor. The IP address or domain that is ou
Read more