Local File Inclusion & Log Poisoning Explained | HackTheBox Toxic

We covered local file inclusion that is a web application vulenrability. We also covered the concept of log file posioning and how we can move from LFI to log file posioning. We used the lab material from HackTheBox Toxic web challenge to demonstrate this on an Ngnix web server serving cookies in base64 format.. This was part of HackTheBox Toxic Web Challenge.

Humanity has exploited our allies, the dart frogs, for far too long, take back the freedom of our lovely poisonous friends. Malicious input is out of the question when dart frogs meet industrialisation.

Local File Inclusion (LFI)

LFI is a web vulnerability where a web application allows the inclusion of files from the server’s local file system. This often happens when a web page uses a parameter in the URL (like an ID) to determine which page to load, and this input isn’t properly sanitized. Instead of a normal page identifier, an attacker can input the path to a sensitive system file.

• For Linux systems, a common target I look for is /etc/passwd, which contains user data (though not passwords, those are in /etc/shadow).
• For Windows systems, a target could be the SAM file, which holds user password hashes. The path might look something like C:\Windows\System32\config\SAM.
• The specific file path depends on the operating system. It’s important to identify the OS first; for example, .aspx extensions often indicate a Windows IIS server.
• A secure application will validate user input and prevent loading arbitrary files. A vulnerable application, however, will load the requested system file if the path is correct.

From LFI to Log Poisoning

Sometimes, even with LFI, I might not know the exact location of the file I’m looking for (like a flag file in a Capture The Flag challenge). This is where Log Poisoning comes in. It’s a technique I use to overcome this limitation and potentially execute system commands.

Log files record various details about requests, including the URL, user agent, timestamp, and HTTP request type. The key idea behind log poisoning is to inject malicious code (like a system command) into a part of the request that gets logged, often the User-Agent header. Then, using the LFI vulnerability, I load the log file. When the log file is parsed or displayed, the injected code might get executed, giving me remote code execution!

HackTheBox “Toxic” Challenge Example

I demonstrated this concept using the HackTheBox “Toxic” challenge. In this specific scenario, the LFI vulnerability wasn’t in the URL parameters but within a cookie.

• The application’s PHP code checked for a cookie. If it didn’t exist, it created one. This cookie, when Base64 decoded, revealed the path to the page being loaded.
• My strategy was:
  1. Intercept a request using a tool like Burp Suite.
  2. Decode the Base64 cookie to see the file path (e.g., index).
  3. Modify the cookie to point to the web server’s access log file. For Nginx, this is often /var/log/nginx/access.log.
  4. Encode this new path back to Base64 and replace the original cookie value.
  5. Send the request. This should display the contents of the access log.
  6. Next, I sent a new request, but this time, I modified the User-Agent header to include a PHP one-liner that executes a system command (e.g., ls to list files). The payload looked like: <?php system('ls'); ?>.
  7. I then reloaded the access log file (by resending the request with the cookie pointing to the log file). The output of the ls command was now visible within the log data, revealing files in the current directory.
  8. Once I identified the target file (e.g., flag.txt), I modified the cookie again to point directly to this flag file to retrieve its contents.

This approach effectively demonstrated how an LFI vulnerability can be leveraged to view log files, and by poisoning these logs with commands, I could achieve remote code execution or reveal sensitive information.

Technical Commands/Payloads I Used:

Here are the commands and payloads I mentioned or showed:

• Linux file path example: /etc/passwd
• Windows file path example: C:\Windows\System32\config\SAM (conceptual, exact path might vary)
• Nginx access log path: /var/log/nginx/access.log
• PHP one-liner injected into User-Agent (to list files): <?php system('ls'); ?>
• Cookie manipulation (conceptual):
  • Original (decoded): index
  • To load log: /var/log/nginx/access.log
  • To load flag (example): flag.txt

Video Walkthrough