Blog 👨‍💻

🔏Server-side request forgery (SSRF)

What is SSRF?

Server-side request forgery (SSRF) còn gọi là tấn công yêu cầu giả mạo từ phía máy chủ cho phép kẻ tấn công thay đổi tham số được sử dụng trên ứng dụng web để tạo hoặc kiểm soát các yêu cầu từ máy chủ dễ bị tấn công.

Trong một cuộc tấn công SSRF điển hình, kẻ tấn công có thể khiến máy chủ tạo kết nối với các dịch vụ chỉ nội bộ trong cơ sở hạ tầng của tổ chức. Trong các 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 ý, có khả năng làm rò rỉ dữ liệu nhạy cảm như thông tin đăng nhập ủy quyền.

What is the impact of SSRF attacks?

Một cuộc tấn công SSRF thành công thường có thể dẫn đến các hành động trái phép hoặc truy cập vào dữ liệu trong tổ chức, trong chính ứng dụng dễ bị tấn công hoặc trên các hệ thống back-end khác mà ứng dụng có thể giao tiếp. Trong một số trường hợp, lỗ hổng SSRF có thể cho phép kẻ tấn công thực hiện thực hiện lệnh tùy ý.

Việc khai thác SSRF gây ra kết nối với các 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 hại trở đi dường như bắt nguồn từ tổ chức lưu trữ ứng dụng dễ bị tấn công.

Common SSRF attacks

Các cuộc tấn công SSRF thường khai thác mối quan hệ tin cậy để leo thang 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 back-end 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 chống lại chính server, kẻ tấn công khiến ứng dụng thực hiện HTTP Request trở lại server đ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ó hostnam như (địa chỉ IP dành riêng trỏ đến bộ điều hợp loopback) hoặc (tên thường được sử dụng cho cùng adapter). 127.0.0.1 - local server.

Ví dụ: Hãy 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 phải truy vấn nhiều 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 HTTP Request đầu cuối. Vì vậy, khi người dùng xem trạng thái của một mặt hàng, trình duyệt của họ 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

Trong trường hợp này, server sẽ tạo một request tới url chỉ định, lấy trạng thái của mặt hàng và trả về cho người dùng.

Trong tình huống này, kẻ tấn công 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 và trả lại cho người dùng. /admin

Tất nhiên, bây giờ, kẻ tấn công chỉ có thể truy cập trực tiếp vào URL. Tuy nhiên, chức năng quản trị 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. Vì vậy, kẻ tấn công chỉ cần truy cập trực tiếp vào URL sẽ không thấy bất kỳ điều gì đáng quan tâm. Tuy nhiên, khi yêu cầu tới URL đến từ chính máy cục bộ, các điều khiển truy cập thông thường sẽ bị bỏ qua. Ứng dụng cấp toàn quyền truy cập 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. /admin /admin

SSRF attacks against other back-end systems

Một loại mối quan hệ 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 back-end 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 ví dụ trước, giả sử có một giao diện quản trị tại URL phía sau 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

Circumventing common SSRF defenses

Người ta 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 phòng thủ này có thể bị phá vỡ.

SSRF with blacklist-based input filters

Một số ứng dụng chặn đầu vào có chứa tên máy chủ như 127.0.0.1 và localhost hoặc các URL nhạy cảm như /admin. Trong tình huống này, bạn thường có thể phá vỡ bộ lọc bằng các kỹ thuật khác nhau:

  • Sử dụng đại diện IP thay thế là 127.0.0.1, chẳng hạn như 2130706433, 017700000001 hoặc 127.1. Đăng ký tên miền của riêng bạn có độ phân giải thành 127.0.0.1

  • Bạn có thể sử dụng spoofed.burpcollaborator.net cho mục đích này. 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 biến thể trường hợp. Cung cấp một URL mà bạn kiểm soát, URL này sau đó sẽ chuyển hướng đến URL mục tiêu. Hãy thử sử dụng các mã chuyển hướng khác, cũng như các giao thức khác cho URL mục tiêu.

Ví dụ: chuyển từ http: sang https: URL trong quá trình chuyển hướng đã được hiển thị để bỏ qua một số bộ lọc chống SSRF.

SSRF with whitelist-based input filters

Một số ứng dụng chỉ cho phép đầu vào khớp, bắt đầu bằng hoặc chứa whitelist các giá trị được phép. Trong tình huống này, đôi khi bạn có thể phá vỡ bộ lọc bằng cách khai thác sự không nhất quán trong phân tích cú pháp URL.

Đặc tả URL chứa một số tính năng có thể bị bypass khi triển khai phân tích cú pháp đặc biệt và xác thực URL:

Bạn có thể nhúng thông tin xác thực vào một URL trước tên máy chủ, sử dụng ký tự @.

  • Ví dụ: https://expected-host:fakepassword@evil-host

Bạn có thể sử dụng ký tự # để biểu thị một đoạn URL.

  • #: Ký tự này phân tách giữa địa chỉ gốc và thông tin xác thực (authentication) cho máy chủ thứ hai.

  • Ví dụ: https://evil-host#expected-host

Bạn có thể tận dụng hệ thống phân cấp đặt tên DNS để đặt đầu vào bắt buộc vào một tên DNS đủ điều kiện mà bạn kiểm soát.

  • Ví dụ: https://expected-host.evil-host

Bạn có thể các ký tự mã hóa URL để gây nhầm lẫn cho mã phân tích cú pháp URL. Điều này đặc biệt hữu ích nếu mã triển khai bộ lọc xử lý các ký tự được mã hóa URL khác với mã thực hiện yêu cầu HTTP phía sau. Lưu ý rằng bạn cũng có thể thử mã hóa kép các ký tự; một số máy chủ giải mã URL đệ quy đầu vào mà chúng nhận được, điều này có thể dẫn đến sự khác biệt hơn nữa. Bạn có thể sử dụng kết hợp các kỹ thuật này với nhau.

Bypassing SSRF filters via open redirection

Đôi khi có thể phá vỡ bất kỳ loại phòng thủ dựa trên bộ lọc nào bằng cách khai thác lỗ hổng open redirection.

Trong ví dụ SSRF trước đó, 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 khai thác. Tuy nhiên, ứng dụng có URL được phép chứa lỗ hổng open redirection. 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 open redirection trong đó có URL sau:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

trả về một chuyển hướng đến: http://evil-user.net

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

Khai thác SSRF này hoạt động vì trước tiên, ứ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ở. Nó tuân theo chuyển hướng và đưa ra yêu cầu tới URL nội bộ mà kẻ tấn công chọn.

Blind SSRF vulnerabilities

What is blind SSRF?

Các lỗ hổng SSRF Blind phát sinh khi một ứng dụng có thể được tạo ra để đưa ra yêu cầu HTTP phía sau tới một URL được cung cấp, nhưng phản hồi từ yêu cầu phía sau không được trả lại trong phản hồi phía trước của ứng dụng.

What is the impact of blind SSRF vulnerabilities?

Tác động của các lỗ hổng SSRF blind thường thấp hơn so với các lỗ hổng SSRF được thông báo đầy đủ do tính chất một chiều của chúng. Chúng không thể bị khai thác để truy xuất dữ liệu nhạy cảm từ các hệ thống, mặc dù trong một số trường hợp, chúng có thể bị khai thác để thực thi mã từ xa đầy đủ.

How to find and exploit blind SSRF vulnerabilities

Cách đáng tin cậy nhất để phát hiện các lỗ hổng SSRF blind là sử dụng các kỹ thuật out-of-band (OAST). Điều này liên quan đến việc cố gắng kích hoạt một HTTP request đến một hệ thống bên ngoài mà bạn kiểm soát và theo dõi các tương tác mạng với hệ thống đó.

Cách dễ nhất và hiệu quả nhất để sử dụng các kỹ thuật out-of-band (OAST) là sử dụng Burp Collaborator. Bạn có thể sử dụng Burp Collaborator để tạo các tên miền duy nhất, gửi chúng dưới dạng payload đến ứng dụng và theo dõi mọi tương tác với các miền đó. Nếu một yêu cầu HTTP đến được quan sát thấy đến từ ứng dụng, thì nó dễ bị SSRF.

Sử dụng extension của burp để auto check xem trang có vuln không? Sau khi phát hiện lỗi có thể dùng shellshock để inject được code ở user-agent trỏ về ip của chúng ta. Phía referer thì chuyển thành ip của máy chủ.

Finding hidden attack surface for SSRF vulnerabilities

Nhiều lỗ hổng giả mạo yêu cầu phía máy chủ tương đối dễ phát hiện vì lưu lượng truy cập bình thường của ứng dụng bao gồm các tham số yêu cầu chứa URL đầy đủ. Các ví dụ khác về SSRF khó xác định hơn.

Partial URL in the request

Đô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 toàn bộ URL được yêu cầu.

URL in data format

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 đó. Một ví dụ rõ ràng về điều này là định dạng dữ liệu XML, đã được sử dụng rộng rãi trong các ứng dụng web để truyền dữ liệu có cấu trúc từ máy khách đến máy chủ. Khi một ứng dụng chấp nhận dữ liệu ở định dạng XML và phân tích cú pháp dữ liệu đó, ứng dụng đó có thể dễ bị tiêm nhiễm XXE và ngược lại, dễ bị tấn công bởi SSRF thông qua XXE.

SSRF via Referer header

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 khách truy cập. Phần mềm này thường ghi lại Referer header trong các request, 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 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 các trang web giới thiệu, bao gồm văn bản liên kết được sử dụng trong các liên kết đến. Do đó, Referer header thường đại diện cho bề mặt tấn công hiệu quả đối với các lỗ hổng SSRF. Xem các lỗ hổng Blind SSRF để biết ví dụ về các lỗ hổng liên quan đến Referer header.

PreviousXML external entity (XXE) injectionNextFile upload vulnerabilities

Last updated