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 .
nmap result :-
[*] Nmap: PORT STATE SERVICE VERSION
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_idcookie 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 -
If you have enough privileges, you can change the password of any user runnig: gitlab-rails runner 'user = User.find_by(email: "email@example.com"); user.password = "pass_peass_pass"; user.
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 :-
for file in $(find / -perm -u=s -type f 2>/dev/null ); do ls -al $file; done;
got an interesting binary
-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