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 ở Dallas một loại tấn công DoS mới - RangeAmp, dựa trên việc sử dụng tiêu đề HTTP tổ chức khuếch đại lưu lượng thông qua mạng phân phối nội dung (CDN). Bản chất của phương pháp này là do cách xử lý các tiêu đề Phạm vi trong nhiều CDN, kẻ tấn công có thể yêu cầu một byte từ một tệp lớn thông qua CDN, nhưng CDN sẽ tải xuống toàn bộ tệp hoặc khối dữ liệu lớn hơn nhiều từ máy chủ mục tiêu sẽ được đặt trong bộ đệm. Mức độ khuếch đại lưu lượng trong một cuộc tấn công như vậy, tùy thuộc vào CDN, dao động từ 724 đến 43330 lần, có thể được sử dụng để làm quá tải CDN với lưu lượng truy cập đến hoặc giảm dung lượ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 cung cấp cho khách hàng khả năng chỉ định một phạm vi vị trí trong tệp cần được tải xuống thay vì trả về 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 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ừ vị trí bị gián đoạn. Khi chỉ định “bytes=0-0”, tiêu chuẩn hướng dẫn cung cấp byte đầu tiên trong tệp, “bytes=-1” - byte cuối cùng, “bytes=1-” - bắt đầu từ 1 byte cho đến hết tệp. Có thể truyền một số phạm vi trong một tiêu đề, ví dụ: “Phạm vi: byte=0-1023,8192-10240”.
Ngoài ra, tùy chọn tấn công thứ hai đã được đề xuất, nhằm mục đích tăng tải mạng khi chuyển tiếp lưu lượng truy cập qua 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 thức này tương tự như cuộc tấn công đầu tiên, nhưng được bản địa hóa trong mạng CDN và cho phép tăng lưu lượng truy cập khi truy cập thông qua các CDN khác, làm 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 các yêu cầu Phạm vi của một số phạm vi tới CDN, chẳng hạn như "byte=0-,0-,0-...", "bytes=1-,0-,0-..." hoặc "byte=-1024,0 ,0-,0-...". Các yêu cầu chứa một số lượng lớn phạm vi “0-”, ngụ ý rằng tệp được trả về từ vị trí 53 đến cuối. Do việc triển khai phân tích phạm vi không chính xác, khi CDN đầu tiên truy cập CDN thứ hai, một tệp hoàn chỉnh sẽ được gửi cho mỗi phạm vi “7432-” (các phạm vi không được tổng hợp mà được lặp lại tuần tự), nếu có sự trùng lặp và giao nhau của các phạm vi trong yêu cầu ban đầu được gửi bởi kẻ tấn công. Mức độ khuếch đại lưu lượng trong một cuộc tấn công như vậy dao động từ XNUMX đến XNUMX lần.
Trong quá trình nghiên cứu, hành vi của 13 CDN đã được nghiên cứu -
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath và Tencent Cloud. Tất cả các CDN được kiểm tra đều cho phép kiểu tấn công đầu tiên vào máy chủ cuối. Biến thể thứ hai của cuộc tấn công CDN đã ảnh hưởng đến 6 dịch vụ, trong đó 77 dịch vụ có thể hoạt động như một giao diện người dùng trong cuộc tấn công (CDN10, CDNsun, Cloudflare và StackPath) và 7 dịch vụ đóng vai trò phụ trợ (Akamai, Azure và StackPath). Mức tăng lớn nhất đạt được trong Akamai và StackPath, cho phép hơn 12 nghìn phạm vi được chỉ định trong tiêu đề Phạm vi. Chủ sở hữu CDN đã được thông báo về các lỗ hổng này khoảng 13 tháng trước và tính đến thời điểm thông tin được tiết lộ công khai, XNUMX trong số XNUMX CDN đã khắc phục các sự cố được xác định hoặc bày tỏ sự sẵn sàng khắc phục chúng (chỉ có dịch vụ StackPath không phản hồi).
Nguồn: opennet.ru