LFI to RCE

I’ve been reading up on this as I prepare for my OSCP certification – there is no shortage of different attack vectors and chaining of exploits when it comes to getting ready. One of these is Local File Inclusion (LFI).

Please note that this can apply to different platforms but for this blog post, we are sticking with Linux-based examples.

When a target is vulnerable to LFI, it means that you as an attacker can reference internal files and resources that should not be accessible externally. This requires the full path and file name – it does not work with directory listing.

From a command line perspective, two dots references the parent directory of the current working directory. If multiple of these are used in tandem, it may be possible to effectively reference a file in a different part of the file system. Think about referencing a file in /etc/ as opposed to the current directory of /var/www/html/.

Let’s take a look at an example of an LFI and directory traversal:

Figure 1. Sample URL we will attempt to exploit

With an LFI and directory traversal, we can attempt to read sensitive files such as /etc/passwd in the below example.

Figure 2. Sample LFI using the ‘key’ paramenter

So now that we are clear on what an LFI vulnerability is, how can we leverage this? Reading files is great but gaining foothold access to a system is better!

We need a way to write some code into a file that we can read. One example of this is by leveraging SSH. When a user attempts to login via SSH, an artifact is written to /var/log/auth.log. So what if instead of providing a username when logging in, we instead provided a malicious payload? This would get written to the auth.log file–effectively poisoning it.

The following is directly cited from PayloadsAllTheThings and I would like to give credit where it’s due: https://github.com/swisskyrepo/PayloadsAllTheThings. This is a fantastic resource and if you do not use it currently, you should!

Figure 1. Using SSH as a method of writing malicious data to a log file

The payload is provided as the username followed by the typical syntax of @hostname or @ipaddress.

Now we have LFI and an auth.log file poisoned with a PHP-based shell. We can now complete the attack and get rudimentary code execution which can be paired with other binaries to obtain a full shell. Examples would be /bin/sh, /bin/bash, /usr/bin/python. The example below demonstrates basic commands to use as a proof of concept that code execution is present and the log poisoning was successful.

Figure 2. The poisoned log file allows for an interactive web shell on the target

An interesting next test I thought of while writing this blog post is if FTP could be leveraged in the same way as SSH? From a bit of Googling, it seems a common log file for this service is /var/log/messages.

Looks like I found my next set of tests to try in my lab!

Advertisement

Published by nop5L3D

Persistent, enthusiastic, and honest. I am a security professional and aspiring Penetration Tester interested in all things within the offensive realm of cybersecurity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: