Server-side request forgery (SSRF)
Trong phần này, giải thích SSRF là gì, miêu tả một số ví dụ phổ biến và giải thích làm thế nào để tìm và khai thác các loại lỗ hổng SSRF khác nhau.
SSRF là gì ?
Giả mạo yêu cầu phía máy chủ (SSRF) là một lỗ hổng bảo mật web cho phép attacker làm cho ứng dụng phía máy chủ thực hiện các yêu cầu đến một vị trí ngoài ý muốn.
Trong một cuộc tấn công SSRF, attacker có thể khiến máy chủ tạo kết nối với các dịch vị chỉ dành riêng cho nội bộ trong cơ sở hạ tầng của tổ chức. Trong một số trường hợp khác, họ có thể buộc máy chủ kết nối với các hệ thống bên ngoài tùy ý, làm tăng khả năng làm rò rỉ dữ liệu nhạy cảm.
Tác động của SSRF
Một cuộc tấn công SSRF thường có thể dẫn đến các hành động hoặc quyền truy cập trái phép vào dữ liệu của tổ chức, trong chính ứng dụng dễ bị tấn công hoặc trên các hệ thống phụ trợ khác mà ứng dụng có thể kết nối, đôi khi là thực hiện lệnh tùy ý.
Một cuộc tấn công SSRF gây ra kết nối với hệ thống thứ 3 bên ngoài có thể dẫn đến các cuộc tấn công nguy hiểm.
Các cuộc tấn công SSRF phổ biến và thực hành lab
Các cuộc tấn công SSRF thường khai thác các mối quan hệ tin cậy để leo thang cuộc tấn công từ ứng dụng dễ bị tấn công và thực hiện các hành động trái phép. Các mối quan hệ tin cậy này có thể tồn tại liên quan đến chính máy chủ hoặc liên quan đến các hệ thống phụ trợ khác trong cùng một tổ chức.
SSRF attacks against the server itself
Trong một cuộc tấn công SSRF vào chính máy chủ, attacker khiến ứng dụng thực hiện yêu cầu HTTP trở lại máy chủ đang lưu trữ ứng dụng, thông qua giao diện mạng vòng lặp của nó. Điều này thường liên quan đến việc cung cấp một URL có tên máy chủ như 127.0.0.1 hoặc localhost
Ví dụ: Cùng xem xét một ứng dụng mua sắm cho phép người dùng xem liệu một mặt hàng có còn hàng trong một cửa hàng cụ thể hay không. Để cung cấp thông tin về kho hàng, ứng dụng sử dụng nhiều truy vấn API REST back-end khác nhau, tùy thuộc vào sản phẩm và cửa hàng được đề cập. Chức năng này được triển khai bằng cách chuyển URL tới điểm cuối API phụ trợ có liên quan thông qua yêu cầu HTTP đầu cuối. Vì vậy, khi người dùng xem trạng thái còn hàng của một mặt hàng, trình duyệt sẽ đưa ra yêu cầu như sau:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
Điều này khiến máy chủ đưa ra yêu cầu tới URL đã chỉ định, truy xuất trạng thái stock và trả lại cho người dùng.
Trong tình huống này, attacker có thể sửa đổi yêu cầu chỉ định URL cục bộ cho chính máy chủ. Ví dụ:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118
stockApi=http://localhost/admin
Tại đây, máy chủ sẽ lấy nội dung của URL /admin và trả lại cho người dùng. Tất nhiên, attacker chỉ có thể truy cập trực tiếp vào URL /admin. Tuy nhiên, chức năng quản trị viên thường chỉ có thể truy cập được đối với những người dùng có xác thực phù hợp. Tuy nhiên, khi yêu cầu /admin đến từ chính máy cục bộ, các kiểm soát truy cập thông thường sẽ bị bỏ qua. Ứng dụng cấp toàn quyền vào chức năng quản trị vì yêu cầu dường như bắt nguồn từ một địa điểm đáng tin cậy
Thực hành lab: ( Level : Apprentice)
Tên lab: Basic SSRF against the local server
Nội dung lab: Trong trang web này có tính năng kiểm tra hàng tồn kho để lấy dữ liệu từ một hệ thống nội bộ. Để giải quyết lab này. Hãy thay đổi URL kiểm tra hàng tồn kho để truy cập giao diện quản trị http://localhost/admin và xóa người dùng carlos.
Thực hiện lab:
Dùng Burpsuite để chặn và sửa đổi request
Trong phần stockApi, sửa giá trị thành : http://localhost/admin và gửi request:
Thực hiện xóa người dùng carlos để hoàn thành lab. Gửi lại request và sửa đổi giá trị stockApi thành: http://localhost/admim/delete?username=carlos
Một câu hỏi được đặt ra: Tại sao các ứng dụng hoạt động theo cách này hoàn toàn tin tưởng các yêu cầu từ máy chủ cục bộ ? Vì:
Kiểm tra kiểm soát truy cập có thể được triển khai trong một thành phần khác nằm phía trước máy chủ của ứng dụng. Khi một kết nối được thực hiện trở lại chính máy chủ, quá trình kiểm tra sẽ bị bỏ qua.
Đối với mục đích khắc phục sự cố, ứng dụng có thể cho phép truy cập quản trị mà không cần đăng nhập đối với bất kỳ người dùng nào từ máy cục bộ. Điều này cung cấp một cách để quản trị viên khôi phục hệ thống trong trường hợp họ mất thông tin đăng nhập. Giả định ở đây là chỉ người dùng hoàn toàn đáng tin cậy mới đến trực tiếp từ chính máy chủ.
Giao diện quản trị viên có thể đang lắng nghe trên một số cổng khác với ứng dụng chính và do đó người dùng có thể không truy cập trực tiếp được.
SSRF attacks against other back-end systems
Một loại mối quan hệ đáng tin cậy khác thường phát sinh với giả mạo yêu cầu phía máy chủ là nơi máy chủ ứng dụng có thể tương tác với các hệ thống phụ trợ khác mà người dùng không thể truy cập trực tiếp. Các hệ thống này thường có địa chỉ IP riêng không thể định tuyến. Vì các hệ thống backend thường được bảo vệ bởi cấu trúc liên kết mạng nên chúng thường có tình trạng bảo mật yếu hơn. Trong nhiều trường hợp, hệ thống back-end nội bộ chứa chức năng nhạy cảm có thể được truy cập mà không cần xác thực bởi bất kì ai có thể tương tác với hệ thống.
Trong bài lab trước, giả sử có một giao diện quản trị tại back-end URL https://192.168.0.68/admin . Tại đây, kẻ tấn công có thể khai thác lỗ hổng SSRF để truy cập giao diện quản trị bằng cách gửi yêu cầu sau:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118
stockApi=http://192.168.0.68/admin
Thực hành lab: (Level Apprentice)
Tên lab: Basic SSRF against another back-end system
Nội dung lab: Trong lab này có tính năng kiểm tra hàng tồn kho để lấy dữ liệu từ một hệ thống nội bộ. Để giải quyết, hãy xử dụng chức năng kiểm tra hàng tồn kho để quét phạm vi nội bộ 192.168.0.x của giao diện admin trên port 8080. Xóa người dùng carlos để hoàn thành lab.
Thực hiện lab:
Dùng Burp suite để chặn và sửa đổi request.
Gửi yêu cầu tới Intruder và sửa đổi giá trị stockApi thành: http://192.168.0.x:8080/admin Fuzzing range từ 1-255 và chọn kết quả trả về là 200
Ok, sau khi thấy ứng dụng chạy trên http://192.168.1.162:8080/admin. Tiến hành xóa carlos để hoàn thành lab:
stockApi=http://192.168.1.162:8080/admin/delete?username=carlos
Circumventing common SSRF defenses
Thường thấy các ứng dụng chứa hành vi SSRF cùng với các biện pháp bảo vệ nhằm ngăn chặn hành vi khai thác độc hại. Thông thường, những biện pháp bảo vệ này có thể bị phá vỡ.
SSRF with blacklist-based input filters
Một số ứng dụng web chặn nội dung chứa hostnames như 127.0.0.1 hay localhost hoặc URL nhạy cảm như /admin. Trong trường hợp này, có thể bypass filter bằng các kỹ thuật khác nhau:
Sử dụng một tại diện IP thay thế của 127.0.0.1 như 2130706433,017700000001 hoặc 127.1
Đăng kí tên miền của riêng bạn phân giải thành 127.0.0.1
Làm xáo trộn các chuỗi bị chặn bằng cách sử dụng mã hóa URL hoặc các trường hợp biến thể.
Thực hành lab: (Level Practitioner)
Tên lab: SSRF with blacklist-based input filter
Nội dung lab: Trong lab này có tính năng kiểm tra hàng tồn kho để lấy dữ liệu từ một hệ thống nội bộ. Để giải quyết vấn đề này, hãy thay đổi URL stockApi để truy cập giao diện quản trị viên tại http://localhost/admin và xóa người dùng carlos.
Thực hiện lab:
Sử dụng Burp suite để chặn và sửa đổi request
Trong request, sửa đổi giá trị stockApi thành: http://127.0.0.1/
Dường như trang web đã có cơ chế bảo vệ đối với payload này. Cùng thử vượt qua filter bằng biến thể của localhost như đã trình bày ở trên xem sao.
Bỏ qua filter bằng cách sử dụng http://127.1
Như vậy, khá khả quan đối với cách này. Giờ cần truy cập đến URL /admin. Nhưng dường như bị filter đối với URL gốc này. Ở đây có thể mã hóa URL. Mã hóa đơn URL admin thì vẫn bị filter, chúng ta thử mã hóa kép URL này xem sao:
Ok. Bypass là truy cập thành công. Xóa người dùng carlos để hoàn thành lab.
Bypassing SSRF filters via open redirection
Đôi khi có thể phá vỡ bất kỳ loại phòng thủ dựa trên filter nào bằng cách khai thác lỗ hổng chuyển hướng mở.
Giả sử URL do người dùng gửi được xác thực nghiêm ngặt để ngăn hành vi SSRF có hại. Tuy nhiên, ứng dụng có URL được phép chứa lỗ hổng chuyển hướng mở. Miễn là API được sử dụng để tạo yêu cầu HTTP phía sau hỗ trợ chuyển hướng, bạn có thể tạo một URL đáp ứng bộ lọc và dẫn đến yêu cầu được chuyển hướng tới mục tiêu phía sau mong muốn.
Ví dụ: giả sử ứng dụng chứa lỗ hổng chuyển hướng mở trong đó có URL sau:
/product/nextProduct?currentProductId=6&path=http://evil-user.net
Trang web trả về một chuyển hướng đến : http://evil-users.net
Như vậy, bạn có thể tận dụng lỗ hổng chuyển hướng mở để bỏ qua bộ lọc URL và khai thác lỗ hổng SSRF:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin
Tại sao exploit SSRF này hoạt động ? Vì : ứng dụng xác thực rằng URL stockAPI được cung cấp nằm trên một miền được phép. Sau đó, ứng dụng sẽ yêu cầu URL được cung cấp, URL này sẽ kích hoạt chuyển hướng mở => chuyển hướng yêu cầu tới URL nội bộ mà attacker đã chọn.
Thực hành lab: (Level Practitioner)
Tên lab : SSRF with filter bypass via open redirection vulnerability
Nội dung lab : Phòng lab này có chứa chức năng kiểm tra hàng tồn kho lấy dữ liệu từ hệ thống nội bộ. Để hoàn thành lab, hãy thay đổi URL kiểm tra stock để truy cập giao diện quản trị tại http://192.168.0.12:8080/admin và xóa người dùng carlos.
Thực hiện lab :
Truy cập một sản phẩm và kiểm tra hàng tồn kho của sản phẩm đó.
Thử giả mạo tham số stockApi và thấy rằng không thể khiến máy chủ đưa ta yêu cầu trực tiếp đến một máy chủ khác :
Khi nhấn vào " Next Product" thấy một tham số path được thêm vào URL stockApi . Gửi 1 request mới và thay đổi giá trị stockAPi thành: /product/nextProduct?path=http://192.168.0.12:8080/admin
Truy cập trang admin thành công, xóa người dùng carlos để hoàn thành lab.
/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos
Finding hidden attack surface for SSRF vulnerabilities
Partial URLs in requests
Đôi khi, một ứng dụng chỉ đặt tên máy chủ hoặc một phần của đường dẫn URL vào các tham số yêu cầu. Sau đó, giá trị đã gửi được kết hợp phía máy chủ vào một URL đầy đủ được yêu cầu. Nếu giá trị dễ dàng được nhận dạng là tên máy chủ hoặc đường dẫn URL, thì bề mặt tấn công tiềm năng có thể rõ ràng. Tuy nhiên, khả năng khai thác dưới dạng SSRF đầy đủ có thể bị hạn chế do bạn không kiểm soát được toàn bộ URL được yêu cầu.
URLs within data formats
Một số ứng dụng truyền dữ liệu ở định dạng có thông số kỹ thuật cho phép bao gồm các URL có thể được trình phân tích cú pháp dữ liệu yêu cầu cho định dạng đó.
SSRF via the Referer header
Một số ứng dụng sử dụng phần mềm phân tích máy chủ để theo dõi khách truy cập. Phần mềm này thường ghi lại Referer header trong các yêu cầu, vì đây là mối quan tâm đặc biệt để theo dõi các liên kết đến. Thường thì phần mềm sẽ phân tích sẽ thực sự truy cập bất kì URL của bên thứ ba nào xuất hiện trong Referer header. Điều này thường được thực hiện để phân tích nội dung của referring sites, bao gồm văn bản liên kết được sử dụng trong các liên kết đến.
Last updated
