Laboratory

There is a balding scientist fiddling with a beaker in the picture. Regardless starting with the machine by firing it up and noting its ip address .

Reconnaisance

nmap result :-

1
2
3
4
5
6
7
8
9

[*] Nmap: PORT    STATE SERVICE  VERSION
[*] Nmap: 22/tcp  open  ssh      OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
[*] Nmap: 80/tcp  open  http     Apache httpd 2.4.41
[*] Nmap: 443/tcp open  ssl/http Apache httpd 2.4.41 ((Ubuntu))
[*] Nmap: Service Info: Host: laboratory.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel
[*] Nmap: Read data files from: /usr/bin/../share/nmap
[*] Nmap: Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
[*] Nmap: Nmap done: 1 IP address (1 host up) scanned in 170.27 seconds
[*] Nmap: Raw packets sent: 131180 (5.772MB) | Rcvd: 113 (4.972KB)

three usual ports 22, 80 and 443 . will start by checking whats on the http server .

the http server has a static website about the laboratory . there is error in the https certificate though which says it was generated for git.laboratory.htb and not laboratory.htb .

there is a gitlab hosted on the git subdomain. gitlab, laboratory , geddit ?

a quick searchsploit for gitlab gives the following results

can boil down to which of them will potentially work if could know the version of gitlab.

sir google ordains this is vulnerable to Arbitrary file read via the UploadsRewriter when moving and issue .

This can be used to get RCE

Will get the secret_key_base from /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml using the arbitrary file read and then use the experimentation_subject_id cookie with a Marshalled payload.

there is a metasploit exploit of the same vulnerability , which when used , dropped in a shell as user git .

This module provides remote code execution against GitLab Community Edition (CE) and Enterprise Edition (EE). It combines an arbitrary file read to extract the Rails “secret_key_base”, and gains remote code execution with a deserialization vulnerability of a signed ‘experimentation_subject_id’ cookie that GitLab uses internally for A/B testing. Note that the arbitrary file read exists in GitLab EE/CE 8.5 and later, and was fixed in 12.9.1, 12.8.8, and 12.7.8. However, the RCE only affects versions 12.4.0 and above when the vulnerable experimentation_subject_id cookie was introduced. Tested on GitLab 12.8.1 and 12.4.0.

now have to do privilege escalation . will run the peas script to check our prospects.

Among a large dump of results the most interesting one in this situation was -

1
2

If you have enough privileges, you can change the password of any user runnig: gitlab-rails runner 'user = User.find_by(email: "admin@example.com"); user.password = "pass_peass_pass"; user.
password_confirmation = "pass_peass_pass"; user.save!'  q

did this and changed password for the admin user , so can login on gitlab and check what they got

got Dexter’s ssh keys and can login and get user flag

upon login checked all suid binaries using :-

1

for file in $(find / -perm -u=s -type f 2>/dev/null ); do ls -al $file; done;

got an interesting binary

1

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

upon checking what it does , it runs the following highlighted command

since this is owned by root this runs as root . so will try to inject bash -i someway in this while it is running .
for this will create a chmod binary of our own with the command bash -i in it and change the path to use the dir with our chmod binary in it while running the docker-security command .

and we have root