File inclusion room
This room has been created by TryHackMe and @Yas3r. Thanks to the creators! - January 2022
First of all, I am very excited about this review and walkthrough as it is my first attempt to write one! I had this project for so long of doing a review and walkthrough book, but I never had time to dedicate to it before now on. I hope that this momentum created by the writing of this first walkthrough will give birth to so many others blog posts of this kind! Anyways, let's dig into the main topic! From completing this room I have learned a lot about the basic of file inclusion vulnerabilities and many techniques that can help the cyber analyst to find some in web applications.
Clink here to join the room right away!
What is covered by this room?
1) What is directory / path traversal
Path traversal is also known as directory traversal. For those who are friends with Mrs. Command Line, the ../
should not sounds so unfamiliar. In the path traversal attack, the ../
allows the attacker to move one step up in the hierarchy of files of the system, getting out of the applications files, and access directories and other files that he should not have access to. The dot-dot-slash is very common in file inclusion attack.
2) Which files and directory to look for
The room gives us good examples of files on Linux and Windows OS that worth trying to access when testing for file inclusion. Very often these files contains sensible information on the users and the OS system.
Here are three files that we can use and try to access to: /etc/passwd
, /etc/shadow
, /proc/version
3) Bypass filters
File inclusion vulnerabilities are commonly the causes of a bad filtering of the user input. You have probably read multiple time "NEVER TRUST THE INPUT USER" when searching about how to protect web application from multiple vulnerability. This motto applies here as well! A technique that is often use by developers to restrict the access of certain files is to implement filters in the user input. However, those filtering can be very badly implemented and can be easily bypass by some simple tricks that are covered by the room. For example, the author shows us how null byte and double dash can help us bypass the filter. All the techniques are very well explained in this room.
4) Remote File inclusion
Local file inclusion is when accessing files on the local machine (the one that host the web application). However, Remote file inclusion also exists and can be especially damaging as it can lead to a remote code execution (RCE). The steps of this attack is very well explained in a schematic way in the room. Briefly, a RFI is when the attacker furnish to the application a URI that points to an external server containing a malicious file. The content of the file can then be executed by the application and trigger a Cross Site Scripting (XSS), a Denial of Service (DoS) or disclose sensitive information. I appreciate that this room address this vulnerability because, I feel like this vulnerability is often forgotten in articles about file inclusion.
5) Remediation
Finally, I really enjoy that the author of the room has included a remediation section in the room. Indeed, it is a thing to know how to test for this vulnerability and how it works behind the scene, but at the end the main job of a cyber analyst is to make recommendation about how to mitigate vulnerabilities. Be prepare to be surprised: User input validation is one of the main key to mitigate file inclusion attacks! Also, as the web application includes in this room uses PHP as scripting language, the authors warns about two PHP features that could potentially makes our application vulnerable to file inclusion attacks such as allow_url_fopen
and allow_url_include.
Challenges walkthrough
The room offers four challenges to put our knowledge into practice. There is three flags to catch and one RCE to execute.
Flag 1
I have found this challenge quite interesting as I have learned that a file inclusion attack could be performed by changing the method of the request! This is a technique I will try in future CTF. Indeed, changing the method of requests could sometime leads to weird behavior of the application. This flag can be easily grabbed using BurpSuite to manipulate the request.
First of all, I simply wrote/etc/passwd
in the input file and submitted the request. From there, it is possible to find the endpoint and the name (file) of the parameter that is used to request the file.
Then, the room gives us a hint that is quite explicit on what action to perform to get the flag. It is said to change the method of the form to POST
. For that, BurpSuite can be of a great help as we can easily manipulate web request. Therefore, I tried to intercept the request and changed the method from GET
to POST. Following this, in the body of the request, I included the file
parameter and set its value to the file I want to get from the server /etc/flag1.
By changing the body with the inspector of BurpSuite, the body get automatically URL encoded. There we go! We got our first flag!
Flag 2
The second flag is also interesting to get as it gives the attacker the reflex of looking into the browser cookie storage when testing web application. For the second flag, the hint is also quite explicit on the action we need to perform. As mentioned, I opened the inspector and noticed that a cookie with the name of THM
was set to Guest
. Also, the image below shows also that only admins can access the page.
Therefore, I tried changing the value of the THM
cookie for Admin
. I refreshed the page and got this response.
When inspecting the web page, it is obvious that there is no user input or other endpoint aside the cookie value that could be modified to perform a file inclusion attack. Therefore, I modified again the cookie value with the path of the file that I am looking for /etc/flag2
. Unfortunately, I got nothing from that attempts, but the error got me an useful hint. We can notice that .php
is automatically added at the end of the name file that I set as the cookie value.
The room gives us a technique to bypass the adding of an extension by the application which consist of inserting Null Bytes at the end of the expression. The Null Byte can be URL encoded or in hexa %00
or 0x00
. The error message also indicates that we are in the includes folder. Then, it is likely that we will need to one or two directory up to get the /etc/flag2
file. Let's try those techniques.
After multiple try, I finally got the flag with this payload injected as the cookie value ../../../../etc/flag2%00
Flag 3
Now, let's get ready to catch our flag #3. First of all, 2 hints are associated with this challenge. We know that not everything is filtered and that the websites uses $_REQUESTS
. I did not know what $_REQUESTS
means, so I did a little bit of research. The PHP docs indicates that $_REQUEST method can contains the contents of $_GET, $_POST and $_COOKIE. Now that we got this information, let's try to figure how the web application behave when a path is submitted in the input file.
I tried injecting those payloads
/etc/flag3
../../../../etc/flag3
../../../../etc/flag3%00
....//....//....//....//etc//flag3%00
and always got the same response...
It seems like the number 3
and all the /
are removed. Plus, the web application add the .php
extension at the end of the file name. Strange... Also, from the URL at the top we can see that the parameter used to get the file is still file
.
From there, I decided to use BurpSuite to have a better overview of the response. I intercepted the request and send it to the repeater. I have changed the request method to POST as the $_REQUEST method is used by the website and add a body to the request with the path of the file as seen in the image below.
Unfortunately, nothing came out when inspecting the response, but we can see that the .php
file extension is still there. Let's add the Null Byte at the end of the path as we previously did.
We got the flag!
I added the Null Byte %00
directly in the Request body not using the Inspector as the Inspector automatically URL encode our body parameters. %00
is already URL encoded so double encoding it will result in %2500
which won't get us the flag.
RFI
To finish, I tried getting the Remote File Inclusion challenge. We know from our last challenges that the website uses the PHP scripting language. Therefore, the first step is to create a PHP script that will execute the hostname
command. Following a little bit of research, an appropriate payload could be:
Once our payload is ready, we can host it on a web server. There is a lot of manner we can generate a custom webserver on our local machine. I decided to host my payload on a Python3 server as it is very convenient and easy to set up.
Then, the room is pretty much explicit on how to perform a Remote File Inclusion attack. We need to inject to the file
parameter the URL that point to our webserver that we set up earlier. Then, the web application will send a GET request to the file hosted by our server and the PHP code from our payload will get executed. The code execution is possible because of the PHP include function that executed the PHP code of the file passed in argument.
There we go! We can see that our payload got executed!
Last updated