HTB Armaxis Walkthrough

I solved the box "Armaxis" which was a very easy boy and had a file inclusion vulnerability via Markdown Injection. The application also suffered from relying too much on user input without proper validation checks in the password reset functionality.

I booted up the machine and connected to the HackTheBox VPN. I noticed that there were two different web applications provided along with the source code.

One hosted instance was the primary application itself.

Another instance was of an email interface which I figured might be used for password reset functionality. It also had a text mentioning our email as "test@email.htb"

I tried directly with the reset password endpoint with the available email address and got a "User not found" error,

so registered a new account and

got redirected into the /weapons endpoint

analyzing the request, I noticed there was a uid and a jwt token for session management.

I moved to the source code provided with the challenge and started with the router file and got an endpoint — /weapons/dispatch which required the "admin" role. I decoded our current JWT to figure that our role was "user". So, as expected we got a 403 status code on visiting that endpoint.

On the database code, we got a seed value that contained an email address that had the role of "admin", but the password was randomly generated. So I figured we might have to use the password reset functionality on this. I initiated a password reset request on our own email "test@email.htb" to analyze the application behaviour.

We were getting a reset token which we had to paste along with the new password we wanted to set for our account.

Upon intercepting and analyzing the request on burp suite, I noticed that there was a third parameter "email" which was being POSTed along with the reset token and our new password.

I changed the email to the admin email I found in the database file,

and got a success message.

Now, logging in with the new password,

we are successfully authenticated.

Since we had the admin role, we had access to weapon dispatch endpoint. On analyzing the weapon dispatch route, it was processing the note section in the markdown.js file.

On analyzing the markdown.js file, I noticed image was being included using base64 encoding, but surprisingly there are no checks for file extensions or MIME type of the file being included.

From the source code structure, I got the idea that we had to get the file named "flag.txt" in the current folder of the web application (in the application source, there was a file named flag.txt that contained a fake flag). I used markdown syntax to include the flag.txt file.

Since we were getting only a broken image icon on browser, I used curl along with our session details to get the /weapons page.

Spotted the base64 encoded contents of flag.txt

decoded the string with base64 utility and had the flag.

Submitted the flag and completed the box.

There was multiple vulnerabilities in this room that needs to be addressed if it were a real application:

1. The password reset functionality should not rely on user controlled input — the application should further implement proper access control mechanisms to ensure an user can not reset someone else's password
2. The application also had a weak password policy making it susceptiable to dictionary attacks — the application should introduce a strong password policy along with rate limiting for sensitive functionality like authentication
3. The application did not implement proper checks for the files it was including — ideally, file inclusion if required, should me restricted to specific folders and files and proper validation checks should have been performed to verify that only images files were being reference with file extension and signature validation.