Layover is a Hack The Box Season 12 machine that rewards patience and careful enumeration. No single step in the chain is exotic. What makes it interesting is that each discovery depends on the previous one, and the overall path moves across three very different domains: wireless networking, web application security, and local Linux privilege escalation.
This post is a discussion of the attack chain and the underlying weaknesses. Command-level detail and full reproduction steps are reserved for the detailed writeup, available through the link at the end of this post.
Overview of the Chain
The compromise begins with access to a wireless-capable jump host. From that position, an internal wireless network is visible, and it is configured without any layer-2 encryption. A login submitted over plain HTTP on that network is captured in the clear. Those credentials open an internal web portal running Craft CMS 5.9.8.
The authenticated account is a low-privileged Content Editor rather than an administrator. A known Craft CMS vulnerability for that version requires administrator rights, so it does not apply directly. However, the underlying weakness is reachable from a lower-privileged endpoint that the original fix did not cover. That endpoint allows a Yii2 behavior injection to reach a command execution sink, granting code execution as the web server user.
The execution sink is constrained by PHP's escapeshellcmd(), which removes the metacharacters a reverse shell would need. The constraint does not eliminate the vulnerability; it narrows the exploitation to a single binary with arguments. That is enough to build a reliable file-read capability.
Reading the application's environment file exposes a security key and database credentials. The key decrypts a stored relay password, which authenticates a second account over SSH and yields the user flag. On that second host, a locally running CUPS 2.4.16 service is vulnerable to a privilege escalation that abuses the daemon's administrative token exchange, leading to a forged sudoers entry and root.
Weaknesses Discussed
Open wireless with HTTP. The wireless phase required no cryptographic attack. The network used no encryption at all, and the login form was submitted over plain HTTP. The credentials were readable by any station within range. This is not a legacy concern. It remains a live risk wherever open networks are deployed alongside unencrypted application traffic.
Monitor mode versus promiscuous mode. A common point of confusion is the difference between the two. Promiscuous mode only exposes traffic on networks the adapter has already joined. Monitor mode captures every 802.11 frame on a channel regardless of destination. The distinction matters when designing a capture, and it is the reason a dedicated monitoring interface is useful.
Craft CMS patch bypass. The vulnerability in this version of Craft CMS is an authenticated remote code execution reachable through a Yii2 behavior injection. The original fix restricted the vulnerable path to administrator-only contexts, but a separate lower-privileged endpoint continued to reach the same underlying sink. This is a familiar pattern: a patch that constrains one entry point without addressing the shared code path beneath it.
Constrained remote code execution. When a sink passes through escapeshellcmd(), pipes, redirection, command separators, and quotation marks are stripped. A reverse shell is not possible. A single binary with arguments still executes. This is a useful reminder that filtering reduces the surface of an exploit without removing the vulnerability, and that a constrained primitive can still be leveraged into something more useful.
Secrets stored beside the keys that protect them. The application stored an encrypted relay password in its database and the key that decrypts it in its environment file. Reading the environment file defeated the protection entirely. Encryption is only as strong as the separation between the ciphertext and the key, and colocating them on the same host undermines that separation.
Custom application modules. The decisive clue in the credential recovery phase was not in the framework. It was in an application-specific module that documented how the relay password was protected and decrypted. Reviewing custom code is often more productive than reviewing the framework, because custom code is where developers make assumptions about what is safe to store and how.
CUPS privilege escalation. CUPS 2.4.16, when running as root and listening on the loopback interface, is vulnerable to an authentication token replay. A rogue IPP server can trigger the daemon's authentication exchange and capture its administrative token. That token grants control over the real daemon, and an administrator is permitted to create printers whose device URIs point to local files. A print job whose content is a valid sudoers line is then written to disk by the root-owned daemon. Services that run as root, speak a network protocol, and trust localhost are recurring candidates for privilege escalation.
Lessons That Transfer
The value of this machine is in the transitions. A wireless weakness becomes a web foothold. A constrained web execution becomes a file-read primitive. A file-read primitive becomes a credential recovery. A credential recovery becomes lateral movement. Lateral movement exposes a local service, and the local service becomes root.
Each step is a known category of issue. The difficulty is in recognizing how they connect, and in not abandoning a step because its immediate output seems limited. A blind command execution that returns nothing is still useful if it can write to a location the attacker controls. A stored secret is still useful if the key that protects it can be read. A printing daemon is still dangerous if it runs as root and can be convinced to write a file.
Enumeration discipline matters more than any single exploit. Reading process environments, reviewing custom application code, and checking which local services run as root are all standard practices, and here they were decisive.
Notes
Writeups of this kind are published only after the machine is retired or otherwise no longer active on the platform. Publishing a full reproduction while a machine is still live would undermine the challenge for other players and would violate the platform's expectations. The discussion above is intentionally limited to concepts and root causes.
The techniques described here are specific to an authorized laboratory environment. They should not be applied to any system without explicit written authorization. The purpose of documenting them is to help defenders understand how small weaknesses combine, and to help practitioners recognize the patterns in their own environments.
A detailed, command-level writeup with full reproduction steps, sample outputs, and the complete attack chain is available for supporters. It covers the wireless capture setup, the Craft CMS exploitation in detail, the file-read primitive, the secret recovery, and the CUPS privilege escalation, along with the reasoning behind each decision.
Comments
Post a Comment
Express your opinion