THM - Advent of Cyber [Day 6]

Today’s task is about LFI or Local File Inclusion. LFI vulnerabilities are quite common in ctfs so I feel at home with this task. An LFI vulnerability allows attackers to read files that are stored locally on the server that were not meant to be accessed. Obviously this is an issue, but it becomes more of an issue when you consider that sometimes the files that are found with this vulnerability can include things like ssh keys, passwords, and backups (which is the idea behind this task in the Christmas narrative that THM has built). LFI can also lead to remote code execution or RCE if the user’s input sanitation is bad enough. Like in the challenge that dealt with IDOR, the main focus in identifying LFI are the URL parameters. For instance, you could have a URL parameter that gets a file, and by changing the filename, you could grab files that were unintended to be read by end users. It is important to note that a URL parameter is not the only entry point for LFI, but it is quite common and what is used in this challenge.

Launching the website gives us an error page actually, but there is a parameter that is an entry point for our LFI. The first task is simple enough, we just need to change the LFI to point to the proper file. The second task involves using a php filter wrapper. We need to make the browser not run the php code and return it to us so we can see it. To do this we encode the php in base64 and then decode it to get the flag that we need.

The PHP code shows us the manage.php page, which we can then perform the base64 trick on to get another file that looks much more interesting, recover-password.php.

… And then from there we get another file that looks interesting, creds.php, which does in fact have the creds.

We can now login and get the flag.

The last question of the task wants us to get RCE through the LFI vulnerability via the log file it gives us. This is also known as a log poisoning attack. As proof of that it wants us to submit the hostname of the victim machine. Now, It would be easiest to simply read the /etc/hostname file through LFI and simply submit that, but in the spirit of being thorough, here’s some screenshots of how you could get RCE via LFI.

After logging into the application as McSkidy, we have access to the log files. We can monitor these log files to see if our curl request has been recorded in the log. The task gives us some commands that work for making a request to the webserver.

curl -A "This is testing" http://<VICTIM IP HERE>/index.php?err=login.php

Once we’ve verified that the logs are recording our requests, we can inject php code into our request and have the machine execute our code. That command looks similar to the one above, we just replace the string with php code.

curl -A "<?php phpinfo();?>" http://<VICTIM IP HERE>/index.php?err=login.php

Once you run that command, you need to logout of the web app and navigate to the logs via LFI, and there you will see the typical log file, but at the end the PHP info page that we called on in the command that we sent, pretty neat!

Finally, the bonus question has us use php sessions to get RCE. This involves knowing where php sessions are kept on the machine (they tell us it’s /tmp on this box). To be honest, I couldn’t see the PHPSESSID cookie in the dev tools on the in browser attack machine, but I was able to get cookie editor in there and found it that way.

Once you have that cookie, you can construct a URL with the session id in it.

http://10.10.179.134/index.php?err=../../../tmp/sess_PHPSESSID_NUMBER

then open another tab to the login page and enter some php into the username field. For this, you can use the same <?php phpinfo();?> code snippet that we used above. Enter anything you want into the password field and hit enter. This login will fail, but if you go to the original page with the LFI URL on it and reload, you get your code executed! This is another form of log poisoning.

This was one of my favorite tasks so far. I really like LFI and this could potentially get us a reverse shell and have access to the whole server. After that we could try to find a priv esc route and then own the machine, but this is enough for now. I may revist this and try to pwn the box.