P1 Bug Hunting — Remote and Local File Inclusion Vulnerabilities

1 year ago 75

BOOK THIS SPACE FOR AD

ARTICLE AD

TL;DR- A full walkthrough and step-by-step process that lands you bug bounties within minutes, file inclusion is definitely a vulnerability you should be familiar with.

Introduction

When misconfigured, some web apps may be vulnerable to a highly damaging vulnerability known as file inclusion. They’re one of the OWASP Top 10 vulnerabilities, and rank high for their ‘ease-of-exploitation’.

They can lead to RCE (Remote Code Execution), which is classified as P1 on most VRTs (Vulnerability Rating Taxonomy), and has potential to land some serious cash in bug bounties. If you’re not familiar with this vulnerability you might even skip right past it, so read on to find all the different ways you can profit from them.

What are file inclusion vulnerabilities?

File inclusion vulnerabilities occur when input directly contacting a web server is NOT sanitized, and allows an attacker to enter and retrieve sensitive data. These responses could be using timed delays, boolean values, or just return the plaintext on the webpage itself.

Here’s a snippet of code where that might occur:

$file = $_GET[‘file’];
include($file);

This code does one thing very, very wrong. It takes anything that the user put in (something like ‘/etc/passwd’ if they’re a malicious hacker), and retrieves that file without any checks. A webpage such as this would need to implement input sanitization and check the permissions of any user attempting to execute this php code.

Here’s a helpful video in case you’re still confused:

What are the two types of file inclusion vulnerabilities?

In terms of file inclusion, we see two variations — Local, and Remote.

Local File Inclusion (LFI)

Allows an attacker to view local files of the current web serverMore common than RFI (about 3x), but harder to exploitIf the attacker is able to place code on the web server through other means, then they may be able to execute arbitrary commands.

Remote File Inclusion (RFI)

Allows attacker to view site files remotely from multiple web serversFar less common on web apps, but it’s much easier to exploit than LFIInstead of accessing a file on the local machine, the attacker is able to execute code hosted on their own machine.

How can I find them?

While you can use automated bug-hunting tools such as Burpsuite, Nuclei, and even WebHeckScanner (my tool), it’s important to learn the ins and outs of manual pen-testing.

Search through a bunch of request and response parameters and try to find any that match the following:

?cat=
?dir=
?action=
?date=
?detail=
?file=
?download=
?path=
?folder=
?prefix=
?include=
?page=
?locate=
?doc=
?site=
?view=
?content=
?document=
?layout=

If you see a url that looks anything like this —

https://example.com/?helpfile=login.txt

That should tip you off that they’re using a very specific type of routing. If you’re familiar with web development, you should know about the basic file structure that would cause us to be directed to login.txt. We can use this to leverage a different url, possibly directing us to a more fruitful directory.

You’ll also want to be familiar with these file structures for navigating firewalls and filters, here are some tips →

Encode your payloads:

Double HTML encodingUTF-8 encodingNull byte termination

Helpful payloads for poorly written WAFs (Web Application Firewalls):

?file=….//….//etc/passwd
?file=..///////..////..//////etc/passwd
?file=..///////..////..//////etc/passwd

How can I exploit and report them?

Continuing from the previous point, we can exploit these vulnerabilities by navigating to this url (if the web app is vulnerable to file inclusion) —

https://example.com/?helpfile=../secret/.htpasswd

This directs us to the .htpasswd file, which is much better than login.txt in this case. Without sanitization, the user could point the url here, and actually request the download of files onto that web app’s server —

https://example.com/?download=../include/connection.php

Upon opening a listener and navigating to our connection.php url on the site (which might take a bit of tinkering with different url paths), we’ll get an RCE vulnerability through our shell, which will now be connected to the site’s inner files and sensitive data.

After you’ve confirmed your vulnerability through a few more tests (don’t do anything malicious though), read up on crafting a perfect bug bounty report. Crafting a professional report yields quicker response time from verifiers, and can even lead to a higher bounty.

Thanks for reading about file inclusion vulnerabilities, and how to exploit them! If you enjoyed reading about bug bounties and cybersecurity tips, check out similar articles from The Gray Area. Feel free to show your support with a few claps for the article (you can just hold down the button)!

If you’d really like to support me as a writer and help me create even more content, subscribe to a Medium membership using my referral link. It gives you access to all of my content, and everyone else’s content on Medium.

Thanks!

Read Entire Article