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:

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

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!

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.

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!