Account hijacking?! I actually tried out IDOR [HackTheBox Armaxis writeup]

Web applications are often deemed "secure" simply by implementing mechanisms such as authentication and tokens.
However, in reality, determines which users' data can be accessed , can lead directly to account hijacking.

In particular, IDOR (Insecure Direct Object Reference) is a vulnerability that occurs when user input is used directly to reference an internal object, and can occur even if authentication and tokens are present.
As a result, it may be possible to manipulate other people's accounts or seize their privileges.

In this article, we will use Hack The Box's CTF challenge Armaxis as a subject to actually recreate the IDOR malware that was lurking in the password reset function and examine how account hijacking can be achieved.

About HackTheBox

This time, we are actually HackTheBox (HTB) to verify vulnerabilities.

HackTheBox is a hands-on CTF platform where participants can practice in a variety of security fields, including web applications, servers, and networks.
Its greatest feature is that participants can learn by actually accessing the machines and applications that will be attacked and getting their hands dirty.

Armaxis we will be looking at this time the Challenge categories that was previously offered on HackTheBox, and is currently a VIP plan or higher (note that only active challenges are available to users with the free plan).

There are also machines and challenges in a variety of categories, including Web, Reversing, Pwn, and Forensics, so you can tackle them at a level that suits you.

If you want to seriously hone your skills with HackTheBox, be sure the VIP plan and take full advantage of past machines and challenges.

👉 Visit the official HackTheBox website here

Security can only be mastered by practicing from an attacker's perspective

Simply reading the reference is not enough. actually attacking can you truly understand why something is vulnerable and how to protect it.

HackTheBox provides a training environment where you can safely experience vulnerabilities on a virtual machine.
Even beginners can learn how to think like an attacker while progressing step by step.

• Virtual machine exercises based on realistic attack scenarios
• Addresses a wide range of vulnerabilities, including RCE, SQLi, and XSS
• VIP plan gives you access to older machines

*HackTheBox Academy (teaching materials type) and Labs (practice environment type), and the billing structures are different.
For those who want to prioritize practice, we highly recommend the Labs VIP plan or higher.

Click here to try it out on HackTheBox!

👉 For detailed information on how to register for HackTheBox and the differences between plans, please click here.

You may also want to read

How to get started with Hack The Box | A thorough comparison of the free and paid plans, Labs and Academy. Many people who want to become security engineers and improve their skills through CTFs are probably interested in Hack The Box (HTB). But when it comes to the official...

Challenge Summary: Armaxis

is a web application-based CTF task based on
the fictional weapons control system "Armaxis." Players access the system as ordinary users, investigating its functions and exploiting vulnerabilities.

In addition to user registration and login functions, Armaxis also has a password reset function a weapon dispatch function that is available only to administrators .
When dispatching weapons, users can enter Markdown as a memo field, and the content is processed on the server side before being saved and displayed.

At first glance, this appears to be a typical web application, but the user authorization check for the password reset process is implemented insufficiently an Insecure Direct Object Reference (IDOR) under certain conditions .
By exploiting this issue, it becomes possible to operate other users, even administrator accounts, which should not be possible.

Gaining administrative privileges unlocks new capabilities and additional attack surfaces, ultimately
allowing a player to exploit the cascading effects of multiple design flaws to gain access to information about the server.

point

• Challenge Type: Web Application
• Vulnerability: IDOR, LFI
• Attack sequence:
  • Investigating the features as a general user
  • Exploiting flaws in password reset processes to gain privileges (IDOR)
  • Access admin functions and discover additional attack surfaces
  • Stealing internal server information (LFI)
• What you can learn
  • The difference between authentication and authorization
  • How IDOR is established

What is IDOR?

Authentication and authorization are often confused
when discussing web application security, but correctly distinguishing between them is essential to understanding IDOR.

Authentication is a mechanism for verifying " who you are, " and login processing and token validation play this role.
On the other hand, authorization is a mechanism for determining what you are allowed to do

IDOR (Insecure Direct Object Reference) is a vulnerability that occurs when
authorization check is missing It occurs when a user-specified value (such as an ID, email address, or file name) is used to directly reference an object within the server, but without verifying that it actually belongs to that user.

It's important to that IDOR holds even in the presence of authentication :
being logged in or having a valid token is meaningless if authorization checks for the referenced object have not been performed.

For example, if an implementation uses the email address in a request to search for or update user information,
it would be possible to manipulate someone else's account simply by replacing the input value.
This is a typical example of an IDOR attack.

The CTF challenge "Armaxis" discussed in this article also lacked this authorization check in the password reset function, which
ultimately led to account hijacking.

I actually tried IDOR!

Before we launch our attack, let's first check the screen.

The first is the login screen for a system called Armaxis.
It seems that both admin users and general users use the same login screen.

The second is a mailbox. This is where the email address for the attacker is prepared.
test@email.htb is our email address, so let's check it.

Reconnaissance phase: Create an account at test@email.htb

First, let's create an account using the email address test@email.htb that is provided.
Registration is simple; just enter your email and password and click the Register button.

If you have successfully registered, you will see the message "Registered Successful."

Once you've registered, try logging in.

At this point, it should say "No weapons dispatched yet."
After this, you'll probably gain admin privileges and start dispatching weapons to this account.

Reconnaissance Phase: Source Code Review

The reconnaissance phase continues, so let's take a look at the source code.

As I looked around, I found an implementation that caught my attention in "/reset-password".

router.post("/reset-password", async (req, res) => { const { token, newPassword, email } = req.body; // Added 'email' parameter if (!token || !newPassword || !email) return res.status(400).send("Token, email, and new password are required."); try { const reset = await getPasswordReset(token); if (!reset) return res.status(400).send("Invalid or expired token."); const user = await getUserByEmail(email); if (!user) return res.status(404).send("User not found."); await updateUserPassword(user.id, newPassword); await deletePasswordReset(token); res.send("Password reset successful."); } catch (err) { console.error("Error resetting password:", err); res.status(500).send("Error resetting password."); } });

It seems fine until I check the token, but it seems like the token doesn't have a user associated with it, so I'm trying to get the user from email.
Let's check getUserByEmail.

async function getUserByEmail(email) { const query = `SELECT * FROM users WHERE email = ?`; try { const user = await get(query, [email]); return user; } catch (error) { throw error; } }

When I check the SQL, it seems to retrieve the user only from email address.

updateUserPassword is called with the userId and newPassword obtained from the email.
Let's check this as well.

async function updateUserPassword(id, newPassword) { const query = `UPDATE users SET password = ? WHERE id = ?`; try { await run(query, [newPassword, id]); } catch (error) { throw error; } }

Since there is no particular control over the token, we found that it is possible to change another user's password using the email and newPassword parameters.

Also, the source code contains the admin's email address.
Make a note of "admin@armaxis.htb" as you will need it to log in to the admin account in the future.

Reconnaissance phase: Checking actual password change requests

Next, let's actually operate the screen and confirm the password change request.
There is a "Forgot Password?" on the login screen, so press it to move to the Reset Password screen.

let's try updating your password with
the provided email address " test@email.htb " test@email.htb " and click the Request Code button.

A dialog box will appear on the screen asking you to enter your token and new password.

You can check the token by reloading your mailbox.

When I tried to update my password by entering the token and new password, I found that the following request was sent.

If you can set each parameter as shown below, you should be able to change the admin password.

• token: Token issued by test@email.htb
• email: admin's email address
• newPassword: Any password

Now that we have all the information available, let's launch an attack based on this information.

Attack Phase: Takeover of the admin account

Let's take advantage of the IDOR vulnerability and use the token issued by test@email.htb to change the password of the admin account and take over the admin account.

First, get a token with "test@email.htb".

Once you reach this screen, you should have received the token in your mailbox.

It arrived safely here. (I accidentally pressed the button twice, so there are three emails.)

Now, let's modify the JSON with the following information:

• token: the token for test@email.htb obtained earlier
• newPassword: Any password (test)
• email: admin@armaxis.htb (admin's email address)

Now you should be able to send a request to change the password of another account using the token from test@email.htb.

The response is 200 OK, so I think it went well.
Let's check it on the screen.

Enter the email address as admin@armaxis.htb, enter the password you set in newPassword, and click the Login button.

Now we have hijacked the admin account!
Now that we have the Dispatch Weapon, we can use it to get the Flag.

Bonus: Get Flag using LFI

Since this article focuses on IDOR, I will briefly summarize the next steps.

First, there was a field on the screen where you could enter Markdown. This time, we will use this Markdown field to load a file on a server that is normally inaccessible to LFI.

The command "COPY flag.txt /flag.txt" tells us that flag.txt is located directly under the root directory.

# Use Node.js base image with Alpine Linux FROM node:alpine # Install required dependencies for MailHog and supervisord RUN apk add --no-cache \ wget \ supervisor \ apache2-utils \ curl \ build-base # Install MailHog binary WORKDIR / RUN wget https://github.com/mailhog/MailHog/releases/download/v1.0.1/MailHog_linux_amd64 RUN chmod +x MailHog_linux_amd64 # Prepare email directory and copy app files RUN mkdir -p /email COPY email-app /email WORKDIR /email RUN npm install # Generate a random password and create authentication file for MailHog RUN RANDOM_VALUE=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1) \ && htpasswd -nbBC 10 test "$RANDOM_VALUE" > /mailhog-auth \ && echo $RANDOM_VALUE > /email/password.txt # Set working directory for the main app WORKDIR /app # Copy challenge files and install dependencies COPY challenge . RUN npm install # Copy supervisord configuration COPY config/supervisord.conf /etc/supervisor/conf.d/supervisord.conf # Expose ports for the app and email client EXPOSE 8080 EXPOSE 1337 COPY flag.txt /flag.txt # Start supervisord CMD ["supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"]

Markdown can display images using "".
Normally you would put an image path here, but let's try setting txt here.

Also, set the path to file:// instead of image://.

![flag](file:///flag.txt)

Once you have created Dispatch Weapon, log in with test@email.htb.

Of course, the image will not be displayed, but you will see some Base64 encoded text in Elements.

<img src="data:image/*;base64,SFRCe200cmtkMHduX2J1Z3NfMW5fdGgzX3cxbGQhfQo=" alt="Embedded Image">

Let's decode this, whatever you want.
I'll use CyberChef.

We were able to successfully retrieve the flag! In this case it was flag.txt, but if someone were to retrieve a password file or something similar, it could lead to major problems, so be careful.

Countermeasures: What can be done to prevent IDOR?

The IDOR issue that occurred with Armaxis was not due to a problem with the token generation method or randomness, but rather a lack of authorization checks . Therefore, simply "strengthening the token" is not enough.

Here we will summarize practical measures based on this case study.

Do not rely on client input for object references

The most important thing to do not to use client input such as email addresses or IDs as object references .

In this password reset process, the email address included in the request was used to search for the user to be updated.
This design makes it possible for someone to manipulate another person's account simply by replacing the input value.

Originally, the users to be updated were:

• Logged-in user information
• The user ID associated with the token

The decision should be made based on information that can be determined on the server side , such as

I have personally seen many applications that actually run using object references that depend on client input, so be sure to develop with caution.

Treat tokens as "operation permission" rather than "identity verification"

A password reset token does more than just check whether it is valid.

• this token issued?
• Is it being used as an operation by that user?

must be verified on the server side .

In this issue, the token was checked, but about which user the token was authorized to operate was ignored.

should not be treated as "proof of identity," but "keys that authorize specific operations for specific users."

This is what tends to happen when you develop with a light-hearted attitude that there is no problem as long as you just issue tokens. I think
there are many engineers who develop without really understanding the meaning of tokens.

Check administrator functions and exception flows more strictly

Exceptional flows like password resets and administrator-only functions tend to have looser authorization than normal processes,
but in reality, these exception flows are the starting point for attacks .

• Password Reset
• Account Recovery
• Administrator-only operations

Functions like these require clear design and implementation of who can operate whose data and why.

Also, since there are times when the general public can be lax, it may be a good idea to have administrator-only functions in a separate system.

Summary: IDOR and the Pitfalls of Authorized Design

In this challenge, that trusting user input without sufficient authorization checks led to account takeover. Even if tokens and authentication are in place, they alone are not enough to ensure security.

The essence of the problem lies in the fact that the server did not determine "whose data it is permitted to manipulate."
A design that uses email addresses directly as object references is a typical example that causes IDOR.

To prevent IDOR, it is important to uniquely determine the operation target on the server side and explicitly check authorization for each process.
This is not a special measure, but a basic design principle.

By actually trying it out through CTF, I was able to see how real the problem of authorization failure is.
If you're interested, I recommend you Hack the Box a try.

Security can only be mastered by practicing from an attacker's perspective

Simply reading the reference is not enough. actually attacking can you truly understand why something is vulnerable and how to protect it.

HackTheBox provides a training environment where you can safely experience vulnerabilities on a virtual machine.
Even beginners can learn how to think like an attacker while progressing step by step.

• Virtual machine exercises based on realistic attack scenarios
• Addresses a wide range of vulnerabilities, including RCE, SQLi, and XSS
• VIP plan gives you access to older machines

*HackTheBox Academy (teaching materials type) and Labs (practice environment type), and the billing structures are different.
For those who want to prioritize practice, we highly recommend the Labs VIP plan or higher.

Click here to try it out on HackTheBox!

👉 For detailed information on how to register for HackTheBox and the differences between plans, please click here.

You may also want to read

How to get started with Hack The Box | A thorough comparison of the free and paid plans, Labs and Academy. Many people who want to become security engineers and improve their skills through CTFs are probably interested in Hack The Box (HTB). But when it comes to the official...