[🥉 Bronze 3] 확장자 블랙리스트가 빠뜨린 파일명 — DreamHack Apache htaccess 풀이

파일명에서 마지막 . 뒤 문자열을 뽑아 블랙리스트와 비교한다. 흔한 PHP 확장자는 다 막아 놨다. 직접 .php 웹쉘을 올려보면 바로 막힌다.

그런데 Apache 설정을 보면 이 필터와 별개로 중요한 한 줄이 있다.

AllowOverride All은 각 디렉토리에 놓인 .htaccess 파일의 지시어를 그대로 적용하겠다는 뜻이다. 업로드 디렉토리도 예외가 아니다 — 업로드된 파일이 담긴 그 디렉토리 자체의 동작을, 업로드된 파일로 바꿀 수 있다는 뜻이다.

💣 핵심 — .htaccess는 확장자가 없다

파일명 ".htaccess"에 explode(".", ...)을 적용하면 어떻게 될까.

"htaccess"는 블랙리스트(php, php3, ...)에 없다. 그래서 .htaccess라는 이름의 파일은 이 검사를 그냥 통과해 upload/.htaccess로 저장된다. 그리고 AllowOverride All 덕분에, Apache는 upload/ 디렉토리 요청을 처리할 때마다 이 파일을 실제 설정으로 읽어 들인다.

여기에 이 한 줄을 넣으면:

그 순간부터 upload/ 안의 모든 .jpg 파일은 PHP로 실행된다. .jpg는 당연히 블랙리스트에 없으니, PHP 코드가 든 shell.jpg를 올리는 것도 아무 제지 없이 통과한다. 필터는 "확장자로 위험한 파일을 막는다"는 가정 위에 서 있었는데, 그 확장자 자체를 재정의하는 파일은 막을 대상으로 생각하지 못했다.

🎯 익스플로잇

1. .htaccess 업로드로 .jpg를 PHP로 만들기

2. PHP 웹쉘을 .jpg로 위장해 업로드

3. 실행 전용 flag 바이너리를 웹쉘로 실행

Dockerfile을 보면 flag는 chmod 111(실행 전용)로 컴파일된 바이너리다. 읽을 게 아니라 실행해서 출력을 받아야 한다.

🚀 Full Exploit

세 단계를 하나로 묶으면 이렇다.

📝 결론

이 문제의 교훈은 명확하다. 파일 업로드 화이트리스트/블랙리스트는 "그 파일이 콘텐츠로만 존재할 때"를 가정한다. 하지만 업로드 디렉토리에 애플리케이션 실행 규칙 자체를 바꿀 수 있는 파일(.htaccess, web.config 등)을 올릴 수 있다면, 그 가정은 통째로 무너진다 — 확장자가 아무리 안전해 보여도, 서버 설정이 그 의미를 바꿔버릴 수 있기 때문이다.

방어는 세 겹으로 해야 한다. 업로드 파일 확장자는 블랙리스트가 아니라 화이트리스트로 검사하고, .htaccess처럼 확장자 없이 시작하는 점 파일(dotfile) 업로드 자체를 별도로 차단하며, 무엇보다 업로드 디렉토리에는 AllowOverride None을 적용해 애초에 사용자가 웹서버 설정을 바꿀 수 없게 만들어야 한다. 업로드된 파일은 실행 권한이 없는 별도 스토리지(혹은 스크립트 실행이 꺼진 디렉토리)에 두는 게 가장 근본적인 대책이다.