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.