🗓️Local File Inclusion

When you are able to navigate or view files of the server is called local file inclusion.

?file=

?name=

../../../../ - means navigate back to root folder

../../../../etc/passwd - view the password file

../../../../../../../../ - we can navigate as much based on double dot with slash

use socat in gtfobins - get the local flag

try to identify in google search get the LFI websites

inurl: page?=

┌──(root㉿kali)-[~/machines/windows/Algernon] └─# cat ../../../../etc/passwd root❌0:0:root:/root:/usr/bin/zsh daemon❌1:1:daemon:/usr/sbin:/usr/sbin/nologin bin❌2:2:bin:/bin:/usr/sbin/nologin sys❌3:3:sys:/dev:/usr/sbin/nologin

• where we can look for LFI

• If static web application with no existence random path with empty value

• may some parameter be vulnerable.like imge file

• How you will identify how many directory will go back?N number of time until you will get the content

Testing for Local File Inclusion

The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.

How to Test

Since LFI occurs when paths passed to include statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters.

Consider the following example:

http://vulnerable_host/preview.php?file=example.html

This looks as a perfect place to try for LFI. If an attacker is lucky enough, and instead of selecting the appropriate page from the array by its name, the script directly includes the input parameter, it is possible to include arbitrary files on the server.

Typical proof-of-concept would be to load passwd file:

http://vulnerable_host/preview.php?file=../../../../etc/passwd

If the above mentioned conditions are met, an attacker would see something like the following:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash
...

Even when such a vulnerability exists, its exploitation could be more complex in real life scenarios. Consider the following piece of code:

<?php include($_GET['file'].".php"); ?>

Simple substitution with a random filename would not work as the postfix .php is appended to the provided input. In order to bypass it, a tester can use several techniques to get the expected exploitation.

Null Byte Injection

The null character (also known as null terminator or null byte) is a control character with the value zero present in many character sets that is being used as a reserved character to mark the end of a string. Once used, any character after this special byte will be ignored. Commonly the way to inject this character would be with the URL encoded string %00 by appending it to the requested path. In our previous sample, performing a request to http://vulnerable_host/preview.php?file=../../../../etc/passwd%00 would ignore the .php extension being added to the input filename, returning to an attacker a list of basic users as a result of a successful exploitation.

WSTG - v4.2 | OWASP Foundationowasp.org

Note