Skip to main content

Lo-Fi

Objective​

We need to navigate to http://10.10.12.72 using the AttackBox and locate a flag stored at the root (/) of the filesystem.

Step 1: Initial Exploration​

Upon visiting http://10.10.12.72, we analyze the URL structure and identify a query parameter:

http://10.10.12.72?page=relax.php

The presence of ?page= suggests that the website dynamically includes files based on user input—this is a common sign of Local File Inclusion (LFI) vulnerability.

Step 2: Exploiting LFI to Access Files​

LFI vulnerabilities allow us to traverse directories and access system files by manipulating the file path.

To navigate to the root of the filesystem, we can use directory traversal (../) repeatedly until we reach /flag.txt, the file we need to retrieve:

http://10.10.12.72/?page=../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../flag.txt

Since we don’t know the exact depth of the current directory, we use many ../ sequences to ensure we reach the root.

Step 3: Understanding the Attack​

  • ../ moves one level up in the directory structure.
  • A long sequence of ../ ensures we reach the top (/), allowing us to access flag.txt.
  • This works because the application is insecurely including files without proper input validation.

Conclusion​

This challenge demonstrates a Local File Inclusion (LFI) vulnerability, where an application allows attackers to access arbitrary files by manipulating URL parameters. In real-world scenarios, this could expose configuration files, credentials, or even allow remote code execution in some cases.

To prevent LFI vulnerabilities, developers should:

  • Restrict user input to allow only expected filenames.
  • Use absolute paths instead of user-controlled parameters.
  • Implement input validation and sanitization.