Path Traversal hay còn được biết với một số tên khác như “dot-dot-slash”, “directory traversal”,”directory clumbing” và “backtracking” là hình thức tấn công truy cập đến những file và thư mục mà được lưu bên ngoài thư mục webroot. Hình thức tấn công này không cần sử dụng một công cụ nào mà chỉ đơn thuần thao tác các biến với ../ (dot-dot-slash) để truy cập đến file, thư mục, bao gồm cả source code, những file hệ thống, …
Để nhận biết khả năng khai thác lỗi này, các kẻ tấn công thường quan sát kết quả có được từ spider hoặc crawler mang lại. Quan sát khả năng khai thác Path Traversal ở đây là gì ?
Ví dụ kết quả trả về từ Spider hay Crawler có dạng sau:
Code:
http://seamoun.com/getUserProfile.jsp?page=main.html
http://seamoun.com/index.php?file=help
http://seamoun.com/main.cgi?home=index.htm
Ngoài ra các bạn còn thấy nhiều dạng url khác mà có “mùi” Path Traversal, các bạn tự hỏi làm sao biết được ? Trả lời: thông qua kinh nghiệm khi phân tích url mà có được.
II. KHAI THÁC
Khi có được kết quả từ việc spider Website với các url có dạng như trên, kẻ tấn công có thể sử dụng “../” để thử liệu có truy cập file và thư mục khác được không ? Ví dụ
Code:
http://seamoun.com/getUserProfile.jsp?page=../../../etc/passwd
Dựa vào thông báo lỗi từ Website kẻ tấn công biết được đường dẫn thực sự trên WebServer, từ đó có thể kết hợp với ../ (dot-dot-slash) để truy cập đến những file quan trong của Website như database, file cấu hình, …
Lưu ý rằng Path Traversal không chỉ xảy ra đối với các biến trong phương thức GET mà còn có thể xuất hiện trong các phương thức POST hoặc biến COOKIE.
Ví dụ: Một số website có thể sử dụng COOKIE để lưu template động cho Website như sau:
Cookie: ID= 2ddd73ef3620afc62cd6942c31bb6003:TEMPLATE=xpstyle
Cookie: USER=member1234: PSTYLE=Green
Như vậy kẻ tấn công có thể thay đổi COOKIE để thực hiện Path Traversal Attack như sau
Cookie: ID= 2ddd73ef3620afc62cd6942c31bb6003:TEMPLATE=xpstyle
Cookie: USER=member1234: PSTYLE=../../etc/passwd
Trong quá trình khai thác kẻ tấn công có thể encode hoặc double encode, sử dụng (null) để bypass filter mà Website đó áp dụng.
Ví dụ:
%2e%2e%2f mô tả cho ../
%2e%2e/ mô tả cho ../
..%2f mô tả cho ../
%2e%2e%5c mô tả cho ..\
%2e%2e\ mô tả cho ..\
..%5c mô tả cho ..\
%252e%252e%255c mô tả cho ..\
..%255c mô tả cho ..\
…
Đối với UTF-8
..%c0%af mô tả cho ../
..%c1%9c mô tả cho ..\
Khi tiếp cận với một ứng dụng Web, việc kiểm tra nó có khả năng bị lỗi Path Traversal có thể được thực hiện bằng hai loại:
+ Nếu kẻ tấn công không thể có source thì chúng sẽ dùng spider, crawler để thực hiện kiểm tra Website và từ những kết quả mà spider mang lại chúng sẽ lần lượt kiểm tra các biến đối với các phương thức GET, POST hoặc COOKIE mà có khả năng bị lỗi.
+ Nếu kẻ tấn công có source code thì có thể tìm kiếm những hàm của những ngôn ngữ lập trình Web mà có khả năng gây ra lỗi Path Traversal như sau:
Code:
PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ...
JSP/Servlet: java.io.File(), java.io.FileReader(), ...
ASP: include file, include virtual, ...
Demo khai thác Path Traversal (X7 Chat). Trong đoạn demo sau đây giả sử kẻ tấn công không biết source code của ứng dụng Web X7 Chat và thực hiện spider để kiểm tra nội dung Website.
(Download file demo bên dưới, chỉ có login mới thấy file download)
III. PHÒNG CHỐNG
Việc phòng chống Path Traversal Attack phải thực hiện kiểm tra biến cẩn thận (có thể áp dụng filter) khi sử dụng các hàm đã giới thiệu ở trên mà có khả năng gây ra lỗi cho phép kẻ tấn công thực hiện Path Traversal. Tuy nhiên một số filter như
Code:
str_replace("../","",$_GET['help_file']) thì vẫn bị lỗi bởi lẽ kẻ tấn công có thể sử dụng “….//” như thế sau khi qua code lọc ở trên nó sẽ trở thành “../”. Rõ ràng việc lọc như vậy vẫn không triệt để. Thay vào đó các bạn nên sử dụng các biểu thức chính để lọc tốt hơn.
Ví dụ
Code:
eregi("[\\/]","{$_GET['help_file']}") Công cụ sử dụng Website Crawler: Acunetix
Link: http://www.hvaonline.net/hvaonline/posts/list/25352.hva