LFI / RFI

LFI vulnerability in a PHP application

Medium
20 min

In this exercise, we will start by authenticating the vulnerability and then exploit it by running our own PHP code in the application. Start by launching the task and follow the steps below. Below, you will also find the source codes of the file index.php, where the vulnerability in question resides.

PHP LFI 1

In this lab you will exploit a LFI (Local File Inclusion) vulnerability and take over the server.

Objective

Get shell and read the flag from /*****-flag.txt

Exercises

Flag

Find the flag from the lab environment and enter it below.

Source code - index.php

<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><title>Mythical Encyclopedia </title></head><body><?php
    if (!isset($_GET["country"])) {
      include("languages.php"); 
    }
    else {
      echo "<h1> Mythical Encyclopedia</h1> &quot;; } if (isset($_GET[&quot;country&quot;])) { $country = $_GET[&quot;country&quot;]; if ($country == &quot;us&quot;) { $file = &quot;./us.php&quot;; } else if ($country == &quot;fr&quot;) { $file = &quot;./fr.php&quot;; } else if ($country == &quot;fi&quot;) { $file = &quot;./fi.php&quot;; } else { $file = &quot;./&quot; . $country; } include($file); } ?&gt;</body></html>

Vulnerability verification

From the PHP code we can see that index.php first checks if the GET parameter country is provided (using the isset function) and if it is provided, the value contained in this parameter is checked using an if-else-if structure.

The logic is as follows.

  • If the country parameter is equal to us, the parameter file is ./us.php.
  • If the country parameter is equal to fr, the parameter file is ./fr.php.
  • If the country parameter is equal to fi, the parameter file is ./fi.php.
  • Otherwise, the file parameter is equal to the ./ + country parameter.

Finally, the include- function is executed, which is given the parameter file. This function executes and returns the given file. Vulnerability occurs in the last else statement, where the file parameter is given any value that the user has provided for the country parameter, which is then passed on to the include function. This results in an LFI vulnerability.

Authenticate vulnerability by performing the following HTTP request.

GET https://www-bnmpokft3q.ha-target.com/index.php?country=../../../../../../etc/passwd HTTP/1.1

Great! - We succeeded in reading the system's internal passwd - file. The parameter we provided, country , contained the value ../../../../../../etc/passwd, and when this was passed to the include function, its value became ./../../../../../../etc/passwd, which refers first to the root of the application, then to the etc directory, and inside it, the passwd file.


Exploiting Vulnerabilities

Next, let's see how we can execute our own PHP code using this. First of all, it is good to remember that in this case the application uses the include function, which its documentation tells us:

Sisällyttämislauseke sisältää ja arvioi määritetyn tiedoston.

This function includes the given file and evaluates (executes) the given code. This means that if the given file contains PHP code, the code will be executed. However, this is not always true, as not all functions that the application can use to include a file necessarily execute the code, but only return it raw to the page. But in the case of the include function, the PHP code is executed.

Typically in situations like this, the attacker's next step would be to attempt to save PHP code into the application in any form as long as it accidentally ends up in a file that the attacker can then include in the page. This can happen, for example, by manipulating the HTTP request so that PHP code is executed and logged by the server, which the attacker can then include in the page. There are several methods and they mainly depend on the attacker's creativity in this case.

Next, let's try to include the log file of the apache2 service in a similar way. Instead of /etc/passwd, we will set /var/log/apache2/access.log, which is a typical location where the apache2 server stores the HTTP requests that have been received by the server.

We managed to include the service's access.log file. The data shows that the service logs general information about the HTTP request as well as the User-Agent header that was included in the HTTP request. The service's logging is fully configurable, so the logged information is not always the same. It's also important to remember that the location of the log files is equally configurable, and finding them is not always this easy.

The attack occurs as follows. We make an HTTP request using the User-Agent header, which includes PHP code. Then, we include the log file in the same way as before, and the include function should execute our code.

We use the curl command here, but you can do the same with whichever tool you prefer, for example, Burp.

curl -H "User-Agent: <?php echo passthru('ls -al'); ?>" https://www-8ean5fizui.ha-target.com

Then we include the same access.log file. (note: the screenshot is taken from the HTML code of the page, which displays the command output a bit more clearly. Right-click on the page and select View Page Source)

We can now read the flag cat /flag.txt. As a good exercise, you can independently try to create a better way to enter commands, such as by saving your own PHP script in the application that allows entering commands from parameters.

hakatemia pro

Ready to become an ethical hacker?
Start today.

As a member of Hakatemia you get unlimited access to Hakatemia modules, exercises and tools, and you get access to the Hakatemia Discord channel where you can ask for help from both instructors and other Hakatemia members.