BugForge - Weekly - Galaxy Dash

Weekly - Galaxy Dash

Vulnerabilities Covered:
Broken Access Control - Account Takeover via User Deletion and Recreation

Summary:
This walkthrough demonstrates a broken access control vulnerability in a team management application. The application exposes user creation, update, and deletion functionality without proper authorization checks. By analysing the API, the delete endpoint was found to allow any authenticated user to remove arbitrary team members by referencing their user identifier. After deleting the target user walt, a new account was created with the same username and attacker-controlled credentials. Logging in as walt with the new credentials grants access to the original account’s session context, returning the challenge flag. The lab can also be solved without deleting the existing account first - simply creating a team member with the username walt and logging in with those credentials is sufficient to retrieve the flag.

Reference:
Bugforge.io

Solution

Step 1 - Application Analysis

The lab scope specifies: For testing you can target user walt, indicating the teams functionality is the primary attack surface. A test account was created to capture the create and update request structures.

Testing the update functionality with additional parameters such as username, email, and password produced no meaningful changes. The update endpoint does not allow modification of authentication-related fields through this path.

---

Step 2 - User Deletion

Shifting focus to the delete functionality, a request was sent to delete the target user walt.

The server accepted the request and removed the user without any authorization check to verify whether the requesting user should have permission to delete another team member.

---

Step 3 - Account Recreation and Flag Retrieval

With the original walt account removed, a new team member was created using the username walt with attacker-controlled credentials.

Logging in with the newly created walt credentials returns the challenge flag in the login response.

After restarting the lab, it was confirmed that deleting the original walt account is not required. Creating a team member with the username walt and logging in with those credentials is sufficient to retrieve the flag, indicating the application does not enforce unique username constraints or proper identity binding.

---

Impact

• Full account takeover of any team member by recreating their account with attacker-controlled credentials
• Any authenticated user can delete arbitrary team members without authorization, causing denial of service and data loss
• The absence of unique username enforcement allows identity impersonation without needing to remove the original account
• An attacker gains access to the target user’s session context, exposing any data, permissions, or roles associated with that identity

---

Vulnerability Classification

• OWASP Top 10: A01:2021 - Broken Access Control
• Vulnerability Type: Insecure Direct Object Reference (IDOR) / Account Takeover via User Recreation
• Attack Surface: Team member management endpoints - create and delete operations lack authorization checks and unique username enforcement
• CWE:
  • CWE-284 - Improper Access Control
  • CWE-639 - Authorization Bypass Through User-Controlled Key
  • CWE-287 - Improper Authentication

---

Root Cause

The team management endpoints do not enforce authorization checks on destructive operations. Any authenticated user can delete any other team member by referencing their identifier, regardless of role or ownership. The application also fails to enforce unique username constraints at the database or application level, allowing a new account to be created with the same username as an existing or deleted user. When the attacker logs in with the recreated username, the application binds the session to the identity associated with that username rather than verifying it against the original account’s credentials or identity chain. The combination of missing authorization on deletion, missing uniqueness constraints, and username-based identity binding enables full account takeover.

---

Remediation

• Implement role-based authorization checks on all team management operations, ensuring only users with appropriate permissions (e.g., team owner, admin) can delete or create team members
• Enforce unique username constraints at the database level to prevent duplicate account creation
• Bind user identity to an immutable internal identifier (e.g., UUID) rather than the username, so that recreating a username does not inherit another user’s session context or data
• Log and alert on user deletion events, particularly when followed by recreation of the same username, as this pattern is a strong indicator of account takeover attempts
• Apply the principle of least privilege to all team management API endpoints, restricting access based on the authenticated user’s role within the team

---