File Inclusion
Local File Incluision (LFI), Remote File Inclusion (RFI), Directory Traversal 등 다양한 File Inclusion (이하 FI) 취약점과 취약점 발견 시 위험과 해결 방안에 대해서 알아보자.
일부 시나리오에서 웹 애플리케이션은 파라미터를 통해서 이미지, 텍스트 등 특정 시스템의 파일에 접근 요청을 하도록 작성된다.
파라미터는 URL에 첨부된 쿼리 파라미터 문자열로 입력에 따라서 다양한 작업을 수행한다.
위 이미지의 url에서 file은 파라미터이고, userCV.pdf는 접근할 파일이다.
구글을 예를 들어서 https://google.com/search?q=TryHackMe 라는 GET 요청을 보내면 TryHackMe라는 값을 파라미터 query라는 의미의 q에 담아서 요청을 보낸다.
왜 존재하느냐
FI 취약점은 PHP처럼 작성 및 구현이 형편없는(poorly) 프로그래밍 언어에서 발견될 수 있다.
그 이유는 Input Validation 때문인데, 입력값이 제대로 검증되지 않고 사용자가 직접 제어할 수 있기 때문이다.
제대로 검증되지 않으면 사용자가 함수에 입력값을 전달할 수 있고, 그로인해 취약점이 발생한다.
기본적으로 공격자는 FI 취약점을 코드, 비밀번호, 혹은 다른 중요한 파일과 같은 취약한 데이터를 다룰 수 있다.
더군다나 공격자가 서버에 파일을 쓸 수 있다면 FI 취약점을 이용해서 Remote Command Execution (RCE)를 획득할 수 있다.
Path Traversal
경로탐색, Directory Traversal이라고도 하는 취약점은 공격자가 어플리케이션을 실행하는 서버의 로컬 파일같은 리소스를 읽을 수 있도록 한다.
공격자는 웹 애플리케이션의 URL을 조작할 수 있고, 루드 디렉터리 외부에 저장된 파일이나 디렉터리에 접근한다.
이 취약점은 사용자 입력이 PHP의 file_get_contents같은 함수에 전달될 때 발생한다.
함수 자체가 문제는 아니고, 입력값 검증이 제대로 되지 않거나 필터링이 미흡할 때 발생한다.
/var/www/app의 경로에 파일을 저장한 다이어그램이다. /var/www/app/CVs의 userCV.pdf를 요청하는 것이 최적의 경로이다.
해당 웹 애플리케이션의 동작을 확인하기 위해서 URL 파라미터를 테스트할 수 있다.
../을 사용하면 디렉터리를 한 단계 위로 이동할 수 있는데 위 다이어그램에서 공격자가 get.php?file=이라는 엔트리 포인트를 찾으면 http://webapp.thm/get.php?file=../../../../etc/passwd을 요청할 수 있다.
입력값 검증이 없고 /var/www/app가 아니라 /etc/passwd에서 파일을 가져온다고 가정하면,
공격자가 요청한 각 ..항목에서는 root에 도달할 때까지 디렉터리를 하나씩 이동하고 root에서 /etc로 이동해서 passwd파일을 읽을 수 있다.
이 과정으로 웹 애플리케이션은 유저에게 파일을 보여준다.
윈도우 공격자도 웹 애플리케이션 공격자와 마찬가지로 root 디렉터리 (.)로 이동할 때까지 올라가서 특정 파일이나 디렉터리로 접근해야한다.
그래서 개발자는 특정 파일이나 디렉터리에만 접근하도록 필터를 걸 수 있다.
