I. Đặt vấn đề
1. Giới thiệu
Server-side request forgery (thường được gọi là SSRF) là một dạng tấn công trong đó kẻ tấn công lợi dụng một tính năng của server public nhằm truy xuất trái phép dữ liệu từ một trang web chỉ định khác, thường là các trang web back-end ở chính server đó. Để các bạn có thể hình dung rõ hơn về dạng lỗ hổng này, chúng ta cùng xét ví dụ sau:
Trong hình trên, kẻ tấn công trao đổi gói tin với server public, lợi dụng máy chủ này gửi yêu cầu tới server back-end (mạng nội bộ). Lúc này server back-end phân tích và tin tưởng yêu cầu này do nó được gửi từ public server, sau đó trả về response tới public server, và public server tiếp tục trả về dữ liệu tới kẻ tấn công. Quá trình tấn công hoàn thành, cách thức hoạt động giống hệt với chiêu "mượn đao giết người"! Đây cũng chính là lý do dạng tấn công này được gọi là "giả mạo yêu cầu phía máy chủ" - kẻ tấn công mạo danh thành máy chủ để truy xuất dữ liệu nhạy cảm một cách "hợp pháp"!
2. Tầm ảnh hưởng
Kẻ tấn công thường lợi dụng kiểu tấn công này giả mạo yêu cầu truy cập tới các trang web vốn cần quyền hạn cao hoặc không nằm trong phạm vi truy cập của người dùng thường, đó có thể là các trang dành cho quản trị viên, các end point chỉ có thể truy cập từ local hoặc chứa dữ liệu nhạy cảm. Từ đó thu thập trái phép dữ liệu hoặc thực hiện các hành vi phá hoại, trong một số trường hợp có thể leo thang từ tấn công SSRF lên tấn công Command Injection. Lỗ hổng Server-side request forgery được xếp ở vị trí số 1010 trong thông kê Top 1010 lỗ hổng bảo mật web của OWASP vào năm 20212021 (A10:2021-Server Side Request Forgery (SSRF))
II. Phân tích và khai thác các lỗ hổng Server-side request forgery
1. Lỗ hổng SSRF trong một số ngôn ngữ
1.1. Ngôn ngữ PHP
Lỗ hổng SSRF có thể xuất hiện trong ngôn ngữ lập trình PHP khi các nhà phát triển sử dụng chưa tốt một số hàm làm việc với URL. Ví dụ xét đoạn code sử dụng hàm file_get_contents() sau:
View attachment 2371
Đoạn code trên in ra nội dung trang web thông qua tham số url được truyền bởi người dùng bằng hàm file_get_contents(). Ví dụ với url=https://google.com:
Do trang web không có bất kỳ phương án ngăn chặn tấn công SSRF, nên kẻ tấn công có thể dễ dàng truy xuất nội dung tệp /etc/passwd:
Hoặc đọc nội dung tại một port đang mở khác của server - vốn dĩ chỉ có thể truy cập thông qua mạng local:
Ngoài ra các hàm khác như fscokopen(), curl_exec(), ... nếu cài đặt thiếu cẩn thận cũng có nguy cơ gây ra lỗ hổng SSRF, các bạn có thể tìm hiểu thêm qua các tài liệu trên Google.
1.2. Ngôn ngữ Python
Xét đoạn code Python sử dụng thư viện Slack sau:
View attachment 2372
Do không thực hiện ngăn chặn lỗ hổng SSRF đối với tham số url được truyền bởi người dùng nên trang web có thể bị tấn công SSRF như sau:
2. Lỗ hổng SSRF truy cập local server
Kẻ tấn công thường tận dụng lỗ hổng SSRF để truy cập các trang web vốn dành cho tài khoản có quyền quản trị viên hoặc chỉ có thể truy cập từ phía local server. Từ đó có thể sử dụng các chức năng của các trang web này. Local server thường được xác định với địa chỉ URL dạng:
http://127.0.0.1
hoặc
http://localhost
. Xét bài lab sau:
Phân tích lab Basic SSRF against the local server
Miêu tả: Chức năng stock check của trang web lấy dữ liệu từ trang mạng nội bộ trả về cho người dùng. Tại đây chứa lỗ hổng SSRF. Để giải quyết bài lab, chúng ta cần khai thác lỗ hổng SSRF truy cập vào trang quản trị viên có địa chỉ
http://localhost/admin
và thực hiện xóa tài khoản người dùng carlos.
Trang web chứa chức năng kiểm tra số lượng hàng còn lại trong kho:
Quan sát request và response trong Burp Suite khi sử dụng chức năng này:
Tham số stockApi truyền bằng phương thức POST cho hệ thống giá trị là một địa chỉ URL
http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1
. Địa chỉ này chỉ có thể truy cập từ mạng local.
Do hệ thống nhận giá trị stockApi là một địa chỉ URL nên chúng ta có thể dự đoạn tại đây có thể chứa lỗ hổng SSRF. Thực hiện kiểm tra: Sử dụng Burp Collaborator, thay giá trị stockApi bằng domain mới được sinh ra:
Gửi request, kết quả tại client collaborator nhận được request tương tác - DNS lookup thành công:
Chứng tỏ chức năng stock check có thể tương tác với bất kỳ URL nào, khả năng lớn chứa lỗ hổng SSRF. Bởi vậy, chúng ta có thể khai thác lỗ hổng truy cập trang quản trị bằng một số cách như sau:
Cuối cùng, thực hiện xóa tài khoản người dùng carlos bằng cách truy cập tới đường dẫn /admin/delete?username=carlos
Payload: stockApi=http://127.0.0.1/admin/delete?username=carlos
Bài lab hoàn thành:
Khi có nhu cầu về các sản phẩm bên trên, đừng ngần ngại gọi ngay cho: 09.7777.1060
Hoặc Zalo 09.7777.1060 để được sự hỗ trợ và tư vấn sớm nhất
CÔNG TY TNHH TƯ VẤN TRUYỀN THÔNG MINARA
ĐỊA CHỈ:
- 182 Trần Bình Trọng, P.3, Q.5, Tp.HCM
- 27 Đường số 16, Trung Tâm Hành Chính Dĩ An, Bình Dương.
Điện thoại: 097.777.1060
Email: info@minara.vn
Website: www.minara.vn
1. Giới thiệu
Server-side request forgery (thường được gọi là SSRF) là một dạng tấn công trong đó kẻ tấn công lợi dụng một tính năng của server public nhằm truy xuất trái phép dữ liệu từ một trang web chỉ định khác, thường là các trang web back-end ở chính server đó. Để các bạn có thể hình dung rõ hơn về dạng lỗ hổng này, chúng ta cùng xét ví dụ sau:
Trong hình trên, kẻ tấn công trao đổi gói tin với server public, lợi dụng máy chủ này gửi yêu cầu tới server back-end (mạng nội bộ). Lúc này server back-end phân tích và tin tưởng yêu cầu này do nó được gửi từ public server, sau đó trả về response tới public server, và public server tiếp tục trả về dữ liệu tới kẻ tấn công. Quá trình tấn công hoàn thành, cách thức hoạt động giống hệt với chiêu "mượn đao giết người"! Đây cũng chính là lý do dạng tấn công này được gọi là "giả mạo yêu cầu phía máy chủ" - kẻ tấn công mạo danh thành máy chủ để truy xuất dữ liệu nhạy cảm một cách "hợp pháp"!
2. Tầm ảnh hưởng
Kẻ tấn công thường lợi dụng kiểu tấn công này giả mạo yêu cầu truy cập tới các trang web vốn cần quyền hạn cao hoặc không nằm trong phạm vi truy cập của người dùng thường, đó có thể là các trang dành cho quản trị viên, các end point chỉ có thể truy cập từ local hoặc chứa dữ liệu nhạy cảm. Từ đó thu thập trái phép dữ liệu hoặc thực hiện các hành vi phá hoại, trong một số trường hợp có thể leo thang từ tấn công SSRF lên tấn công Command Injection. Lỗ hổng Server-side request forgery được xếp ở vị trí số 1010 trong thông kê Top 1010 lỗ hổng bảo mật web của OWASP vào năm 20212021 (A10:2021-Server Side Request Forgery (SSRF))
II. Phân tích và khai thác các lỗ hổng Server-side request forgery
1. Lỗ hổng SSRF trong một số ngôn ngữ
1.1. Ngôn ngữ PHP
Lỗ hổng SSRF có thể xuất hiện trong ngôn ngữ lập trình PHP khi các nhà phát triển sử dụng chưa tốt một số hàm làm việc với URL. Ví dụ xét đoạn code sử dụng hàm file_get_contents() sau:
View attachment 2371
Đoạn code trên in ra nội dung trang web thông qua tham số url được truyền bởi người dùng bằng hàm file_get_contents(). Ví dụ với url=https://google.com:
Do trang web không có bất kỳ phương án ngăn chặn tấn công SSRF, nên kẻ tấn công có thể dễ dàng truy xuất nội dung tệp /etc/passwd:
Hoặc đọc nội dung tại một port đang mở khác của server - vốn dĩ chỉ có thể truy cập thông qua mạng local:
Ngoài ra các hàm khác như fscokopen(), curl_exec(), ... nếu cài đặt thiếu cẩn thận cũng có nguy cơ gây ra lỗ hổng SSRF, các bạn có thể tìm hiểu thêm qua các tài liệu trên Google.
1.2. Ngôn ngữ Python
Xét đoạn code Python sử dụng thư viện Slack sau:
View attachment 2372
Do không thực hiện ngăn chặn lỗ hổng SSRF đối với tham số url được truyền bởi người dùng nên trang web có thể bị tấn công SSRF như sau:
2. Lỗ hổng SSRF truy cập local server
Kẻ tấn công thường tận dụng lỗ hổng SSRF để truy cập các trang web vốn dành cho tài khoản có quyền quản trị viên hoặc chỉ có thể truy cập từ phía local server. Từ đó có thể sử dụng các chức năng của các trang web này. Local server thường được xác định với địa chỉ URL dạng:
http://127.0.0.1
hoặc
http://localhost
. Xét bài lab sau:
Phân tích lab Basic SSRF against the local server
Miêu tả: Chức năng stock check của trang web lấy dữ liệu từ trang mạng nội bộ trả về cho người dùng. Tại đây chứa lỗ hổng SSRF. Để giải quyết bài lab, chúng ta cần khai thác lỗ hổng SSRF truy cập vào trang quản trị viên có địa chỉ
http://localhost/admin
và thực hiện xóa tài khoản người dùng carlos.
Trang web chứa chức năng kiểm tra số lượng hàng còn lại trong kho:
Quan sát request và response trong Burp Suite khi sử dụng chức năng này:
Tham số stockApi truyền bằng phương thức POST cho hệ thống giá trị là một địa chỉ URL
http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1
. Địa chỉ này chỉ có thể truy cập từ mạng local.
Do hệ thống nhận giá trị stockApi là một địa chỉ URL nên chúng ta có thể dự đoạn tại đây có thể chứa lỗ hổng SSRF. Thực hiện kiểm tra: Sử dụng Burp Collaborator, thay giá trị stockApi bằng domain mới được sinh ra:
Gửi request, kết quả tại client collaborator nhận được request tương tác - DNS lookup thành công:
Chứng tỏ chức năng stock check có thể tương tác với bất kỳ URL nào, khả năng lớn chứa lỗ hổng SSRF. Bởi vậy, chúng ta có thể khai thác lỗ hổng truy cập trang quản trị bằng một số cách như sau:
- Payload 11: stockApi=http://localhost/admin
- Payload 22: stockApi=http://127.0.0.1/admin
Cuối cùng, thực hiện xóa tài khoản người dùng carlos bằng cách truy cập tới đường dẫn /admin/delete?username=carlos
Payload: stockApi=http://127.0.0.1/admin/delete?username=carlos
Bài lab hoàn thành:
Khi có nhu cầu về các sản phẩm bên trên, đừng ngần ngại gọi ngay cho: 09.7777.1060
Hoặc Zalo 09.7777.1060 để được sự hỗ trợ và tư vấn sớm nhất
CÔNG TY TNHH TƯ VẤN TRUYỀN THÔNG MINARA
ĐỊA CHỈ:
- 182 Trần Bình Trọng, P.3, Q.5, Tp.HCM
- 27 Đường số 16, Trung Tâm Hành Chính Dĩ An, Bình Dương.
Điện thoại: 097.777.1060
Email: info@minara.vn
Website: www.minara.vn