The “voting” service from ENOWARS 3 was a Flask-based website with an Sqlite database. It contained a beginner-friendly vulnerability in the session token generation.
The website allows users to create new polls or vote (yes / no) on existing polls. New users can freely register with a password, while existing users can login with that password (and stay logged in for up to an hour). Poll creators can create a private note for their poll, that they can only see themselves. The gameserver registers as a new user and creates a new poll with a flag in that private note field:
When logging in, the app creates a session, saved as a random session id (sid) and username. The session id is set as a cookie. On future visits the server checks if the session id from the cookie is in the database; if so the request is considered authenticated. The relevant code to generate the session looks like this:
We see: The given session id depends solely on the username,
session_id = sha512(username). That means we can simply calculate the session id for any user, as long as this user is currently logged in. Then we request this user’s polls and include a cookie with the forged session id - and we get his private note (including the flag).
The exploit is straightforward:
- Retrieve the front page and get a list of all polls
- For the 20 newest polls, get the username of their creator
- Forge this user’s session id
- Request the poll again (with the forged session id). The service thinks we’re logged in as poll owner and includes the private note
- Extract and print the flag from the private note
A clean and secure way of generating a session id is using an HMAC instead of a plain hash function. You can patch the first lines of
We found the vulnerability in the first minutes after looking at the service - it was at the top of the file and rather obvious. When the network opened we were the first team to exploit this and got overall first blood. Afterwards we spent some time looking at the rest of the service, but did not find any other vulnerability. The service examples were making heavy use of Unicode, so we especially looked for Unicode vulnerabilities - but did not find anything. We guess that also no other team found one, because we remained unexploited for the whole CTF.
Overall this was a well-prepared service which was more suited to beginners, but fun neverless.