WebApp Penetration Testing: Local File Inclusion (LFI)

What is a local file inclusion (LFI) vulnerability?

LFI allows an attacker to include a file on a server through a browser. When a Web application does not properly filter the input data, there may be a vulnerability that allows an attacker to manipulate input data, inject path traversal characters, and other files that contain web servers.

Vulnerability Code Example

As shown in the following figure, this is a PHP code that have local file inclusion vulnearbility:

Identify LFI in the WEB application

LFI vulnerabilities are easily recognized and utilized. Any one contains the WEB server file script, for the next step LIF test, is a good entry point, for example:

For the penetration tester, you can try to manipulate the file location parameters to use it, like the following:

The above is to show the contents of the /etc/passwd file on UNIX or LINUX systems.

The following figure is in a WEB application, the successful use of LFI vulnerability in the example:

Technique for bypass WAF

  • PHP Expect
    PHP “expect://” allows the implementation of system commands, however, PHP expect module is not enabled by default.
  • PHP file://
    The following figure is a POST request with payload:

    The following figure using php://input attack DVWA, contains a “ls” command, as follows:
  • PHP://filter
    PHP php: // filter allows infiltration testers to include local files and encode the output data with BASE64. Of course, the output data encoded with BASE64 needs to be decoded to restore the original content.Examples of attacks are as follows:

    The output of the results of BASE64 decoding.
    The PHP ZIP wrapper handles the uploaded .zip file on the server side, and the attacker can upload a ZIP file through a flawed file upload function and execute the server-side ZIP filter via LFI. A typical attack instance looks like this:1. Create a PHP bounce SHELL (SHELL.php).2. Compress it into a .zip file.

    3. Upload this .zip file to the remote server.

    4. Use PHP ZIP package to extract PHP SHELL, use “php? Page = zip: //path/to/file.zip%23shell”.

    5. The above command will be extracted as a file named SHELL.php file, if the server does not add. Php suffix, you can add by renaming.

    If the file upload function does not allow uploading a ZIP file, you can try to bypass the file upload limit using various methods.

  • Execute LFI with /proc/self/environ
    Use the local file contains a vulnerability to see if you can include the /proc/self/environ file. And then into the User-Agent header into the PHP code may attack success. If the code is successfully injected into the User-Agent header, the local file contains the vulnerability will use and execute /proc/self/environ, for reloading the environment variable, and finally execute your bounce shell.
  • Null Byte
    By adding “nullbytes” to the URL encoding, such as “00%”, in some cases can bypass the filtering in the web application. Typically, after the increase of the empty character, the back-end WEB application may be released or not processed for the input, which can bypass the WEB application blacklist filter.Here are some examples of special LFI null bytes:
  • Truncate LFI
    Truncation is another technique that bypasses the blacklist. By injecting a long parameter into a loopholes in a file containing mechanism, the WEB application may have to “cut it” (truncate) the input parameters, which may bypass the input filter TheLFI truncated instance:
  • Log file
    Log file contamination is done by writing code that injects the target system into the log file. Often, when accessing some open services on the target system, the system automatically writes the access record to the log file, which makes it possible to write the code to the log. For example, when using a URL that contains a PHP bounce shell to access the target system, the target system returns a 404 page and creates an apache’s access record that contains the previous PHP bounce shell. The use of previously found documents containing loopholes, you can parse the apache log files, thus the implementation of the log PHP rebound shell.After the source code is imported into the target system’s log file, the next step is to determine the location of the log file. In the investigation and discovery phase of the penetration test of the WEB server, we usually collect the information of the target system by scanning. A good starting point is to find the default log path of the recognized operating system and WEB server.
  • Send a bounce shell by mail to the target machine
    If the target machine forwards the e-mail directly or through another machine on the network and stores the message in the system’s www-data user (or other apache user), it is entirely possible to send a bounce shell by email to the target of. If the domain name does not exist MX records, but SMTP can access, then it is possible to connect to the target mail server, and to www-data / apache users to send mail. Mail to send to the current user is running apache, which can ensure that the user account has access to the user’s mail data directory, and the data injected PHP rebound shell. In this example, the user account is www-data, the mail directory is / var / spool / mail / www-data.In an actual attack, first use a list of known UNIX / LINUX account names to enumerate the target system as follows:

    As above: Use the smtp-user-enum script to confirm that the www-data user account exists in the system.

    The following picture shows the process of sending mail to telnet to www-data users:

    The following figure shows the www-data mail offline file containing shell code that was sent past PHP bounce.



    Use netcat to monitor the local 80 port, for the target system PHP rebound SHELL back, as shown below, PHP SHELL successful rebound: