By Adam Hirsch –
In this blog, we will demonstrate about log file injection, local file inclusion,
and remote code execution using these methods.
Apache normally uses two log files:
, which contains all valid requests to the Web server
, which contains error messages.
The server access log records all requests processed by the server, which means requests made will be stored in the previously mentioned log files. By
utilizing some misconfigured files and permissions, we will be able to inject
code into those locations and execute it. We will wrap up the topic talking
about remote logging and why it’s a preferable solution to log exploitation.
- The target machine is running a LAMP stack on Ubuntu 16.04.
- The attacker will be running Kali. This isn’t needed but the included tools are useful and will speed up the set-up process.
- A PHP file on the webserver that is vulnerable to malicious user input.
Leveraging a vulnerable PHP file
We are going to leverage a vulnerable PHP file which doesn’t validate user input. For simplicity purposes, it will only contain the code that is relevant. This PHP file allows a user to pass variables into therequest.
This PHP file will reside in /var/www/html/temp/ and we will name it . Let’s now query the page and see what we can pull up. If we append after we’ll traverse upwards a directory. In our instance, test.php is located at /var/www/html/temp. Therefore, we will need to traverse upwards 4 times to reach the root directory that the server is running on.
In this example, let’s visit the servers :
Unfortunately, we are not able to view them. This is most likely due to file permissions set on. Viewing , you can see that the function was passed in the correct value, but was denied access to view due to permissions.
Let’s check the file permissions that are set using .
As we thought, other users are not able to read, write, or execute access.log. We will issue the command . Other users should be able to read this file now. It’s possible that these logs may already have been configured with these permissions due to poor practice.
Querying the page with the same method as before now yields theinformation:
Of course, it is possible to view other valuable files. When trying out other
files or directory’s you may encounter the same permission issues.
What we did is known as exploiting a local file inclusion vulnerability(LFI). There is also remote file inclusion which is worth researching. Next let’s leverage the servers poor configurations further and see what we can do.
Injecting code into the log file
So far, we’re able to traverse the server’s directories and read readable files.
Our previous step will lead us into the next objective; writing code to the log
file. To do this, we’ll use the Netcat utility. This is because sending GET requests in the browser will URL encode the request, making it useless.
An example passing code through the browser:
Here is the log in and
is converted to .
Fire up Netcat and connect to the web server on port 80 and craft a GET request. I’ll be using thefunction which executes an external program and displays raw output. The goal of this is to write our code to access.log.
A sample cutout ofon the server shows we successfully injected our code. An attacker may verify this using the pervious example in Leveraging a vulnerable PHP file.
When querying the same URL,is not given an argument which triggers a warning that gets logged to error.log. We need to specify what input will be.
Now our URL will consist of two variables; .and
Content will remain asbecause that’s where our function is located.
Input will be the command that we want to execute on the system.
Every time the web service needs to access and read the log file it will read the code we injected that contains the , it will execute that program. Here we see the output in the :function. Now that we provide an argument for it, such as
Obtaining a shell
What we want to do is invoke a reverse shell from the Server. We are capable of remotely executing programs on the server from our attacking machine. Let’s create a PHP reverse shell script. I’ll be using this. Change and to values that suit your needs.
To get the PHP file onto the Server and execute it, we’ll use a webserver to deliver our malicious code.
Kali Linux has apache2 preinstalled by default. This’ll speed our process.
I’ll save the PHP script at
I’m going to compress the PHP file so it is not executed when using. The reason for this is because the script will fail to daemonise and only provide a shell from the attacker’s machine.
The next steps use the same methods mentions previously. Execute wget on the server to download the compressed PHP file. We are placing the file in /tmp. You could also provide the -O flag to specify where wgetwill download the file to.
Decompress the file.
Begin listening to the port you modified the PHP script to open.
Finally, executing the PHP file on the server will provide a shell.
A common solution to preventing vulnerabilities that were covered is centralized logging. Not only does this help prevent potential breaches of sensitive data but it also prevents the need of sifting through log files diagnosing system or network problems.
Distributed log collectors are a new class of solutions designed for high-volume and high-thorough log and event collection. They are highly scalable and haste analyzing log files. Some examples are: