Jail — HackTheBox Machine Writeup

All custom exploit scripts, helper utilities, and diagnostics developed for this machine are attached below. Click any script to launch the Interactive Code Explorer to inspect syntax-highlighted code, search with Ctrl+F, copy, or download the files directly.

::Port scan

The box answers on six TCP ports:

MTU blackhole: the web server headers arrived but the 2 KB body never did — a classic path-MTU problem through the VPN. Clamping the MSS on the route fixed it instantly:

::The website

Port 80 serves a single page of ASCII art — a jail cell. Nothing dynamic.

But a directory listing at /jailuser/dev/ leaks the source code of the service running on port 7411, the compiled binary, and the build script

compile.sh is the first big hint:

Two words that change everything: -m32 (32-bit binary) and -z execstack (the stack is executable — DEP is off). On a 32-bit box with an executable stack, a classic stack overflow becomes trivially exploitable.

::The NFS shares

Both shares are exported to everyone. We'll come back to these — the /var/nfsshare one is the key to the next user.

The jail.c source is short. Two functions matter:

Three things stand out:

1. ▹Hardcoded credentials: admin / 1974jailbreak!.
2. ▹DEBUG mode leaks the stack address of userpass — a gift for exploit development.
3. ▹strcpy(userpass, password) with a 16-byte destination and no length check — the classic overflow. The password comes straight from the PASS token we send to the service.

The service runs on port 7411 and speaks a tiny FTP-like protocol

The leaked address 0xffffd610 is identical across connections — the fork()-per-connection model gives every child the same stack layout, so a leak in one connection is valid in the next. No ASLR drama.

::Understanding the Vulnerability (The "Why")

In C, when a function creates local variables—like char userpass[16] inside auth()—it allocates that memory on the call stack.

When auth() is called, the CPU also stores critical bookkeeping data on the stack so it knows where to resume execution when the function returns:

The vulnerability is inside auth():

strcpy() copies characters from our password into userpass without checking length. Because userpass is only 16 bytes:

1. ▹Bytes 0-15 fill userpass[16].
2. ▹Bytes 16-19 overwrite char *response.
3. ▹Bytes 20-23 overwrite the saved EBP.
4. ▹Bytes 24-27 (at offset 28 bytes) overwrite the Saved Return Address (EIP).

When auth() finishes and executes the ret (return) instruction, the CPU pops whatever value is in Saved EIP into the instruction pointer and jumps there. By overwriting this address, we hijack execution flow.

::Verifying the EIP Offset with GDB

Instead of guessing the offset, we verify it dynamically using a cyclic pattern (De Bruijn sequence) in GDB:

The offset is confirmed: exactly 28 bytes of padding reaches the return address.

::Crafting the Shellcode (Executable Stack)

Because compile.sh used -z execstack, the operating system leaves the stack memory marked as executable (RWX). We don't need complex ROP gadgets—we can place raw machine instructions (shellcode) directly on the stack and tell EIP to jump to them.

Our shellcode must satisfy three conditions:

1. ▹Zero Null Bytes (\x00): Functions like strcpy() and sscanf() terminate upon encountering \x00. A null byte would truncate our payload before reaching the stack.
2. ▹Socket Redirection: The server's handle() function already duplicated STDOUT (fd 1) and STDERR (fd 2) to the network socket, but not STDIN (fd 0). We call dup2(1, 0) so whatever we send over the network goes straight to the shell's input.
3. ▹Spawn /bin/sh: Call execve("/bin//sh", NULL, NULL) using the Linux x86 syscall interface (int 0x80).

Assembly breakdown:

The resulting 27-byte null-free machine code:

::Exploit Payload Layout & Execution

Our payload is constructed in three parts:

• ▹Why base + 32? base is the leaked address of userpass (+0x00). The return address sits at +0x1C (28 bytes) and takes 4 bytes. The shellcode immediately follows at +0x20 (32 bytes). Setting EIP to base + 32 jumps straight into our shellcode.

The exploit runs in two phases:

1. ▹Connection 1: Send DEBUG, USER admin, and PASS test to leak the stack address of userpass (e.g., 0xffffd610).
2. ▹Connection 2: Send USER admin and PASS <payload> to trigger the overflow and spawn the shell.

Running the exploit:

We're nobody, CentOS 7.3, SELinux enforcing. Enumeration time:

The interesting bit is the NFS option no_all_squash. With root_squash, the root user gets mapped to nobody — but every other uid passes through unchanged. Local uid 1000 on our Kali box is kali; on Jail, uid 1000 is frank. Anything we write to the share as uid 1000 is owned by frank on the remote side. And the SUID bit survives the trip.

So the plan: compile a tiny helper that calls setresuid(1000,1000,1000) and spawns a shell, drop it on the share as the kali user, set it SUID, and run it from the nobody shell.

Compiled statically — the remote CentOS 7 glibc (2.17) is far older than Kali's, and a dynamic binary would refuse to run with GLIBC_x not found.

Why setresuid matters: a SUID binary owned by frank gives us euid 1000, but the real uid is still 99 — and bash drops privileges when ruid ≠ euid. Setting all three ids to 1000 keeps the shell fully frank.

I installed my SSH key as frank for a stable foothold, then claimed the first flag:

As frank, sudo -l reveals a second sudo rule:

We can open that one file in rvim — restricted vim — as adm. The restriction is real: :! shell commands and :sh are blocked. But rvim still embeds interpreters. This vim was built with +python/dyn, and vim script can hand the whole process to Python:

One line, and the vim process becomes a plain shell running as adm.

/var/adm is adm's home (the box uses a nonstandard home dir) and it contains a hidden .keys directory — the road to root.

::The note and the cipher

The second file is Atbash — the alphabet mirrored onto itself (A↔Z, B↔Y, ...). A tiny decoder reveals the message:

The user is frank — Frank Morris escaped Alcatraz in 1962. So the password is Morris + 4 digits + a symbol.

::The encrypted archive

keys.rar holds rootauthorizedsshkey.pub (root's authorized SSH key) and it's password-protected. We pull it to our box and attack it.

The password shape is exactly Morris?d?d?d?d?s — a hashcat mask over 10 digit × ~30 symbol combinations (~330k candidates). But the intended answer is guessable directly: Morris1962! (escape year + !).

::Recovering the private key

The extracted public key is a 512-bit RSA key. RsaCtfTool runs its whole battery of attacks and lands on the Wiener attack — a small private exponent d, which can be recovered from n and e alone via continued fractions:

::Root

The box runs OpenSSH 6.6.1, which only offers SHA-1 RSA signatures — modern clients refuse them by default, so the key needs the legacy algorithms re-enabled:

• ▹GTFOBins — rvim
• ▹Wiener's attack (Wikipedia)
• ▹RsaCtfTool
• ▹Atbash cipher (Wikipedia)
• ▹Frank Morris — Alcatraz escape (Wikipedia)
• ▹HackTheBox — Jail