Hack The Box Academy — File Inclusion — Skills Assessment

n00bie Security Researcher @GroovySolutionz on X

Hack The Box Academy — File Inclusion — Skills Assessment

Ok, time to check them skillz on File Inclusion — We’re presented with an IP and Port to test and just one question:

We need to find an LFI and get RCE on the box and there should be a flag in the root directory. The first thing we want to do is check out the IP and Port directly into the browser and we’re confronted with a website.

Parameter in URL to check for LFI.

Just doing some poking around the website leads us to our first parameter to check for LFI. We’ll send this over to Caido, our proxy tool and run the LFI-Jhaddix.txt wordlist on it through Automate and see if we come up with any easy wins here. Remember to double check your syntax, run the scan with and without a backslash in front of the FUZZ word and also try it both URL and non URL encoded.

After running the scan we notice a couple things — we’ve got two different lengths responding 4530 and 4729.

And on the 4729 response we have this “Invalid input detected!” warning. So my first thought was to try and bypass this warning by figuring out what is triggering the warning. Lets send the same request to Replay and see if we can’t monkey with it to find out exactly what the trigger is for this warning.

../ causes invalid input detected/// does not trigger the warning

Using the just the backslash does not trigger the warning, but using ../ does trigger the warning. So we can narrow it down to the dots.

2 .. dots triggers the warninga single dot does not trigger the warning

So it seems the warning is being triggered by the two dots together. So to get around this we can try and Double URL encode the payloads, and we can do this using Caido. I’ll run through how — First head over to preprocessors tab with your request in Automate. Then we’re going to select to URL Encode the default Charset but we’re going to add the dot. Then we are going to Add the preprocessor rule twice like this:

Don’t forget to add the dot to the Charset list.

If we remember from the module PHP has some unique vulnerabilites with PHP wrappers. One of the ways to see if these Wrappers are allowed is to check for a configuration file. We can also just try the more common Wrappers and see if they work. I did follow this part from the lesson to check for this php.ini file using /etc/php/7.3/apache2/php.ini but came up empty.

So another method is just to throw a couple at it and see what happens. Lets start with this filter wrapper to check for base64 encoded output. We can add this payload to the end of the URL and see if we get back anything nice.

php://filter/read=convert.base64-encode/resource=index

BINGO!!!

Let’s view the source and see if we can get this string and convert it back to the source code in cyberchef.

If we look close, we’ll find an endpoint that should be worth checking out!

We’ve found this interesting endpoint. Lets check that bad boy out in the browser…and wouldn’t you know it we have an unauthenticated admin panel!

We found and unauthenticated admin panel.

As we click around the panel, we can check out the various links. Notice that we’re calling different logs and that we’re using another parameter that pops up to call on these pages.

/ilf_admin/index.php?log=

These logs that are here seem to be internal but it automatically brings to mind a possible Log Poisoning attack scenario. For that we’ll have to find a log that we can get our input reflected back to us, and these three (chat, service and system) I can’t seem to get anything reflected. So lets send our parameter back through an LFI scan again using Caido and the LFI-Jhaddix.txt wordlist.

We’ve got some hits!

We can see from our scan we’re hitting some internal files starting 5 directories back. Nice!! So now that we know we’ve got something there and we know we’re on a linux server because of the etc/passwd file. Lets get a more specific wordlist and check for any other files we might be able to come up with. For this I use the LFI-gracefulsecurity-linux.txt wordlist form SecLists. We need to remember to add our 5 path traversals to be sure we’re on the right directory to find the goodies.

….and goodies we did find!

We find a bunch of nice stuff, but we’re really interested in these other log files we have for our RCE! We’ve found 2 new endpoints var/log/nginx/access.log and /var/log/nginx/error.log — Lets check these bad boys out and see if we can get our input to reflect!

From our lessons we know that sometimes we can modify our User-Agent: header to add a payload to the logs. First lets try and modify the header and see if it reflects.

So lets send a couple of these bad boys.

And here we have our pwnypwnpwn reflection. So this is certainly a candidate for RCE.

This is great! So lets try and add a simple PHP payload to the User-Agent: header on our request and see if we can get that RCE — here’s the request I sent. When going through the lessons we achieved RCE with this payload: <?php system($_GET["cmd"]); ?>

So lets try it here — remember that when sending the request we will have to add the command we’re trying to run at the end of the URL like this:

Is it going to work?

We can refresh the log page after sending the request and we have our request reflected but it’s missing the good part.

Not seeing my whoami command being executed here.

This is a part I struggled with, because it seems like when we send this payload the server stops recording the logs and my request doesn’t reflect anymore. This is where I had to do a bit of a deep dive and find the correct syntax that will work. For a hint of what the problem is we can check out the error logs we found earlier here:

We have a PHP syntax error somewhere.

From the error log we can see that we have some kind of PHP syntax error.

Usually when I get an error like this I like to start with quotes, and notice on our payload we’re using double quotes so lets swap them to single quotes and try again. Unfortunately when we try again we’re still not getting any more of our responses coming through. It seems we have broke the server and we’ll have to restart. Luckily on this target we can simply reset the server here:

We need to restart the server because we broke the access.log

To Be continued….