At first, this web app seems straightforward, but thereโs something more lurking beneath the surface. It relies on a token for user authentication, but not everything is as secure as it seems. Look closely, and you might discover that the systemโs trust can be manipulated. The secret is hidden within the way this token is used. Can you find the key to unlock whatโs been concealed? The challenge is waiting for you to crack it. Submit your answer in the following format: ACECTF{3x4mpl3_fl4g}.
http://34.131.133.224:9999/
๐ฏ Challenge Files & Infrastructure
Provided Files
1
Files:None
๐ Initial Analysis
First Steps
Initially, the website appears as follows:
Site Presentation
We are told to log in to the /login route with a POST request, but even so, it’s always better to try with a GET request.
Login GET
In fact, as we can see from the GET request, I was able to extract the user and pass fields. Additionally, we are told that regardless of the credentials we send, just following the request format is enough to access. By opening BurpSuite, intercepting the request, and forming a POST with the fields in the JSON format I just found, I was able to receive a token as a response:
Burp Login
Most likely, it is a jwt, so I immediately tried to analyze it with https://jwt.io:
Jwt.io
As we can see from the analysis, the HS256 algorithm is used for the signature, and the payload is "user":"guest". In the case of the HS256 algorithm, the vulnerability to exploit is most likely an Algorithm Confusion, perhaps by setting the algorithm to None or performing a secret cracking to craft the token with the cracked secret key. (By running jwt-cracker with the rockyou.txt wordlist, I did not find any occurrences, so I decided to proceed with Algorithm Confusion). Let’s move on to the exploitation.
๐ฌ Vulnerability Analysis
Potential Vulnerabilities
JWT None Algorithm Supported
๐ฏ Solution Path
Exploitation Steps
Initial setup
First of all, when specifying the None algorithm, the signature of the jwt (the part after the last dot) must be removed. So we initially have:
(Attention not to remove the last . since removing it would make the jwt format invalid, knowing that it consists of header.payload.signature). Once this is done, there are many ways to modify the fields of the jwt, for example by doing base64decode, changing the field, and then re-encoding it to assemble the token. Alternatively, you can use the faster jwt-tool. Let’s proceed with the exploitation phase.
Exploitation
Once the signature is removed, we can pass the token to jwt-tool and specify the -T (Tamper) flag to modify the fields of the jwt provided:
The last thing we need to figure out is which route to send it to in order to get the flag, since sending it to /login or / will return an error in the first case (due to the expected user and pass fields) and a Not Modified status code in the second case, indicating we’re not on the right track. So, I decided to inspect the robots.txt file to see if it contains any route:
Robots
In fact, as we can see, the /flag route is specified. I tried making an OPTIONS request with curl:
1
curl -X OPTIONS http://34.131.133.224:9999/flag
I get that the only available method is POST. So, I assume the new token needs to be forwarded in a json payload, exactly as we received it during the login phase. Indeed, by making a POST request to /flag set up in the way just mentioned, I was able to obtain the flag.
Flag capture
Manual Flag
๐ ๏ธ Exploitation Process
Approach
The automated exploit makes a POST request to /login to extract the JWT token, then removes the signature and sets alg to None and user to admin. After that, it makes a POST request to /flag with the forged token and extracts the flag from the response.
