These are my solutions for Google CTF 2022
This is my first official CTF (Capture The Flag) that will be held by a big company like Google so I hope you will enjoy my writeups.
the first as the challenge says is about the log4j vulnerability. if you don't know what is that, I recommend seeing this video to have an idea of how it works:
https://www.youtube.com/watch?v=0-abhd-CLwQ
The challange URL is: https://log4j-web.2022.ctfcompetition.com
the website looks like this:
there is a box that we can send some commands, also we can source in a file called App.java for the backend and the app server called app.py by checking the codes, we found out there that page working with some commands that are given by the source:
- help --> prints hints for using it.
- /help --> same as
help - /wc --> it will count all words after the first space
- /repeat --> it will print the string after the first space
- /time --> it will show the time of the system
in the attachment's file, there are interesting files too, by checking the log4j2.xml file, we will see :
so we can use log4j vulnerability on the ${sys:cmd} part
but how we can see, which command and how that variable will be initialized? To find that, we need to run the server locally and check its log output of it.
for example, I sent /repeat hello world to our chatbot box, and here is the output:
according to the picture, we can see the first string before space will be in ${sys:cmd}. so we just need to send our payload in the first string before space, like the video I send above, the first thing we should do, checks vulnerability by a local variable such as :
- ${java:version}
- ${java:runtume}
- ${java:os}
- etc
so I will test with ${java:version} we need to send ${java:version} to our local server and check the output and see is working or not. here is the output:
so we can see the payload working great, now we should send our main payload to get the flag. the second thing for getting access to a server like RCE, we need to use JNDI vulnerability, so we must check the version of log4j because it might use the version that vulnerability has been patched.
by checking the pom.xml file in the attachments we will see the Log4j version is 2.17.2.
so we will check if there is a vulnerability on that or not. the version used on this challenge doesn't have JNDI vulnerability so we need to find another way with that variable.
by guessing the parameter used in the request, we will face an interesting Exception.
i sent this payload: ${java:flag} xD and this happened.
so I decode to pass the real Flag variable according to App.java file
that line means flag set in environment variables with FLAG name.
so our payload will be this: ${java:${env:FLAG}} and the result will be:
and the reason is stacktrace goes to stdout. here is the flag: CTF{d95528534d14dc6eb6aeb81c994ce8bd}