CTFs | CTF_INSA_2024 | Web | LFI

LFI 1

In this challenge, we are tasked to perform LFI on the given website. The LFI vulnerability often appear in the GET parameter directly in the URL. Here we can notice the ?page=accueil.php where the GET parameter is page and its value is accueil.php.

Note that here we only have one GET parameter so the URL ends with ?page=... but if we would have multiple parameters, we would have a URL looking like ?page=...&param2=...&param3=.... Notice the first use of ? and then exclusively the use of &.

The 3 steps when doing information gathering when we face a website in a CTF environment are:

• Read the page : Look for usernames, passwords, domains, vhosts…
• Read the source code: Look for comments left by devs, look for interesting headers or interesting files (ex: js files)
• Launch a fuzzer: Launch tools like Gobuster or Ffuf to find interesting files or directories

The website doesn’t have much text, lets look at the source code by either using the shortcut CTRL+U or by right clicking on the page and select Read source code:

As we can see, there is a comment (<-- /var/www/flag.txt -->) in the source code of the page. We can read the content of this file by replacing accueil.php in the URL by the path of the flag.txt file:

And voilà, you got your first LFI validated.

LFI 2

This challenge is also an LFI but replacing the GET value as in the previous exemple won’t work. As you can see the structure of the website is the same:

An interesting thing about LFI is that it allows us to read files and also get Remote Code Execution (RCE). Here we are only interested in reading files. We don’t have the path of the flag so why not reading the files we already know exists ? “But we don’t know any file” you may say. And you are partially right, but we know that there is an index.php, an accueil.php… So why not read them ?

The problem is that they are PHP files. “Why is that a problem ?”. Because if we just ask to print the accueil.php (like it’s done by default), it will only print the HTML generated by the server from the PHP source code. If there is interesting code like passwords, connexion to a database or PHP comments, all of that won’t be printed in the source code of the page we receive in front of us. So one technique to read the full PHP code is to Base64 encode the content of the file to be able to read everything. To do so, we are using PHP Wrappers. A PHP Wrapper is like a bridge that helps PHP code talk to other systems or services easily. It simplifies tasks like sending requests, receiving responses, and handling data, making it convenient for developers to use external functionality within their PHP applications.

We can use it like this to Base 64 encode the accueil.php file:

http://ctf.insa-cvl.fr:1001/index.php?page=php://filter/read=convert.base64-encode/resource=acceuil.php

Note that we only encoded once. A good habit would be to encode it multiple times (2 times is great).

After using this payload, we get the following result:

We can decode it in the terminal using echo "base64_string" | base64 -d but you can also use online tools or BurpSuite. And once decoded, we get the flag in the PHP comment: