[🥉 Bronze 1] "IP인지 검증했다"와 "안전하다"는 다른 말이다 — DreamHack EZ_command_injection 풀이

문제: DreamHack — EZ_command_injection 분류: Web 난이도: 🥉 Bronze 1 FLAG: DH{EZZZZZ_COMm4Nd_1nJecTiON_ZzZZ}

제목부터 "쉬운 명령어 인젝션"이라고 대놓고 말해주는 문제다. 그런데 실제로 서버 코드를 열어보면 ipaddress 표준 라이브러리로 입력을 검증하는 코드가 딱 버티고 있다 — "쉬운" 문제라고 해서 방어 코드까지 허술한 건 아니었다. 이 검증을 그대로 뚫는 게 아니라, 검증이 놓치는 지점을 찾아야 했다.

명령어 인젝션 자체는 이 시리즈에서 여러 번 다룬 익숙한 취약점 유형이지만(;, `, $() 같은 셸 메타문자를 필터링하지 않고 사용자 입력을 그대로 명령줄에 붙이는 패턴), 이 문제는 "필터링을 아예 안 한" 게 아니라 "필터링을 대신할 만큼 신뢰도 높아 보이는 검증을 썼는데도 뚫린다"는 점에서 결이 달랐다. 정규식으로 대충 특수문자를 걸러내는 수준이 아니라, RFC 스펙을 그대로 구현한 표준 라이브러리로 검증했는데도 구멍이 있었다는 게 이 문제의 재미였다.

문제 개요

VM을 띄우면 그냥 "Ping Result"라는 제목의 빈 페이지 하나가 나온다. 별도의 입력 폼도 없다.

폼이 없다는 건 URL을 직접 만들어야 한다는 뜻이다. 문제 파일로 소스가 함께 제공됐다.

핵심은 /ping 라우트다.

host = request.args.get('host', '')
try:
    addr = ipaddress.ip_address(host)
except ValueError:
    ...  # Invalid IP address
 
cmd = f'ping -c 3 {addr}'
output = subprocess.check_output(['/bin/sh', '-c', cmd], timeout=8)

사용자 입력을 그대로 쉘에 넘기는 게 아니라, 일단 파이썬 표준 라이브러리 ipaddress.ip_address()로 "이게 진짜 IP 주소인가"부터 확인한다. 파싱에 실패하면(ValueError) 애초에 명령을 실행하지도 않는다. 이 정도면 흔한 명령어 인젝션 문제보다 방어가 한 단계 더 있는 셈이다 — 직접 문자열을 검사하는 대신, 신뢰할 수 있는 표준 라이브러리에 검증을 위임하는 방식은 실무에서도 자주 권장되는 패턴이다.

▶🕳️ 삽질 — 파라미터 이름부터 잘못 짚어서 한참 헤맸다

문제 파일을 열어보기 전에는 그냥 무작정 URL을 두드려봤다. ?ip=, ?host=, ?target= 같은 흔한 파라미터 이름들로 GET 요청을 날려도 전부 "No result available"만 나왔고, POST로 보내면 아예 405가 떴다. 소스 코드를 열기 전까지는 이게 파라미터 이름이 틀린 건지, 메서드가 틀린 건지, 엔드포인트가 틀린 건지 구분이 안 됐다.

app.py를 열어보고 나서야 세 가지가 한 번에 풀렸다 — 엔드포인트는 /ping(루트 /가 아니라), 메서드는 GET만 허용, 파라미터 이름은 정확히 host. 이 세 개 중 하나라도 틀리면 서버는 그냥 조용히 기본 페이지만 돌려줄 뿐 어떤 힌트도 주지 않는다.

이 화면을 처음 봤을 때가 사실상 진짜 시작점이었다 — "값이 뭐든 일단 이 요청 자체는 서버가 제대로 처리하고 있다"는 걸 확인시켜준 것이다. 여기서부터 ip_address() 검증 로직 자체를 공략하는 단계로 넘어갔다.

💣 핵심 — scope_id는 "유효한 IP"이면서 동시에 "임의의 문자열"이다

ipaddress.ip_address()가 정확히 뭘 어디까지 허용하는지 로컬에서 먼저 확인해봤다.

IPv6 주소는 fe80::1%eth0처럼 % 뒤에 scope id(zone index)를 붙여서 "어느 네트워크 인터페이스를 통한 주소인지"를 표시할 수 있다. 링크로컬 주소를 다룰 때 실제로 쓰이는 정상적인 문법이다. 그런데 파이썬의 ipaddress 모듈은 이 scope id의 내용을 사실상 검증하지 않는다 — 빈 문자열이 아니기만 하면 뭐가 들어있든 그대로 받아들이고, str(addr)로 다시 문자열화할 때도 원본 그대로 돌려준다.

>>> ipaddress.ip_address("::1%$(id)")
IPv6Address('::1%$(id)')
>>> str(ipaddress.ip_address("::1%$(id)"))
'::1%$(id)'

즉 "::1%$(id)"는 파이썬 입장에서 완벽하게 유효한 IPv6 주소이면서, 동시에 셸에서 그대로 실행하면 id 명령을 치환해버리는 완벽한 인젝션 페이로드이기도 하다. 세미콜론(;), 파이프(|), 앰퍼샌드(&), 백틱, 달러 기호, 괄호, 공백까지 — 셸에서 위험하다고 여겨지는 문자 거의 전부가 scope id 안에서는 아무 제약 없이 통과된다. 딱 하나, 슬래시(/)만 예외였다 — IPv6 주소 뒤에 /가 오면 CIDR 서브넷 표기(fe80::/64)로 해석하려다 파싱에 실패한다.

이 가설이 맞는지 가장 간단한 형태로 먼저 확인해봤다. ::1%eth0처럼 셸 특수문자가 전혀 없는, 그냥 "존재하지 않는 인터페이스 이름"만 붙여서 요청을 보냈다.

응답이 "Invalid IP address"가 아니라 "An error occurred while executing the command"로 바뀐 게 핵심 신호였다. 전자는 ipaddress.ip_address() 단계에서 막혔다는 뜻이고, 후자는 그 단계는 통과했지만 실제 ping 실행이 실패했다는 뜻이다. eth0이라는 문자열이 scope id로 받아들여져 파싱까지는 성공했고, 다만 그 값을 인터페이스로 쓴 ping 명령 자체가 (그런 인터페이스가 없거나 컨테이너에 ICMP 권한이 없어서) 실패한 것이다. 이 한 번의 요청으로 "scope id 부분은 정말로 검증되지 않는다"는 가설을 명확하게 확인할 수 있었다.

🎯 자체 완결 solve

이제 남은 건 두 가지 제약을 동시에 만족하는 페이로드를 만드는 것이었다.

1. 절대경로를 쓸 수 없다. /app/flag.txt처럼 슬래시가 들어간 문자열은 그 자체로 IP 파싱을 깨버린다.

문제 파일에 포함된 Dockerfile을 보면 WORKDIR /app으로 앱이 배포된다는 걸 알 수 있었다. 즉 애플리케이션이 실행되는 현재 디렉터리가 이미 /app이라, 절대경로 없이 flag.txt라는 상대경로만 써도 충분했다.

2. ping이 실패해도 결과가 화면에 나와야 한다. subprocess.check_output()은 실행한 명령의 최종 종료 코드가 0이 아니면 CalledProcessError를 던지고, 그 경우 코드는 실제 출력 대신 "An error occurred while executing the command"라는 고정 메시지만 보여준다. 우리가 주입한 ping -c 3 ::1%<페이로드>의 ping 부분은 애초에 정상적으로 끝날 수 없는 주소라서 실패할 게 뻔했다 — 그래서 세미콜론으로 명령을 이어붙이고 맨 끝에 true를 붙여서, ping이 뭐라고 하든 최종 종료 코드만큼은 0으로 강제했다.

최종 페이로드:

host=::1%x;cat flag.txt;true

여기서 scope id 부분(x;cat flag.txt;true)을 다시 뜯어보면, x는 그냥 자리를 채우는 더미 인터페이스 이름이고(scope id가 완전히 비어있으면 파싱이 실패하므로 뭐라도 있어야 한다), 진짜 하려는 일은 그 뒤 세미콜론부터 시작된다. 서버가 최종적으로 /bin/sh -c에 넘기는 명령은 결국 ping -c 3 ::1%x;cat flag.txt;true가 되고, 셸은 이걸 세미콜론 기준으로 세 개의 독립된 명령으로 쪼개 순서대로 실행한다 — ping -c 3 ::1%x(실패해도 무시됨), cat flag.txt(진짜 목적, 표준출력으로 flag를 찍음), true(항상 성공, 셸 전체의 마지막 종료 코드를 0으로 확정). subprocess.check_output()이 확인하는 건 오직 이 마지막 명령의 종료 코드뿐이라, 앞선 두 명령이 뭘 했든 신경 쓰지 않는다.

이걸 브라우저 주소창에 직접 넣어 확인했다.

이 flag를 드림핵에 제출해 정답으로 확정됐고 VM 크레딧도 바로 환급됐다.

📝 결론

이 문제가 잘 짚어준 지점은 "신뢰할 수 있는 라이브러리로 검증했다"는 것과 "그 검증 결과가 안전하다"는 것이 항상 같지 않다는 사실이었다.

• 검증 함수의 "성공 조건"이 정확히 뭘 의미하는지 확인해야 한다. ipaddress.ip_address()가 성공한다는 건 "RFC 문법상 유효한 IP 주소 표현이다"라는 뜻이지, "이 문자열에 위험한 문자가 없다"는 뜻이 아니다. IPv6의 scope id처럼 프로토콜 스펙 자체가 "임의의 문자열을 허용하는 자유 필드"를 갖고 있다면, 그 필드를 통과한 값이라도 후속 처리(이번엔 쉘 명령 조립)에서는 여전히 위험할 수 있다.
• 입력 검증과 출력 사용 사이의 "거리"를 좁게 봐야 한다. 이 코드는 ip_address()로 검증한 값을 검증 그 자체(addr 객체)가 아니라 문자열로 다시 변환해서(f'{addr}') 사용한다. 검증에 통과한 객체를 다시 문자열화하는 순간, "이 객체가 뭘 보장하는가"와 "이 문자열이 뭘 담고 있는가"가 미묘하게 어긋날 수 있다는 걸 이 문제가 잘 보여준다.
• 명령 실행 결과를 예외 처리로 숨기는 코드는 공격자에게도 힌트가 된다. CalledProcessError를 잡아서 일반 에러 메시지로 뭉뚱그리는 방어적 코드였지만, 거꾸로 "종료 코드를 0으로 맞추기만 하면 출력이 그대로 노출된다"는 조건을 명확하게 알려준 셈이었다.

이번 풀이에서 실제로 값을 잃은 문자는 슬래시 하나뿐이었지만, 다른 웹 서버 환경이었다면 이야기가 조금 달라졌을 수도 있다. 예를 들어 플래그 경로가 앱의 작업 디렉터리 바깥에 있었다면 ..(상위 디렉터리 이동)을 여러 번 겹쳐 써서 슬래시 없이도 상대경로로 접근하는 우회가 필요했을 것이고, 애초에 WORKDIR가 어디인지 알 수 없는 블랙박스 환경이었다면 find . -name flag* 처럼 슬래시 없는 탐색 명령으로 먼저 위치부터 찾아야 했을 것이다. 이번엔 Dockerfile이 제공돼 있어서 그 탐색 과정을 건너뛸 수 있었다.

방어자 관점에서 보면, 이 문제의 진짜 교훈은 "외부 라이브러리로 형식을 검증하는 것"과 "셸에 안전하게 값을 전달하는 것"은 서로 다른 책임이라는 원칙이다. 애초에 ping 같은 외부 명령을 실행해야 한다면, 문자열을 조립해 셸에 넘기는 대신 subprocess.run(['ping', '-c', '3', str(addr)])처럼 인자를 리스트로 분리해서 넘기고 shell=True(또는 /bin/sh -c)를 아예 쓰지 않는 것이 훨씬 근본적인 해결책이다. 인자가 리스트로 분리되면 addr 문자열 안에 어떤 특수문자가 들어있든 셸이 그걸 다시 해석할 기회 자체가 사라진다 — 입력을 아무리 정교하게 검증해도 결국 셸 문자열 조립이라는 위험한 지점을 거친다면, 그 검증은 언제든 이번 문제처럼 우회당할 여지를 남긴다.