HTB - Expressway Write-Up

Summary

Expressway is a Linux machine on Hack The Box that involves exploiting a weak Pre-Shared Key (PSK) in an IKEv1 VPN service to gain initial access. Privilege escalation is achieved by bypassing a flawed security policy in a custom sudo binary that relies on the system’s hostname. This write-up details the process from initial reconnaissance to gaining root privileges, concluding with remediation steps for the identified vulnerabilities.

Target

• IP Address: 10.10.11.87
• Hostname: expressway.htb

Reconnaissance

TCP Port Scan

The initial reconnaissance phase began with a TCP port scan using nmap to identify open ports and running services.

nmap -sC -sV -v 10.10.11.87

• -sC: Run default Nmap scripts.
• -sV: Probe open ports to determine service/version info.
• -v: Increase verbosity level.

The scan revealed that the target identified itself as expressway.htb. To facilitate easier access, this hostname was mapped to the target’s IP address in the local /etc/hosts file.

sudo sh -c 'echo "10.10.11.87 expressway.htb" >> /etc/hosts'

UDP Port Scan

A UDP scan was performed to discover services that might not be running over TCP.

nmap expressway.htb -sU --top-ports 100

• -sU: UDP scan.
• --top-ports 100: Scan the 100 most common UDP ports.

The UDP scan identified several open or filtered ports, with ports 500 (ISAKMP/IKE) and 4500 (IPsec NAT-T) being of particular interest. These ports indicate the presence of an IPsec VPN endpoint, which presents a unique attack surface compared to more common services like web servers or SSH. The Internet Key Exchange (IKE) protocol on UDP port 500 is used to negotiate security associations and can often be probed to reveal information about the VPN gateway’s configuration, such as supported encryption transforms, vendor IDs, and authentication methods.

Gaining Initial Access

IKE Enumeration

With an IKE service identified, the next step was to probe it for configuration details using ike-scan.

ike-scan -M 10.10.11.87

• -M: Use a main mode probe.

The scan returned a successful Main Mode handshake, revealing the following configuration:

• Authentication Method: Pre-Shared Key (PSK). This is a critical finding, as PSKs can often be weak and susceptible to cracking.
• Encryption: 3DES (a legacy cipher).
• Hashing Algorithm: SHA1.
• Diffie-Hellman Group: Group 2 (1024-bit).
• Vendor IDs: The gateway supports Extended Authentication (XAUTH), suggesting it may require username/password credentials after the initial IKE exchange.

Cracking the Pre-Shared Key

The use of PSK authentication opens up an opportunity for an offline cracking attack. By sending an Aggressive Mode request with a fake ID, we can capture the hash of the PSK.

ike-scan -P -M -A -n fakeID expressway.htb

• -P: Save the PSK hash to a file (default: ike.psk).
• -A: Use Aggressive Mode.
• -n fakeID: Provide a group name (ID) to trigger the hash response.

The captured hash was then cracked using psk-crack and the rockyou.txt wordlist.

psk-crack -d /usr/share/wordlists/rockyou.txt ike.psk

The tool successfully cracked the hash, revealing the PSK: freakingrockstarontheroad.

The recovered PSK was validated by re-probing the gateway:

ike-scan --psk='freakingrockstarontheroad' 10.10.11.87

Obtaining the User Flag

The cracked PSK was reused as a password for the ike user account, which was discovered during the IKE enumeration phase (leaked as a user identity in Aggressive Mode). This allowed for a successful SSH connection.

ssh [email protected]

Upon successful authentication, the user flag was retrieved.

Privilege Escalation

Enumerating Sudo

Post-exploitation enumeration revealed a custom sudo binary located at /usr/local/bin/sudo. When executed, this binary produced a custom denial message that included the current hostname (expressway). Further investigation of system logs (e.g., Squid proxy logs) uncovered a second, internal hostname: offramp.expressway.htb.

This suggests that the custom sudo binary implements a security policy based on the hostname from which the command is executed.

Bypassing the Sudo Policy

The security policy can be bypassed by using the -h flag in the sudo command to specify a different host. By setting the host to offramp.expressway.htb, the restrictive policy was circumvented, allowing for command execution as the root user.

/usr/local/bin/sudo -h offramp.expressway.htb bash

This command spawned a root shell, granting full administrative privileges on the system.

With root access, the final flag was captured.

Vulnerability Analysis and Remediation

1. Weak IKEv1 PSK & Information Leak

• Vulnerability: The IKEv1 service was configured with a weak, dictionary-based Pre-Shared Key. Furthermore, its support for Aggressive Mode allowed for the leakage of a user identity (ike) and the PSK hash, enabling an offline cracking attack. The PSK was also reused as the password for the ike user’s SSH account.
• Remediation:
  • Disable IKEv1 Aggressive Mode: This mode is known to be insecure and should be disabled on all production VPN gateways.
  • Enforce Strong PSKs: If PSKs must be used, they should be long (>20 characters), randomly generated, high-entropy strings that are not susceptible to dictionary attacks.
  • Implement Certificate Authentication: The industry best practice is to use IKEv2 with certificate-based authentication, which provides stronger security guarantees than shared secrets.
  • Eliminate Credential Reuse: Critical infrastructure keys, such as a VPN PSK, must never be reused for user account passwords.

2. Custom Sudo Policy Bypass

• Vulnerability: A custom-compiled SUID root binary replaced the standard sudo, implementing a flawed, context-aware security policy based on the system’s hostname. This policy was easily bypassed by specifying an alternate hostname.
• Remediation:
  • Avoid Replacing Core Security Binaries: Standard, repository-provided security tools like sudo are heavily audited and maintained. Replacing them with custom code introduces significant risk.
  • Utilize the sudoers File: All privilege management logic should be configured within the /etc/sudoers file. This file provides a powerful and secure mechanism for defining granular permissions without modifying the sudo binary itself.
  • Adhere to the Principle of Least Privilege: Security policies should be deny-by-default. The flawed policy was likely implemented as an allow-by-exception rule, which failed when the context (hostname) was altered.

3. Information Disclosure via Logs

• Vulnerability: The Squid proxy logs were world-readable, leaking sensitive internal network information, including the internal hostname offramp.expressway.htb.
• Remediation:
  • Restrict Log File Permissions: Log files often contain sensitive data and should only be readable by root and dedicated administrative or monitoring groups. A permission set such as 640 (rw-r-----) is recommended as a standard practice.