Author: INTELEON404 Category: Web Exploitation PicoCTF: 2026 Difficulty: Medium

Introduction

This picoCTF challenge, titled Hashgate, is a classic example of Insecure Direct Object Reference (IDOR) vulnerability. The developers tried to protect user data by replacing numeric IDs with their MD5 hashes in the URL. However, due to predictable ID generation and completely broken access control, the hashing provided no real security.

The challenge beautifully demonstrates how weak authorization logic can lead to account takeover even when data appears "hidden" behind hashing.

Reconnaissance

Right after launching the challenge instance, I inspected the page source and found hardcoded login credentials conveniently left by the developers.

None
Email
Email: guest@picoctf.org
Password: guest

Using the provided email and password, I logged into the application. After logging in, I landed on the dashboard with the following URL:

?id=3000

Initially, the parameter showed a plain numeric ID. However, when I intercepted traffic with Burp Suite, I discovered that the application was actually converting the numeric ID to its MD5 hash and using that hash to identify users.

None

The most critical observation was that the backend was not properly validating the user's session or permissions. It blindly trusted whatever value was passed in the id parameter (or its hash) to fetch and display user information. This confirmed the presence of a severe IDOR vulnerability.

Exploitation

The challenge hint mentioned that the company had around 20 employees, indicating that user IDs were sequential and limited to a very small range—most likely 3000-3020.

I wrote a short Python script to generate MD5 hashes for all IDs in this range:

import hashlib

print("[+] Generating MD5 hashes for user IDs (3000-3020)...\n")

for i in range(3000, 3021):
    user_id = str(i).encode('utf-8')
    md5_hash = hashlib.md5(user_id).hexdigest()
    print(f"{md5_hash}  →  {i}")
None
3000–3020 md5 hash

I then used Burp Suite Intruder to brute-force these 21 hashes by replacing the id parameter in the dashboard request.

After analyzing the responses, one hash produced a noticeably different and richer response:

None

Hash: 5a01f0597ac4bdf35c24846734ee9a76

Using CrackStation, I quickly reversed the hash and found the original ID:

3012 → 5a01f0597ac4bdf35c24846734ee9a76

This ID belonged to the Administrator account.

By simply replacing the ID parameter with the administrator's MD5 hash, I gained full access to the administrator's profile and successfully retrieved the flag.

Key Takeaways & Lessons Learned

  • Hashing predictable values (such as incremental user IDs) offers almost no protection against brute-force or guessing attacks.
  • Insecure Direct Object Reference (IDOR) occurs when an application uses user-supplied input to directly access objects without proper authorization checks.
  • Always enforce access control on the server-side using secure session tokens or role-based validation — never rely on obscurity.
  • Small, sequential ID ranges combined with client-controlled parameters make IDOR exploitation trivial.
  • MD5 is fast to compute, making it especially weak when the possible input space is limited.

This challenge is an excellent reminder that security through obscurity is not security at all.