Một nhóm các nhà nghiên cứu từ Đại học Bắc Kinh, Đại học Thanh Hoa và Đại học Texas tại Dallas phát hành thông tin về công việc của bạn đã làm để có thể xác định một lớp tấn công DoS mới mà họ đặt tên là "RangeAmp" và dựa trên việc sử dụng tiêu đề Range HTTP để tổ chức khuếch đại lưu lượng truy cập qua mạng phân phối nội dung (CDN).
Bản chất của phương pháp vấn đề là, do lỗi xử lý tiêu đề phạm vi trên nhiều CDN, Tiền đạo có thể yêu cầu một byte từ một tệp lớn qua CDN, nhưng CDN sẽ tải xuống toàn bộ tệp hoặc một khối dữ liệu lớn hơn đáng kể từ máy chủ đích cho bộ nhớ đệm.
Mức độ khuếch đại lưu lượng trong một cuộc tấn công kiểu này, theo CDN, là 724 đến 43330 lần, có thể được sử dụng để làm quá tải lưu lượng CDN đến hoặc giảm băng thông của kênh liên lạc cuối cùng đến trang web của nạn nhân.
Tiêu đề Phạm vi cho phép khách hàng xác định phạm vi vị trí trong tệp sẽ được tải thay vì trả lại toàn bộ tệp.
Ví dụ: máy khách có thể chỉ định "Phạm vi: byte = 0-1023" và máy chủ sẽ chỉ truyền 1024 byte dữ liệu đầu tiên. Tính năng này được yêu cầu cao khi tải xuống các tệp lớn: người dùng có thể tạm dừng tải xuống và sau đó tiếp tục tải xuống từ vị trí bị gián đoạn. Khi chỉ định "byte = 0-0", tiêu chuẩn quy định cung cấp byte đầu tiên trong tệp, "byte = -1" - byte cuối cùng, "byte = 1-" - từ 1 byte đến cuối tệp. Bạn có thể chuyển nhiều phạm vi trong một tiêu đề, ví dụ: "Phạm vi: byte = 0-1023.8192-10240".
Bên cạnh đó, một phương án tấn công thứ hai đã được đề xuất (Nó được gọi là cuộc tấn công RangeAmp Overlapping Byte Ranges (OBR), được thiết kế để tăng tải mạng khi lưu lượng truy cập được chuyển tiếp qua một CDN khác, được sử dụng làm proxy (ví dụ: khi Cloudflare đóng vai trò là giao diện người dùng (FCDN) và Akamai đóng vai trò là phụ trợ (BCDN)). Phương pháp tương tự như cuộc tấn công đầu tiên, nhưng được bản địa hóa trong các CDN và cho phép bạn tăng lưu lượng truy cập khi truy cập thông qua các CDN khác, tăng tải cho cơ sở hạ tầng và giảm chất lượng dịch vụ.
Ý tưởng là để kẻ tấn công gửi nhiều phạm vi đến yêu cầu phạm vi CDN, chẳng hạn như "byte = 0-, 0-, 0 - ...", "byte = 1-, 0-, 0 - ..." hoặc "byte = - 1024,0-, 0 -…«.
Yêu cầu chứa một số lượng lớn phạm vi "0-", có nghĩa là trả lại tệp từ đầu cho đến cuối. Do phân tích cú pháp dải ô không chính xác khi CDN đầu tiên tham chiếu đến dải thứ hai, một tệp hoàn chỉnh được trả về từng dải "0-" (các dải không được tổng hợp, mà được sắp xếp theo thứ tự) nếu có sự trùng lặp và giao nhau của dải trong yêu cầu tấn công được gửi ban đầu. Mức độ khuếch đại lưu lượng trong một cuộc tấn công như vậy nằm trong khoảng từ 53 đến 7432 lần.
Nghiên cứu đã kiểm tra hành vi của 13 CDN: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath và Tencent Cloud.
Nhóm nghiên cứu cho biết: “Thật không may, mặc dù chúng tôi đã gửi email cho họ nhiều lần và cố gắng liên hệ với các dịch vụ khách hàng của họ, nhưng StackPath đã không đưa ra bất kỳ phản hồi nào”.
“Nhìn chung, chúng tôi đã cố gắng hết sức để báo cáo có trách nhiệm về các lỗ hổng và cung cấp các giải pháp giảm thiểu. Các nhà cung cấp CDN liên quan đã có gần bảy tháng để thực hiện các kỹ thuật giảm thiểu trước khi tài liệu này được xuất bản. "
Tất cả các CDN được xem xét đều cho phép loại tấn công đầu tiên vào máy chủ mục tiêu. Phiên bản thứ hai của cuộc tấn công CDN hóa ra đã tiếp xúc với 6 dịch vụ, trong đó bốn dịch vụ có thể hoạt động như một giao diện trong cuộc tấn công (CDN77, CDNsun, Cloudflare và StackPath) và ba dịch vụ đóng vai trò back-end (Akamai, Azure và StackPath).
Mức tăng cao nhất đạt được trong Akamai và StackPath, cho phép bạn chỉ ra hơn 10 cấp bậc trong tiêu đề Xếp hạng.
Chủ sở hữu CDN đã được thông báo về lỗ hổng bảo mật khoảng 7 tháng trước và tại thời điểm công bố thông tin, 12 trong số 13 CDN đã giải quyết các vấn đề được xác định hoặc bày tỏ sự sẵn sàng giải quyết chúng.
Fuente: https://www.liubaojun.org