This year I participated with Flag Fortress 2, and we reached the 2nd place (which is well above my goals I set for myself two years ago).
Here are writeups of two of the challenges:
Web - Call the Manager pliz!
After accessing the challenge link, we are redirected to /fetcher. We'll get back to it later. We can also notice that the source code ZIP is commented in the HTML.
After downloading it we can view the following routes and controllers:
Let's start with the 'flag' route (this is what we eventually want, right?).
According to the code, when accessing /flag, before the execution of 'FlagController.getFlagFinaleFlag' method there are two middleware (Middleware are functions that process requests and responses, sitting between the server receiving a request and the controller). One of them is for token authentication and the other is for validating that the user role is 'admin'.
Inside this controller we can see that the mentioned method probably reads the actual flag. But we can see that there is another method (getFlags) that was not mentioned in the /flags route or anywhere else in the code, and it is vulnerable to SQL Injection.
Although it is not implemented in the code, let's try accessing it anyway using the /flag route, and the parameter mentioned in the code (id). It seems we need an access token.
Searching the code for this error, brings us to the 'authenticateToken' middleware.
So we probably need an account. The 'users' route mention a creation process but there is a middleware that checks that the request originates from localhost.
The method requires username and password, and we cannot control the user's role which is set to 'user'.
Back to the /fetch path, we can exploit an SSRF vulnerability (can also be identified in the code). Using that, we can set the domain as 'localhost' and bypass the localhost middleware. We can see that we are able to create a new user, login with its credentials and receive an access token (the login functionality can also be understood from the code).
Using the access token, we can exploit the SQLI I have mentioned earlier. In a normal behavior it should return 'id' and 'flag' which are integer and string so we should keep this structure so there will be no errors.
I guessed that the first user probably has an 'admin' role, so searched for the first user. It makes sense since the challenge author's name is Liav (it is also possible to replace 'username' with 'role' in the payload just to make sure).
Same for password:
I logged in with these credentials, retrieved the access token and accessed /flags/flag.
Radio Frequency - Covert Signal
The challenge provided a WAV file that sounded very similar to an SSTV transmission (https://www.youtube.com/watch?v=SffT9U8scBc), so I said to myself, 'Oh, this should be easy,' and opened the SSTV software I usually use (RX-SSTV). After trying different modes, I realized there was more to it.
I had a hunch from the start that it would not be straightforward and that the challenge description probably contained hints. Some of the keywords would likely be Olivia, 4:00, and 125.
After searching a bit, I discovered that Olivia is the name of an MFSK mode, which is a method of delivering data (usually text) using radio frequencies, compared to SSTV, which is used to deliver image data.
I downloaded some software and struggled a bit in the beginning.
But then I downloaded one that seemed pretty simple to use.
After choosing the correct mode (Olivia OL 4-125) and loaded the WAV file, the flag was written letter by letter.
Happy hacking,
Orel 🥥
Congrats Orel and team on beating your goal! Excellent write up as always ☺️