HTB Command Injections - Skills Assessment

You are contracted to perform a penetration test for a company, and through your pentest, you stumble upon an interesting file manager web application. As file managers tend to execute system commands, you are interested in testing for command injection vulnerabilities.

Use the various techniques presented in this module to detect a command injection vulnerability and then exploit it, evading any filters in place.

We visit the page and use the credentials supplied to login with guest | guest

We're imported into a 'tiny' file manager application. I feel like there's a penis joke but can't come up with it... The menu in the top right offers us a search feature... because of the tiny penis? We notice right away that the owner of all the files are the www-data user... let's hope we have bad permissions setup as well as bad input cleaning.

To the right of the files are the ability to preview the file, move it (which gives us the ability to move it into a temp folder or keep it in the same location) or download it... which works like me on Monday morning - not at all.

Using the search feature uses an Ajax style live search of the page, isolating any files we're looking for - if they exist.

Let's pretend we're Morty and start burp with a refresh of the page. We're going to right click the target IP in the list and add it to scope, then under the proxy settings, change the options to filter out anything that's not in scope by checking the box next to "and > URL > is in target scope". Look Morty, this isn't really needed but it cuts down on the chatter when using burp... just... just click the button Morty.

It looks like using the search doesn't cause any traffic through {... burp! ...} so we can safely say that's all handled on the back end (I bet you'd like to see that back end wouldn't you... pervert.) When we click preview on one of the files we can see the request made concatenates the needed file name in the GET request. There's also a filemanager cookie being used.

If we click the file copy we see the see the same kind of GET request and filemanager cookie.

If we walk through the file transfer option we see a lot of the same - We can see the source path and destination folder we're moving the file to and the GET request outlining what and where we're moving stuff to. BORING!

If we attempt to modify the file name we get an error about Malicious request denied. As Chris Farley once said "Hehe I love it, I love my little naughty pet."

After playing with stuff for a while I got my first break using the --version switch for the mv command it's using.

From here we built up our command slowly, like this (be gentle don't just SHOVE it in there without getting it excited first - it'll cause tearing and WAF's will turn on you in an instant):

${IFS}%26l's' <-- printed the folder structure 

${IFS}%26l's'${IFS}%2E%2E <-- took us as far as we can due to permissions

${IFS}%26l's'${IFS}%2E%2Ee'ch'o${IFS}${PATH:0:1} <-- took us up that extra level where we see the flag.

${IFS}%26l's'${IFS}%2E%2Ee'ch'o${IFS}${PATH:0:1}flag.txt <-- verifies we can see just the flag and then we just need to print it out.

Our final iteration of the command replaces the ls with cat and gives us that juicy flag we wanted. Looking at this after the fact, I could have likely shortened this up as

$IFS%26c'a't${IFS}e'ch'o${IFS}${PATH:0:1}flag.txt

but my timer ran out, I'm super lazy and I already got the flag... suck it Tiny File Application.