Server-side request forgery (SSRF)
Last updated
Last updated
Là lỗ hổng bảo mật web cho phép kẻ tấn cống làm máy chủ ứng dụng thực hiện request đến một vị trí không mong muôn (dịch vụ chỉ danh cho nội bộ tổ chức/hệ thống bên ngoài tùy ý) nhằm rò rỉ dữ liệu nhạy cảm chẳng hạn như authorization credential.
Hành động trái phép hoặc truy cập dữ liệu nội bộ (do lỗ hổng trong ứng hoặc trong các back-end system mà ứng dụng có thể giao tiếp với)
Thực thi lệnh tùy ý RCE
Gấy ra kết nối đến hệ thống của bên thứ ba bên ngoài có thể dẫn đến các cuộc tấn công ác ý tiếp theo (thường bắt nguồn từ việc tổ chức lưu trữ ứng dụng dễ bị tấn công)
SSRF thường khai thác trust relationship liên quqn đến máy chủ hoặc các hệ thông back-end khác trong cùng một tổ chưc
Khiến ứng dụng thực hiện HTTP request trở lại máy chủ hosting ứng dụng, thông qua (thường liên quan đến việc cung cấp một URL với hostname như hoặc ).
Ví du: Khi người dùng stock status một item, trình duyệt sẽ thực hiện request sau:
Kẻ tấn công có thể điều chỉnh request để chỉ định URL local máy chủ
Máy chủ sẽ lấy nội dụng /admin và trả về cho người dùng.
Nếu yêu cầu đến URL /adminđến từ máylocal, access control thông thường sẽ bị bỏ qua. Ứng dụng cấp quyền truy cập đầy đủ vào chức năng quản trị, vì yêu cầu có vẻ như bắt nguồn từ một vị trí đáng tin cậy.
NOTE: Lý do các ứng dụng hoạt động theo cách này và ngầm tin tưởng các yêu cầu đến từ máy cục bộ:
Có thể kiểm soát truy cập chỉ được triển khai trong một thành phần nằm trước ứng dụng.
Với mục đích phục hồi sau thảm họa, ứng dụng có thể cho pháp truy cập quản trị mà không cần đăng nhập với bất kỳ user từ máy cục bộ
Giao diện quản trị có thể lắng nghe trên một số cổng khác với ứng dụng chính và người dùng có thể không thể truy cập trục tiếp
Giải pháp:
Intercept khi request chức năng xem stock status
Request này gọi trực tiệp đến máy chủ thông qua URL. Sửa stockApi
Đây là request khi xóa tài khoản carlos
Lặp lại request check stock status và sửa stockApi như sau
Gửi và nhận kết quả
Trong một số trường hợp, application server có thể tương tác với các back-end sysem mà không thể truy cập trực tiếp bởi người dùng. Các hệ thống này thường có địa chỉ IP private không thể định tuyến, bảo vệ bởi network topology nên thường có bảo mật yếu hơn. Đôi khi chúng còn chưa thông tin nhạy cảm mà có thể truy cập không cần xác thực bởi bất kỳ ai mà có thể tương tác với chúng.
Ví dụ: Nếu biết được địa chỉ ip riêng tư, attacker có thể sửa truy vấn api hợp lệ để truy cập
Sử dụng chức năng stock check,
Giá trị stockApi trỏ đến IP là 192.168.0.1
Từ đây có thể dự đoán rằng dải mạng nội bộ của máy chủ là 192.168.0.x
Brute-force nhằm tìm địa chỉ hợp lệ cho SSRF
Tìm và gửi request POST /product/stock đến Intruder. Sửa giá trị sockApi như sau:
Trong tab Payload
Attack và tìm status code 200
Intercept một request POST /product/stock và sửa thành
Blacklist gồm127.0.0.1 và localhost, hoặc URL nhạy cảm như /admin.
Sử dụng biểu diễn IP thay thể của 127.0.0.1, như 2130706433, 017700000001, hoặc 127.1.
Đăng ký tên miên riêng mà resolve tới 127.0.0.1 (có thể sử dụng spoofed.burpcollaborator.net)
Làm mờ các chuỗi bị chặn bằng cách sử dụng mã hóa URL (admin thành %61%64%6D%69%6E) hoặc thay đổi chữ hoa chữ thường.
Cung cấp một URL bạn kiểm soát, cái mà chuyển hướng đến URL mục tiêu. Thử sử dụng các mã chuyển hướng khác nhau, cũng như các giao thức khác nhau cho URL mục tiêu (như chuyển URL từ http: thành https: )
Sử dụng chức năng stock check, gửi request POST /product/stock đến Repeater.
Thử sửa stockApi thành http://localhost
Có thể đoán rằng ứng dụng sử dụng blacklist để chặn một số hostname
Sử dụng hostname thay thế 127.1
Thành công vượt qua. Nhưng khi thêm đường dân /admin thì tiếp tục bị chặn
Thử làm mờ chuỗi admin bằng URL encode hoặc thay đổi chữ hoa thường. Ở đây thử với Admin thì thành công
Xóa tài khoản carlos bằng cách sửa stockApi như sau
Một số ứng dụng chỉ cho phép các đầu vào khớp với danh sách giá trị hợp lệ (whitelist). Bộ lọc có thể kiểm tra sự khớp ở đầu chuỗi hoặc ở bất kỳ vị trí nào trong chuỗi đầu vào. Có thể bỏ qua bộ lọc này bằng cách khai thác các điểm không nhất quán trong việc phân tích cú pháp URL.
Cụ thể, tiêu chuẩn URL có một số tính năng dễ bị bỏ qua khi thực hiện kiểm tra và xác thực URL:
Chèn thông tin xác thực trước hostname bằng ký tự @, ví dụ: https://expected-host:fakepassword@evil-host.
Sử dụng ký tự # để chỉ định phần fragment của URL, ví dụ: https://evil-host#expected-host.
Khai thác hệ thống phân cấp tên DNS để chèn đầu vào yêu cầu vào một tên DNS đầy đủ do bạn kiểm soát, ví dụ: https://expected-host.evil-host.
Mã hóa URL (URL-encoding) để gây nhầm lẫn cho mã phân tích cú pháp URL, hoặc sử dụng mã hóa kép khi có sự khác biệt trong việc xử lý ký tự URL-encoded giữa bộ lọc và hệ thống back-end.
Kết hợp các kỹ thuật này với nhau để gia tăng khả năng vượt qua các bộ lọc bảo mật.
Sử dụng chức năng stock check, gửi request POST /product/stock đến Repeater.
Đầu tiên, sửa stockApi=http://127.1
Nhận được lỗi External stock check host must be stock.weliketoshop.net. Có thể
hiểu rằng phải là truy vấn trong stock.weliketoshop.net
Sửa stockapi thành stock.weliketoshop.net
Nhận được mã lỗi 500 Internal Server Error
Thử kết nối external stock với username bất kỳ ví dụ như http://hacking@stock.weliketoshop.net
Mã lỗi 500 giống như trên cho thấy máy chủ đang cố kết nối với tài khoản hacking, cho ta cách bypass cách phòng thủ này
Đặt stockApi=http://127.1#@stock.weliketoshop.net ('#' để 127.1 không được hiểu là username )
Lỗi “ 400 Bad Request ” và “External stock check host must be stock.weliketoshop.net”. Có vẻ dấu # là nguyên nhân, cần làm mờ nó
Thực hiện mã hóa lần nữa với dấu #, thành %2523
Thành công vào trang quản trị.
Xóa người dùng carlos: http://127.1%23@stock.weliketoshop.net/admin/delete?username=carlos
Ví dụ, khi ứng dụng cho phép người dùng nhập URL nhưng thực hiện kiểm tra chặt chẽ để ngăn chặn việc khai thác SSRF (Server-Side Request Forgery), nếu ứng dụng có lỗ hổng chuyển hướng mở, có thể tạo ra một URL thỏa mãn bộ lọc nhưng vẫn dẫn đến mục tiêu mong muốn.
Ví dụ, ứng dụng có lỗ hổng chuyển hướng mở với URL:
sẽ trả về một chuyển hướng đến:
Ccó thể lợi dụng lỗ hổng này để vượt qua bộ lọc và khai thác lỗ hổng SSRF như sau:
Khai thác này thành công vì ứng dụng kiểm tra URL của stockAPI nằm trong domain hợp lệ, sau đó yêu cầu URL được cung cấp, dẫn đến chuyển hướng mở và cuối cùng truy cập vào URL nội bộ mà kẻ tấn công mong muốn.
Giải pháp:
Sử dụng chức năng stock check, gửi request POST /product/stock đến Repeater.
Không còn hostname trong api call, cho thấy rằng tính năng này chỉ giới hạn cho phép truy cập local application
Cuối trang có tính năng Next product
Tạo ra request như dưới đây
Đây có thể là lỗ hổng open direction
Sửa stockApi= /product/nextProduct?currentProductId=1&path=http://192.168.0.12:8080/admin/delete?username=carlos
Điều này cho phép chuyển hướng hợp lệ để xóa tài khoản carlos
Blind SSRF xảy ra khi một ứng dụng có thể bị lừa để thực hiện HTTP request đến một URL do người dùng cung cấp, nhưng response từ yêu cầu đó không được trả về phía người dùng ở frontend
Thường thấp hơn so với SSRF thông thường vì bản chất một chiều của nó: không dễ dàng khai thác để lấy dữ liệu nhạy cảm từ hệ thống back-end, mặc dù đôi khi có thể được khai thác để RCE
Phát hiện: Cách đáng tin cậy nhất để phát hiện lỗ hổng Blind SSRF là sử dụng các kỹ thuật out-of-band (OAST): gửi HTTP request đến một hệ thống bên ngoài mà bạn kiểm soát và giám sát các tương tác mạng với hệ thống đó. Sử dụng Burp Collaborator, tạo ra các tên miền duy nhất và gửi chúng dưới dạng payload đến ứng dụng. Nếu quan sát thấy có yêu cầu HTTP đến từ ứng dụng, thì ứng dụng đó có lỗ hổng SSRF.
Lưu ý: Thường khi kiểm tra lỗ hổng SSRF, có thể thấy DNS lookup cho tên miền của Burp Collaborator nhưng không thấy HTTP request tiếp theo. Điều này thường xảy ra khi ứng dụng cố gắng thực hiện HTTP request nhưng bị chặn bởi bộ lọc ở cấp độ mạng.
Khai thác: Vì không thể xem phản hồi từ back-end request, nên không thể sử dụng lỗ hổng này để khám phá nội dung trên các hệ thống mà máy chủ ứng dụng có thể tiếp cận. Tuy nhiên, có thể sử dụng Blind SSRF để thăm dò các lỗ hổng khác trên máy chủ hoặc hệ thống back-end, bằng cách quét địa chỉ IP nội bộ và gửi các payload được thiết kế để phát hiện các lỗ hổng đã biết.
Một cách khác là yêu cầu ứng dụng kết nối đến hệ thống do kẻ tấn công kiểm soát và trả về phản hồi độc hại. Nếu có thể khai thác lỗ hổng nghiêm trọng ở phía máy chủ HTTP, bạn có thể đạt được khả năng thực thi mã từ xa (RCE) trong cơ sở hạ tầng ứng dụng.
Giải pháp:
Truy cập một sản phẩm, chặn yêu cầu trong Burp Suite và gửi nó đến Burp Repeater.
Trong tab Repeater, chọn header Referer, nhấp chuột phải và chọn "Insert Collaborator Payload" để thay thế tên miền ban đầu bằng một tên miền được tạo bởi Burp Collaborator. Gửi yêu cầu.
Chuyển đến tab Collaborator và nhấn "Poll now". Nếu không thấy bất kỳ tương tác nào, chờ vài giây và thử lại, vì lệnh phía máy chủ được thực thi không đồng bộ.
Bạn sẽ thấy một số tương tác DNS và HTTP được khởi tạo bởi ứng dụng kết quả từ payload của bạn.
Giải pháp: Tham khảo
Shellshock
Shellshock là một lỗ hổng bảo mật nghiêm trọng được phát hiện vào năm 2014 trong Bash, một trình shell phổ biến được sử dụng rộng rãi trên các hệ thống Unix/Linux và macOS. Lỗ hổng này cho phép kẻ tấn công thực thi các lệnh tùy ý trên máy chủ từ xa thông qua việc khai thác cách Bash xử lý các biến môi trường
Xây dựng một payload để kiểm thử lỗ hỏng Shellshock như sau:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Tại phiên bản Bash 4.3 nó đã hoạt động, giải thích về câu payload trên:
env: đặt biến môi trường sau đó thực thi luôn câu lệnh phía sau
bash -c: mở một tiến trình con bash sau đó thực thi lệnh phía sau
sau khi mở tiến trình con bash, hệ thống đặt biến môi trường x và hiểu x là một hàm tự động, do không có quy định việc kết thúc của hàm nên hệ thống đã thực thi luôn câu lệnh phía sau và in ra vulnerable, tiếp theo thực thi in ra this is a test.
1. URL không đầy đủ trong các yêu cầu:
Mô tả: Một số ứng dụng chỉ chèn tên máy chủ hoặc phần của đường dẫn URL vào các tham số yêu cầu. Giá trị này sau đó được tích hợp vào URL đầy đủ mà máy chủ sẽ yêu cầu.
Khó khăn: Nếu bạn không kiểm soát toàn bộ URL được yêu cầu, khả năng khai thác có thể bị hạn chế.
Chiến lược: Phân tích cách mà URL được tạo ra từ các tham số và kiểm tra xem có thể thay đổi hoặc điều chỉnh giá trị của các tham số này để thực hiện tấn công SSRF không.
2. URL trong các định dạng dữ liệu:
Mô tả: Một số ứng dụng truyền dữ liệu theo các định dạng có thể bao gồm các URL, mà sau đó có thể được yêu cầu bởi trình phân tích định dạng dữ liệu.
Ví dụ: Định dạng XML có thể chứa các URL và nếu ứng dụng phân tích XML, có thể xảy ra các lỗ hổng XXE (XML External Entity) và SSRF thông qua XXE.
Chiến lược: Xem xét các định dạng dữ liệu mà ứng dụng chấp nhận và phân tích các cách mà URL có thể được xử lý trong các định dạng này.
3. SSRF qua tiêu đề Referer:
Mô tả: Một số ứng dụng sử dụng phần mềm phân tích phía máy chủ để theo dõi các lượt truy cập. Phần mềm này thường ghi lại tiêu đề Referer trong các request, và có thể request các URL từ tiêu đề này
Chiến lược: Tạo các request với tiêu đề Referer chứa các URL độc hại hoặc không mong muốn và kiểm tra xem ứng dụng có thực hiện các yêu cầu tới những URL đó không.
