Day 6 – Patch Management is Hard
Despite the name (patch management), Day 6 is really about Local File Inclusion vulnerabilities. LFI is another type of vulnerability that can occur when input isn’t sanitized or validated.
At this point, you may have noticed a common theme among vulnerabilities. Any time a user is allowed to tamper with some kind of input ( URL, cookies, comments, authentication), there is a possibility of exploiting the feature.
LFI vulnerabilities can be quite serious, as they can lead to accessing sensitive data or even Remote Code Execution (RCE) – one of the most critical vulnerabilities.
The tasks for Day 6 involve PHP, which is a server side scripting language that is embedded in HTML. Compare this with JavaScript, which is a client-side scripting language. While JS is executed by the client’s computer (why JS needs to be enabled to view some website features), PHP is installed and executed on the server.
Question 1
Deploy the attached VM and look around. What is the entry point for our web application?
Deploy both the AttackBox and target machine for Day 6. Open Firefox and navigate to the IP address of the target.
As soon as the web page opens, you should see that we have been redirected to a different URL than the one we typed in. Using the IP address 10.10.10.10 as an example, we should see that we have been directed to the following URL:
http://10.10.10.10/index.php?err=error.txt
The question is asking to identify the entry point. An entry point is a parameter that passes an argument to the web app.
Let’s compare this to the example in the writeup for Day 6 on THM. In the example, we were given the following URL:
http://example.thm.labs/page.php?file=php://filter/resource=/etc/passwd
In this example, the entry point was ‘file’. Any arguments that follow it will be passed through it to the web app, allowing us to test for vulnerabilities.
Now compare this with the URL we found when we navigated to the target and you should be able to identify the entry point. Keep in mind we have to work with what we have; ‘file’ won’t work as an entry point for this web app. What has taken its place?
Answer:
(Highlight below to see answer):
err
Question 2
Use the entry point to perform LFI to read the /etc/flag file. What is the flag?
Now that we’ve identified the entry point, we should be able to use it read the /etc/flag file.
We can use the example again to help us, this time substituting our targets IP address, entry point, and flag file.
Original example:
http://example.thm.labs/page.php?file=php://filter/resource=/etc/passwd
Our new URL:
http://10.10.10.10/index.php?err=php://filter/resource=/etc/flag
Remember to substitute the IP address of your target machine and you should see the flag on the page.
Answer:
(Highlight below to see answer):
THM{d29e08941cfe41df55f1a7da6c4c06}
Question 3
Use the PHP filter technique to read the source code of the index.php. What is the $flag variable’s value?
The index.php file is the entry point for web apps that use PHP. One of the main reasons that websites/apps use index.php is that it centralizes the PHP code on the site; instead of having many PHP files that need to managed and updated, you only need to manage index.php.
First, let’s try reading the index.php file directly using the following URL:
http://10.10.10.10/index.php?err=php://filter/resource=index.php
We get an error because the server is trying to execute the PHP code.
Instead of trying to access it directly, we can use a trick in order to read index.php. We do this by telling it to encode index.php into base64, which we can then decode to obtain the original index.php code.
To do this, use the following URL:
http://10.10.10.10/index.php?err=php://filter/convert.base64-encode/resource=index.php
The base64 encoded contents of index.php should be at the bottom of the page. It looks something like this:
Navigate to base64decode.org, and use it to decode this. You should see a much more readable PHP code. The $flag value is on the second line of the code.
Answer:
(Highlight below to see answer):
THM{791d43d46018a0d89361dbf60d5d9eb8}
Question 4
McSkidy forgot his login credential. Can you help him to login in order to recover one of the server’s passwords?
THM gives us a hint that there should be a PHP file containing credentials that is referenced in the code that we obtained in the last task.
The third line gives us the key:
include(“./includes/creds.php”);
It looks like there might be credentials stored in ./includes/creds.php.
Note that the ‘./’ in the file path references the current location in the file system.
Let’s use the same trick that we used in the last question, this time referencing the ./includes/creds.php file instead of index.php:
http://10.10.10.10/index.php?err=php://filter/convert.base64-encode/resource=./includes/creds.php
You should again see base64 encoded data at the bottom of the page. Use base64decode.org to decode this into a readable format and you should be able to obtain the credentials.
Answer:
(Highlight below to see answer):
McSkidy:A0C315Aw3s0m
Question 5
Use the credentials to login into the web application. Help McSkidy to recover the server’s password. What is the password of the flag.thm.aoc server?
Navigate to the app’s login page and use the credentials that we just obtained to gain access to McSkidy’s account.
Next, go to the ‘Password Recovery’ page. You should see the names and passwords for three servers, one of which is the flag.thm.aoc.
Answer:
(Highlight below to see answer):
THM{552f313b52e3c3dbf5257d8c6db7f6f1}
Question 6
The web application logs all users’ requests, and only authorized users can read the log file. Use the LFI to gain RCE via the log file page. What is the hostname of the webserver? The log file location is at ./includes/logs/app_access.log.
In order to answer this question, we need to perform a log poisoning attack.
Log poisoning will allow us to gain remote code execution (RCE) on the webserver.
Make sure you’re logged in using McSkidy’s credentials and navigate to:
https://10-10-10-10.p.thmlabs.com/logs.php
Make sure you replace the last two octets of the IP address in the above URL with those of your target machine.
The logs are stored in a format of four headers that are separated by colons (‘:’)
The four headers are user, IP, User-Agent, and page:
The User-Agent contains browser information and is controlled by the user. If we include PHP code in User-Agent we can obtain RCE.
This is actually easier than it sounds!
First, open up a terminal and use the curl (which stands for ‘client URL’) command:
curl -A “this is testing” http://10-10-10-10.p.thmlabs.com/logs.php
The -A flag specifies the User-Agent string to send to the server. Execute the command and refresh the login page. You should see an entry corresponding to our command.
Note there are actually two new entries: one from our curl command, and one from refreshing the logs.php page.
Now let’s try injecting some PHP code!
This time, we’ll use the following curl command:
curl -A “<?php phpinfo();?>” http://10-10-10-10.p.thmlabs.com/logs.php
This will pull up the PHP information page when executed.
If you just refresh the page, you will see that the PHP will not be executed and we can’t see the code- instead we will find a log entry with a blank User-Agent field. We need to access the log page via LFI for our attack to work.
Navigate to the log file specified in the question description using LFI. Note that we won’t need to perform the encoding/decoding steps because we aren’t trying to read a PHP file.
The following URL should do the trick:
http://10.10.10.10/index.php?err=php://filter/resource=./includes/logs/app_access.log
This time instead of the User-Agent header, we should see the PHP information page. The hostname we are looking for is the second entry in the ‘System’ field.
Answer:
(Highlight below to see answer):
lfi-aoc-awesome-59aedca683fff9261263bb084880c965
