Fare Evasion
Writeup for Fare Evasion (Web) - UIU CTF (2024) 💜
Description
SIGPwny Transit Authority needs your fares, but the system is acting a tad odd. We'll let you sign your tickets this time!
Recon
The web page is a fare collection system with two options; I'm a Passenger and I'm a Conductor, although the latter is greyed out.
Clicking the first option triggers a POST request to the /pay endpoint, which returns an error message.
Checking the page source reveals the following script.
Finally, we have an access_token cookie in JWT format.
Solution
Putting the pieces together:
We have a JWT with a payload value of
passenger, which we need to change toconductorAn error message revealed the JWT secret:
a_boring_passenger_signing_key_?
JWT Tampering
Looks like a JWT attack - let's see if the key is correct.
It is! jwt_tool even gave us a command to forge our own token. Let's do that now, setting the payload claim to conductor.
I swapped the cookies, but it didn't work. Maybe we need to change the kid header value to conductor_key as well 💡
Hmmm.. Now it says, Key isn't passenger or conductor. Please sign your own tickets. which is the same message I get when signing the token with a random [invalid] secret.
Time to rethink! Remember the comments in the JS snippet?
Pair them with the response we received from the /pay endpoint.
We have already confirmed that the signing key is correct, so the first part must be the MD5 hash of the headerKid in raw format (rather than hex).
Let's test it; we know the passenger kid is passenger_key, so we can MD5 it, decode from hex, and then encode in unicode format.
It's a match! Let's take a step back, though. Before the unicode escaping, the raw string is _Rò sÜxÉÄÅ´\ä. Therefore, whenever the following line executes:
It's actually executing:
Any thoughts?? 🧠
Maybe if the MD5 hash decoded to something like 'or 1=1--? 🤔
SQL Injection
I'd already had a suspicion about SQLi but wasn't sure how to accomplish it. For example, how do I find a string that, when hashed, will produce a string of hex values that, when decoded (unhexed), begins with 'or 1=1--?
My teammate already solved the challenge and recommended a tool called hasherbasher 💡
This tool helps exploit poorly designed authentication systems by locating ASCII strings that, when MD5 hashed, result in raw bytes that could change SQL logic.
So, it turns out we don't need to construct a hash as precisely as I'd initially anticipated. Here's the hasherbasher regex: \A.*?'(\|\||or|Or|OR|oR)'[1-9]+?.*\z.
Providing the string 'or\d' (where \d is any decimal value) exists somewhere in the raw bytes, the SQL injection should succeed. Here's the example from GitHub.
If we MD5 DyrhGOYP0vxI2DtH8y, we get 6c0e97fda5c225276f522735b381a25b.
If we decode 6c0e97fda5c225276f522735b381a25b from hex, we get lý¥Â%'oR'5³¢[
Why would this work? It's basically SELECTing all of the keys from the database, WHERE the kid = ${md5("'lý¥Â% OR 5³¢[")}.
The first condition returns false, since no kid exists called ${md5("'lý¥Â%.
The second condition returns true, since (\d) is always true, even if it's in string format ('\d') and followed by letters ('\d\w+').
To demonstrate this fact, try the following query in an online SQLite interpreter.
It returns zero results, while this query returns all rows from the DB.
The same applies to MariaDB, but PostgreSQL and MSSQL respond with an error.
Anyway, returning to our SQL statement, we have two conditions: one is true, and one is false. If we OR these results, the overall condition returns true (0 || 1 = 1), and all keys will be returned from the DB.
Time to test it out 🙂
We send the request with the new token and receive all the keys in return 😎
JWT Forgery
Now we need to forge a brand new JWT for the conductor using the associated key: conductor_key_873affdf8cc36a592ec790fc62973d55f4bf43b321bf1ccc0514063370356d5cddb4363b4786fd072d36a25e0ab60a78b8df01bd396c7a05cccbbb3733ae3f8e
Finally, we submit the request and receive the flag.
Flag: uiuctf{sigpwny_does_not_condone_turnstile_hopping!}
Last updated