3. File path traversal,traversal sequences stripped non-recursively

이번에는 절대경로가 통하지 않고, 상대경로 ../를 replace와 같은 방식으로 거를 때 우회하는 방법이다(while문으로 모든 ../를 거르지 않을 때). 

 

../를 거르기 때문에 사용자가 ../../../../etc/passwd라는 값을 입력하게 되면 etc/passwd라는 값만 전하게 되어, /var/www/html/etc/passwd라는 파일을 OS가 찾으려는 시도를 하게 될 것이다.

그러니, ....//와 같이 해놓는 식으로 우회하는 거다. 이렇게 하면 ../가 걸러져서 결국에는 ../가 남게 된다.

....// => ../ (굵은 표시 한 게 사라진 결과 상대 경로만 남음.)

 

이를 해결하기 위해서는 while문으로 끝까지 전부 처리해줘야 한다. 근데 이거 말고도 다른 방어 방법은 있으니까 그건 맨 마지막 장에서 다룰거다.

 

이제 문제를 보자.

그림 1. 취약점이 있는 사이트

그림 1과 같이 웹사이트가 있다.

보기에는 별 문제가 없어보인다.

그러니 페이지 소스를 보도록 하자

 

그림 2. 그림 1의 페이지 소스

그림 1의 페이지 소스가 그림 2이다.

보면 img태그를 통해 image라는 프로그램이 실행되었고, filename이라는 변수에 42.jpg를 전달하고 있는게 확인이 된다.

filename에 전하는 값을 바꾸기 위해 일단 image라는 프로그램을 실행시켜보자.

그림 3. 이미지

그림 3은 image라는 프로그램을 실행시켜서 42.jpg라는 이미지를 서버로부터 받아온 결과이다.

filename에 다른 값을 넣어보도록 하자.

 

그림 4. 상대경로 테스트

서버가 어떤 식으로 취약한 지 알려주진 않았으니(사실 그 전에 공부할 때, ../를 거르고 그걸 우회할 거라고 알려주긴 했는데 문제에는 무슨 취약점이 존재한다고 알려주진 않았으니까 한 번만 해보도록 하자) 상대 경로를 입력해서 path traversal을 발생시켜보도록 하자.

그랬더니 그림 4와 같이 No such file이 떴다.

아무래도 /var/www/file/etc/passwd와 같은 느낌으로 적혔나보다. 

 

그림 5. 절대경로 테스트

이번에는 절대경로를 적어보자.

그림 4와 다를 바 없이 이번에도 그림 5처럼 No such file이라는 답변이 돌아왔다.

보아하니 슬래시를 여러 개 써도 거르는 모양이다.

절대경로도 안 된다. 탈락

그림 6. /etc/passwd파일 받기

이제 학습한대로 ....//를 넣어보자.

페이로드는 filename = ....//....//....//....//etc/passwd이다.

결과는... 따단! 그림 6과 같이 무언가 불러와졌다.

아무래도 정답이겠지만 확인해보도록 하자.

그림 7. 웹서버의 Response

그림 7과 같이 서버의 응답을 봤더니 /etc/passwd가 맞다.

 

끝