TryHackMe LFI WalkThrough

This room was created to help students understand and exploit a web server that contains a Local File Inclusion(LFI) vulnerability.

LFI is a vulnerability that may be found in web servers. This vulnerability is exploited when a user provides input that contains a path to a file that exists on the server, and this file is displayed to the user.

This vulnerability can lead to reading sensitive info from the server. The cause of LFI is improper sanitization of user input. To avoid this, user input should have some validation checks it must pass before used in the web page's includes statement.

This vulnerability exists in just about any language, but the most common examples I have stumbled across are in PHP.



Let’s Get Started



When poking around the website, we can see that there is a parameter page in the URL http://10.10.62.113page= .



page-param.png

This parameter seems like it accepts a file on the server. The page= parameter accepts a file name (ex: index.html) indicating that the webpage has an includes statement in the source code. If this statement is not sanitized, we may query for arbitrary files on the server.

view-files.png


To better view these files, we can view the source on the web page, and we can view the results of the files more clearly.


etc-pass.png


Now we begin the enumeration phase. Here are the files I looked at.

/etc/passwd - We can use this file to determine which users exist on our target. We can also learn their shell/group information.

/etc/shadow - I have rarely been able to access this file as a non-privileged user, but if we can read this file, we can try to use it to crack user passwords.

/etc/group - We can use this file to determine which groups exist and which our user belongs to

/etc/sudoers - We can view the sudo config here. Based on this file it looks like our current user, falcon, can run journalctl as root.

etc-sudoers.png




/proc/cmdline - If we can view this file, we can use this to learn what command was run to spawn the web application process. From here, we can learn interesting things about the application. For example, we learn we are spawned using python and this application appears to be a flask application.



proc-cmdline.png

/proc/self/environ - contains a bunch of environment variables we can use to learn about our current process.

/home/falcon/.bashrc - An interesting file tells us information about the environment upon login, variables in the environment/alias' and functions the user may use.

Another interesting file we should try and the view is our users .bash_history sometimes the bash history contains interesting information, or even passwords users pass as arguments in a command. In this lab, we were unable to view this file, or it was empty.

Task2:

Look around the website. What is the name of the parameter you found on the website?

ANS: page

This task includes a list of interesting files to look for: https://github.com/cyberheartmi9/PayloadsAllTheThings/tree/master/File%20Inclusion%20-%20Path%20Traversal#basic-lfi-null-byte-double-encoding-and-other-tricks

What is the name of the user on the system?


ANS: falcon

We saw this when we viewed /etc/passwd

view-src.png

Name of the file which can give you access to falcon's account on the system?


ANS: id_rsa

priv-key.png

/home/falcon/.ssh/id_rsa - The hidden directory ~/.ssh contains interesting SSH info like private keys etc. By default, ssh keys are stored in a file called id_rsa. So we took a shot in the dark and guessed this file exists here, and boom! We have our way in on this box!

What is the user flag?


ANS {not-included}

Now that we have an SSH key, we can copy it to our host and use it to log into the server as falcon.

using-key.png


Notice the error I received when I first tried to use this key. This error occurs when a private key file has too open of permissions. I have a Linux cheat sheet we can use for reference for file permissions here.

I changed the permissions of the file using chmod 600 and was able to use this key to log into the server successfully.


Viewing the Source Code:

Once we have an interactive shell on the target machine. We can view app.py to check out what the includes statement actually looks like to understand the vulnerability.

source-py.png

We see that the “page” parameter we pass is set in the “page” variable. The program attempts to append the “page” variable to the path it wants the application to retrieve files from /opt/web/{} the {} is where our page variable is used. This file is then set to a template variable. The template is rendered in index.html page into a placeholder called “data”.

viewingsource.png


In the figure above, we can see exactly where the data placeholder is on the HTML page, and we can see the result of /etc/passwd in that very destination.


Task3:

What can falcon run as root?


ANS: /bin/journalctll


Earlier, we learned this from our LFI enumeration: /etc/sudoers .

etc-sudoers.png


We also can figure this out using `sudo -l` to list our sudo privileges.

sudolist.png



What is the root flag?

ANS: {not-included}



Privilege Escalation



We can search for ways to abuse our sudo permissions by searching through: https://gtfobins.github.io/


We find a page about journalctl that suggests that journalctl can be used to break out of restricted environments by spawning an interactive system shell. We can run journalctl as a superuser as follows:

sudo journalctl

Since we spawned this process in root context (using sudo) we can run !/bin/bash to spawn an interactive root shell!


root.png
Previous
Previous

Practical Dynamic Port Forwarding

Next
Next

Practical Local Port forward