2. File path traversal,traversal sequences blocked with absolute path bypass

이번에는 개발자가 상대경로를 블랙리스트로 막아놨을 때, 우회하는 방법에 관한 내용이다.

첫 번째 우회방법으로 절대경로를 이용한다.

 

이게 가능한 이유는 개발자가 유저에게 입력받은 경로랑, 자기가 적은 베이스 경로를 그냥 합치려고 할 때 생기는 성질때문이다.

원리는 다음과 같다.

/var/www/html/file과 같은 디렉터리 뒤에 파일 이름을 사용자로부터 받는다고 가정해보자. 이 때, 사용자가 "///etc/passwd"와 같은 입력을 하면 특정 코드로 인해 /var/www/html/file와 ///etc/passwd를 합치려고 한다. 여기서 뒤의 값이 ///로 되어있기 때문에 합쳐주는 함수가 앞의 값인 /var/www/html/file을 다 버리고 /etc/passwd만 남긴다.(슬래시가 2개 이상 겹치는 순간부터 리눅스는 여러 개의 슬래시를 하나의 슬래시로 인식한다.)

 

참고로 이러한 성질이 발생하는 함수는 다음과 같다.(더 있을 수도 있다.)

파이썬의 os.path.join("/var/www/html","///etc/passwd")  => /etc/passwd
자바의 spring프레임워크 new File("/var/www/html","//etc/passwd") => /etc/passwd

Node.js의 path.resolve("/var/www/html","/etc/passwd") => /etc/passwd

 

문제를 보자.

힌트로는 이미지에 힌트가 있다고 한다.

그리고, 상대 경로가 막혀있다고 한다. 상대 경로는 쓸 수 없다.

그림 1. 취약점이 존재하는 사이트

 

그림 1과 같은 사이트의 이미지에 취약점이 존재한다고 하니 코드를 보도록 하자.

그림 2. 그림1의 코드

코드를 보니 <img src="image?filename=36.jpg">라고 적혀있다.

image라는 프로그램에서 filename이라는 변수를 받는데, 여기서는 36.jpg라는 값을 보냈고 그 이미지를 받은 게 그림 1의 위험 표지판?처럼 보인다.

그림 3. 이미지 태그 클릭 결과

그림 2의 이미지 태그를 클릭해서 image프로그램을 실행한 결과를 받아보았다.

생각한대로 위험 표지판이 맞다.

그러면 이제 filename의 부분을 바꿔보자.

그림 4. 절대경로로 바꿔버리기

그림 4와 같이 filename에 ///etc/passwd를 넣었다.

원리대로라면 무언가 값이 돌아와야 하고, 그림 4와 같이 깨진 그림이지만 무언가가 돌아왔다.(그야 돌아온 파일이 이미지 형식이 아니면 깨질수밖에...)

그러면 내가 받은 무언가가 /etc/passwd가 맞는지 웹서버가 준 Response값을 보도록 하자.

그림 5. Response

그림 5를 보아하니 웹서버가 돌려준 Response가 /etc/passwd가 맞다.

 

끝!