Identifying and Mitigating OpenSSH Vulnerabilities: In-Depth Analysis of SSH Private Key Leakage and Privilege Escalation Risks

1. Host Discovery

Launch the virtual machine to directly obtain the host’s IP address.

2. Port Discovery (Services, Components)

Use the command `sudo nmap 10.58.81.112 -n -Pn -p- –reason -sV -sC -O` to obtain open ports, provided services, used components, and their versions on the host.

Certainly, here is the rewritten content: “Open Ports, including OpenSSH vulnerabilities, are a concern for network security as they can be targeted by attackers to gain unauthorized access.”	Provided Services	Used Components	Component Versions
22/tcp	ssh	OpenSSH	8.4p1
80/tcp	http	Apache	httpd 2.4.48
–	–	Linux	4.15 – 5.6

3. Vulnerability Discovery (Gaining Access)

Port 22/ssh Service

01. Component Vulnerabilities

Use the command `searchsploit OpenSSH`, and no Nday vulnerabilities were found for component OpenSSH 8.4p1.

02. Weak Password Vulnerabilities

Use the command `hydra -C /usr/share/seclists/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt 10.58.81.112 ssh`, no weak password vulnerabilities were detected.

Try another dictionary, use the command `hydra -C /usr/share/wordlists/legion/ssh-betterdefaultpasslist.txt 10.58.81.112 ssh`, no weak password vulnerabilities were detected again.

Port 80/http Service

01. Component Vulnerabilities

Use the command `searchsploit Apache`, no Nday vulnerabilities were found for component Apache httpd 2.4.48.

Using the command `searchsploit Apache | grep -i httpd`, again, no Nday vulnerabilities for Apache httpd 2.4.48 were found.

02. URL Discovery (Directories, Files)

1. Visit the homepage http://10.58.81.112/, found nothing, it’s a static page, classic CTF style.

2.1 From the port discovery (services, components) stage, a /robots.txt file was found that exposed the /~myfiles/ directory.

http://10.58.81.112/robots.txt

Visit the directory http://10.58.81.112/~myfiles/, again, nothing was found.

2.2 Use the command `dirb http://10.58.81.112 -r` to brute force website directories and files, no new directories or files were found.

2.3 Use the command `dirb http://10.58.81.112/~myfiles/ -r` to brute force directories and files under /~myfiles/, no new directories or files were found. That’s it, game over.

3.1 Since there’s a ~ before the /~myfiles/ directory, which is not a common entry in directory brute-force dictionaries, it may be a feature of the target website, so decided to try brute-forcing directories with the ~ prefix.

Use the command `wfuzz -c -z /usr/share/seclists/Discovery/Web-Content/common.txt –hc 404 http://10.58.81.112/~FUZZ` to perform fuzz testing, and indeed found new directories.

3.2 Use the command `dirb http://10.58.81/112/~secret/ -r` to brute force directories and files under /~secret/, found a file /~secret/index.html.

Access the file /~secret/index.html, which indicates the existence of “my” SSH private key file in the /~secret/ directory, it seems the brute-forcing intensity wasn’t enough and fuzzy testing should be used.

Additionally, it indicates that “my” name is icex64, suggesting that logging in to the SSH service could be achieved using the account “icex64” and SSH private key file.

3.3 Use the command `wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt -z list,”.txt”- –hc 403,404 http://10.58.81.112/~secret/FUZZFUZ2Z` for fuzz testing, attempting no file suffix and “.txt” file suffix, but no SSH private key files were discovered.

3.4 Could it be the wrong file suffix? Or the file name dictionary isn’t suitable? Or perhaps the file name requires a prefix? Is it prefixed with ~? Since it’s an SSH private key file, let’s try adding a . prefix.

Execute the command `wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt -z list,”.txt”- –hc 403,404 http://10.58.81.112/~secret/.FUZZFUZ2Z` for pattern testing, discovered the SSH private key file /~secret/.mysecret.txt.

Port 22/ssh Service

03. Private Key Leakage

1. Generally, using an SSH account and SSH private key file allows SSH service login, but this SSH private key file is unknownly encrypted or encoded. If encrypted, there’s no solution without the decryption algorithm and key; hopefully, it’s just encoded. Finally, it’s successfully decoded using base58.

2.1 Use the account “icex64” and SSH private key file to login to the SSH service, discovering that because the SSH private key file permissions are 0644, accessible by other users, it’s insecure, so the SSH service automatically switched to SSH password login. Use the command `chmod 0600 mysecret` to remove other users’ access permissions to the SSH private key file.

Using the account “icex64” and SSH private key file, discovered that the SSH private key file requires a decryption key. Operations teams, could this really happen?

2.2 Use the command `/usr/share/john/ssh2john.py mysecret > mysecret.john` to convert the SSH private key file into the format required by John.

Using the command `john mysecret.john –wordlist=/usr/share/wordlists/fasttrack.txt` to crack the SSH private key file’s decryption key, found P@55w0rd!. Operations teams, could this really happen?

3. Use the account “icex64”, SSH private key file, and SSH private key file’s decryption key P@55w0rd! to successfully log in to the SSH service.

4. Privilege Escalation

01. perm

Use the command `find -perm 4000 2>/dev/null` to check for privileged commands in the system, none were found.

02. sudo

1. Use the command `sudo -l` to view the current user’s privileged commands, found able to execute the command `/usr/bin/python3.9 /home/arsene/heist.py` as the arsene user without a password.

Unfortunately, like icex64, the arsene user is just a regular user, only allowing privilege exploitation, not escalation.

More regrettably, neither `/usr/bin/python3.9` nor `/home/arsene/heist.py` command have write permissions, preventing the writing of privilege escalation commands.

2. A turning point is found because the /home/arsene/heist.py file imports the webbrowser module. If write permission is available on the webbrowser.py file, injecting a privilege escalation command is feasible.

Fortunately, write permission exists for the webbrowser file, located at /usr/lib/python3.9/webbrowser.py.

3. Search for Python privilege escalation commands on GTFOBins:

Write the privilege escalation command into the /usr/lib/python3.9/webbrowser.py file.

4. Execute the command `/usr/bin/python3.9 /home/arsene/heist.py` as the arsene user without a password, obtaining arsene user privileges successfully.

References:

1. Python Privilege Escalation article, published on 2021-06-03: Linux Privilege Escalation: Python Library Hijacking[1]
2. Chinese translation of the Python Privilege Escalation article, published on 2021-06-09: Linux Privilege Escalation: Python Script Exploitation Hijacking Methods[2]
3. The related CTF challenge link, published on 2021-10-21: Empire: LupinOne[3]
4. Speculation: The CTF challenge author likely referred to the Python Privilege Escalation article to design this vulnerability.

03. sudo

1. Use the command `sudo -l` to view the current user’s privileged commands, found able to execute the command `/usr/bin/pip` as the root user without a password.

2. Search for pip privilege escalation commands on GTFOBins:

3. Execute the command `/usr/bin/pip` as the root user without a password to gain root privileges, achieving privilege escalation.