[🥉 Bronze 3] flag는 서비스가 아니라 이미지 안에 있었다 — DreamHack Exercise: Docker 풀이

문제: DreamHack — Exercise: Docker 분류: Misc 난이도: 🥉 Bronze 3 FLAG: DH{docker_exercise}

"주어진 Dockerfile을 빌드해 이미지를 만들고 컨테이너를 실행해 보세요"라는 한 줄짜리 실습 문제다. 익스플로잇이 아니라 Docker로 챌린지가 어떻게 배포되는지 손에 익히는 게 목적이다. 서비스에 붙어 봐야 flag는 안 나온다 — flag가 어디 있는지부터 알아야 한다.

cat -n Dockerfile

문제 개요

풀이 흐름은 짧다. 바이너리가 flag를 안 준다는 걸 확인하고, Dockerfile을 읽어 flag가 이미지 안으로 복사된다는 사실을 파악한 뒤, 같은 Dockerfile로 이미지를 빌드·실행해 그 안의 flag를 읽는다.

🧩 배경 — Dockerfile · 이미지 · 컨테이너

Docker는 애플리케이션과 그 실행 환경(OS 패키지, 파일, 설정)을 이미지(image) 하나로 묶어 두고, 그 이미지를 띄운 인스턴스를 컨테이너(container) 로 돌리는 도구다. 워게임 서버도 보통 이렇게 배포된다 — "이 바이너리를, 이 우분투 환경에서, 이 권한으로 돌린다"를 한 파일에 적어 두는 것이다.

그 설계도가 Dockerfile 이다. 명령 한 줄이 이미지의 한 레이어(layer) 가 된다.

• FROM — 베이스 이미지(여기선 ubuntu:22.04)
• RUN — 빌드 중 실행할 명령(패키지 설치, 사용자 추가 등)
• ADD / COPY — 호스트의 파일을 이미지 안으로 복사
• USER — 이후 단계와 컨테이너 실행 시의 기본 사용자
• CMD — 컨테이너가 떴을 때 실행할 명령

여기서 핵심은 ADD 다. 빌드 시점에 호스트에 있던 파일이 이미지 안에 통째로 들어간다. 이미지를 가진 사람은 그 파일을 그대로 꺼낼 수 있다 — 이게 이번 문제의 전부다.

🔬 정찰 — 받은 파일과 바이너리

받은 파일은 셋이다.

Dockerfile
deploy/
├── chall    # 서버에서 socat으로 노출되는 바이너리
└── flag     # 이미지로 들어갈 flag 파일

먼저 바이너리부터. file로 종류를 보고 직접 실행해 보면, 그리고 main을 디스어셈블해 보면 하는 일이 딱 하나다 — puts로 문자열 하나 출력하고 끝.

main:
    lea  rax, [rip+0xeac]   ; "Hello Beginners!"
    mov  rdi, rax
    call puts
    mov  eax, 0
    ret

flag를 읽는 코드도, 입력을 받는 코드도 없다. 그러니 라이브 서버에 접속해도 결과는 똑같다. 서버는 socat ... EXEC:/home/chall/chall 로 이 바이너리를 그대로 실행할 뿐이라, 네트워크로 넘어오는 건 "Hello Beginners!" 한 줄이 전부다.

정리하면 서비스(바이너리)는 flag로 가는 길이 아니다. flag는 다른 곳에 있다.

💣 핵심 — flag는 이미지 안으로 ADD 된다

Dockerfile을 다시 본다. 가운데 두 줄과 권한 설정이 전부다.

ENV user chall
 
ADD ./deploy/flag /home/$user/flag      # flag 파일을 이미지 안으로 복사
ADD ./deploy/$user /home/$user/$user    # 바이너리도 복사
 
RUN chown root:$user /home/$user/flag
RUN chmod 440 /home/$user/flag          # root와 chall 그룹만 읽기
 
USER chall
CMD socat -T 30 TCP-LISTEN:$chall_port,reuseaddr,fork EXEC:/home/$user/$user

flag 파일이 이미지의 /home/chall/flag 로 들어가고, 권한은 440 root:chall 이 된다. 즉 chall 그룹에 속한 사용자라면 읽을 수 있다. 그리고 컨테이너는 USER chall 로 돌아간다 — 바이너리(chall 사용자, chall 그룹)는 그 flag를 읽을 권한이 있지만, 정작 flag를 출력하는 코드가 없을 뿐이다.

원래 pwnable 문제라면 여기서 바이너리의 버그를 찾아 셸을 따고 cat /home/chall/flag 를 했을 것이다. 하지만 이 바이너리엔 버그가 없다. 대신 문제 설명이 길을 알려 준다 — "Dockerfile을 빌드해서 이미지를 만들고 실행해 보라." 그 이미지 안에는 우리가 받은 deploy/flag 가 그대로 들어 있다.

$ ./chall
Hello Beginners!
$ echo AAAA | ./chall
Hello Beginners!

🎯 풀이 — 직접 빌드해서 flag 꺼내기

방법은 Dockerfile이 시키는 그대로다. 이미지를 빌드한다.

docker build -t exercise-docker .

빌드 로그를 보면 Dockerfile의 각 줄이 레이어로 쌓이는 게 그대로 보인다 — apt-get install socat, adduser chall, 그리고 ADD ./deploy/flag /home/chall/flag 로 flag가 이미지 안으로 들어간다.

이제 컨테이너를 띄운다. 서비스(socat)에 붙으면 서버와 똑같이 "Hello Beginners!"만 나오지만, 컨테이너 안에서 chall 사용자로 flag 파일을 직접 읽으면 끝이다. chall 은 chall 그룹이라 440 root:chall 파일을 읽을 수 있다.

docker run -d --rm --name exdoc -p 2222:2222 exercise-docker
 
# 서비스로는 인사말만
nc 127.0.0.1 2222            # → Hello Beginners!
 
# 이미지 안에 구워진 flag를 chall 사용자로 읽기
docker exec -u chall exdoc cat /home/chall/flag

DH{docker_exercise}

ls -l 로 확인되듯 flag는 -r--r----- root chall 권한이고, id 로 보면 우리가 uid=1000(chall) groups=1000(chall) 이라 그룹 읽기 권한으로 통과한다. 라이브 서버도 같은 Dockerfile로 빌드된 같은 이미지를 돌리므로, 이미지 안의 flag가 곧 답이다.

📝 결론

컨테이너 이미지에 넣은 파일은 "숨긴 것"이 아니다. 이번 문제는 학습용이라 flag를 그대로 받아 빌드만 하면 됐지만, 같은 원리가 실무에서는 사고로 이어진다. 이미지에 한 번 ADD/COPY된 비밀은 레이어에 박제되어, 이미지를 가진 사람이라면 docker save로 레이어 tar를 풀거나 docker history로 빌드 단계를 들춰 그대로 꺼낼 수 있다. 중간에 RUN rm 으로 지워도 앞 레이어엔 남는다.

정리하면,

1. 비밀은 이미지에 굽지 않는다. API 키·인증서·flag 같은 민감 파일은 빌드 타임 ADD/COPY 대신 런타임에 주입한다 — 볼륨 바인드 마운트, 런타임 환경변수, BuildKit --secret 마운트(레이어에 남지 않음), 또는 오케스트레이터의 시크릿 기능.
2. 이미지는 배포물이라고 생각한다. 누군가 이미지를 손에 넣으면 그 안의 모든 레이어를 들여다볼 수 있다는 전제로 무엇을 넣을지 정한다.
3. 챌린지 배포 구조를 읽는 습관. 워게임의 Dockerfile은 "바이너리가 어떤 권한·환경에서 도는지"를 그대로 보여 준다. 로컬에서 같은 이미지를 빌드해 두면 익스플로잇을 서버에 쏘기 전에 동일 환경에서 안전하게 검증할 수 있다 — 이 실습이 가르치려는 진짜 도구다.