Trick
https://app.hackthebox.com/machines/477
Nmap
DNS
Starting out on DNS we add 10.10.11.166 to our attacking systems secondary DNS servers. Performing a zone transfer with dig
reveals the sub-domains root.trick.htb
and preprod-payroll.trick.htb
.
Note: Add these into /etc/hosts.
Browsing to http://preprod-payroll.trick.htb reveals the following login prompt.
Note: add to /etc/hosts
.
Performing directory enumeration with dirseach reveals the /user.php
page.
Viewing the page we find the username Enemigosss. We find the page buttons are not actionable.
Viewing the page source reveals come code that indicates parameters that we can use.
Testing the page parameter we are taken to a new page however, unable to action in any meaningful way further.
the id=n
parameter could possibly be susceptible to SQL injection so we fire up sqlmap
and command in the URL with the parameters.
Running through with the --batch
and --tables
parameters we are shown the users table on the payroll_db database.
We can then dump the contents of the users table.
which reveals the following credentias credentials: Enemigosss:SuperGucciRainbowCake
Going back to the login page on http://preprod-payroll.trick.htb we are able to proceed with the given credentials.
We find that none of the pages provide any interesting information so we use wfuzz to fuzz for further pages.
Finding the page http://preprod-payroll.trick.htb/index.php?page=site_settings we are presented with an opportunity for file upload. However, I was not able to get this working. Viewing the requests through a proxy shows our working user does not have permission for file upload.
Looking again at the subdomain preprod-payroll we can fuzz the subdomain for other potentials domains where the word "payroll" is fuzzed which identifies "marketing".
Adding preprod-marketing.trick.htb
to our hosts file we then browse to the domain and find an additional host.
Going through the available pages we find the parameter /index.php?page=services.htm
l can likely be fuzzed for further pages or maybe even LFI.
Checking for LFI:
We get various hits for the bypassing to read /etc/passwd
.
Seeing that the user michael exists on the target system we fuzz for well known files and get a hit for the id_rsa
ssh key.
Copying the contents into id_rsa
and using chmod
to set the appropriate permissions. We are then able to SSH
into the target system.
Grabbing the user.txt
flag.
Checking sudo permissions with sudo -l
. We see we have the ability to restart the fail2ban
service as root without specifying the root password.
Some research into privilege escalation with fail2ban. Having the ability to edit the iptables-multiport.conf
file presents opportunity for privilege escalation.
The user michael has directory permissions over /etc/fail2ban/action.d
which means we can replace files within the directory with our own files.
First off, copy the current contents of iptables-multiport.conf
and make appropriate changes. Below we are setting the command to create a new root user with the password Password123.
The command will be executed under "actionstart" which executes the given command for when the service starts.
The following commands then need executing in quick succession as the directory resets often.
Copy the preconfigured iptables-multiport.conf
we created earlier into the configuration file and save.
Wait a short while, check /etc/password and we should see our new user.
We can then use su
to switch to our new root user. For some unknown reason during the process of changing user I was moved directly to the root user. No complaints...
Last updated