Understanding Local File Inclusion Vulnerability | TryHackmMe LFI

Introduction

In this walkthrough, we covered the basics of LFI vulnerability and how to perform a testing to find it. This video is part of web fundamentals pathway from TryHackMe.

Local File Inclusion (LFI) is the vulnerability that is mostly found in web servers. This vulnerability is exploited when a user input contains a certain path to the file which might be present on the server and will be included in the output. This kind of vulnerability can be used to read files containing sensitive and confidential data from the vulnerable system.

The main cause of this type of Vulnerability is improper sanitization of the user’s input. Sanitization here means that whatever user input should be checked and it should be made sure that only the expected values are passed and nothing suspicious is given in input. It is a type of Vulnerability commonly found in PHP based websites but isn’t restricted to them.

Importance of Arbitrary file reading

A lot of the time LFI can lead to accessing (without the proper permissions) important and classified data. An attacker can use LFI to read files from your system which can give away sensitive information such as passwords/SSH keys; enumerated data can be further used to compromise the system.

In this task, we are going to find the parameter which is vulnerable to the Local File Inclusion attack. We will then will try to leverage information obtained to get access to the system.

Finding and Exploiting the LFI Vulnerability

First things first, I needed to set up my environment. I deployed the machine on TryHackMe, fired up my web browser, and got Burp Suite running to intercept and inspect the web traffic.

My initial exploration led me to a web application that used a page parameter to load different pages. This is often a prime suspect for LFI. To test my theory, I tried to access the /etc/passwd file, a classic proof-of-concept for this type of vulnerability. By manipulating the URL and using directory traversal (../../../../), I was able to break out of the web root directory and point to the file I wanted. And just like that, the contents of /etc/passwd were displayed on the screen!

This confirmed the LFI vulnerability. The reason this worked is twofold: the application wasn’t properly sanitizing the user input from the page parameter, and the server had misconfigured file permissions that allowed the web user to read files outside of its intended directory.

From LFI to a Shell

Seeing the user list in /etc/passwd revealed a user named falcon. My next step was to see if I could access this user’s files. I targeted the .bashrc file in falcon‘s home directory, which was successful. This gave me the confidence to go for the real prize: the user’s SSH private key.

I knew that SSH keys are typically stored in a hidden .ssh directory within a user’s home folder. By pointing the LFI to /home/falcon/.ssh/id_rsa, I was able to view the private key. To make sure I captured it correctly, I used Burp Suite to intercept the raw response, copying the entire key.

With the private key in hand, I saved it to a file on my own machine, which I named id_rsa. A crucial step here is to set the correct permissions for the key file; SSH will reject a key that is too openly accessible. After changing the permissions, I used the key to log in as the falcon user via SSH. Success! I was now inside the machine.

Escalating Privileges to Root

Gaining user access is great, but the ultimate goal is always to get root. I needed to find a way to escalate my privileges. I checked what commands falcon could run as the superuser using sudo. It turned out that falcon could run the journalctl command as root without needing a password.

I immediately consulted GTFOBins, an amazing resource for finding ways to exploit Unix binaries for privilege escalation. As expected, GTFOBins had an entry for journalctl. By running a specific command, I was able to spawn a root shell.

Now, with full root access, all that was left was to claim my rewards. I navigated to the user’s home directory to read the user.txt flag and then to the root directory to get the root.txt flag. Mission accomplished!

Technical Commands Used

Here are all the technical commands I used on the terminal during this process:

• sudo chmod 600 id_rsa
  • This command changes the permissions of the id_rsa file to 600, which means only the owner of the file can read and write to it. This is a necessary security measure for using SSH private keys.
• ssh -i id_rsa falcon@<machine_ip>
  • This command initiates an SSH connection to the target machine. The -i flag specifies the identity file (the private key) to use for authentication, and falcon@<machine_ip> specifies the username and the IP address of the server.
• sudo journalctl !/bin/bash
  • This is the command I used for privilege escalation. It leverages the journalctl binary, which falcon could run as root, to execute a command (!/bin/bash) that spawns a new bash shell with root privileges.
• id
  • I ran this command right after getting the shell to confirm my user identity. The output showed that I was indeed root.
• ls
  • A basic command to list the files and directories in the current location.
• cat user.txt
  • This command displays the content of the user.txt file, revealing the user flag.
• cat root/root.txt
  • This command displays the content of the root.txt file located in the /root directory, revealing the final root flag.

Room Answers