Cuộc tấn công NXNSAttack ảnh hưởng đến tất cả các trình phân giải DNS

Nhóm các nhà nghiên cứu đến từ Đại học Tel Aviv và Trung tâm liên ngành ở Herzliya (Israel) đã phát triển phương thức tấn công mới NXNSTấn công (PDF), cho phép bạn sử dụng bất kỳ trình phân giải DNS nào làm bộ khuếch đại lưu lượng, cung cấp tốc độ khuếch đại lên tới 1621 lần về số lượng gói (đối với mỗi yêu cầu được gửi đến trình phân giải, bạn có thể đạt được 1621 yêu cầu được gửi đến máy chủ của nạn nhân) và lên tới 163 lần về lưu lượng.

Sự cố liên quan đến đặc thù của giao thức và ảnh hưởng đến tất cả các máy chủ DNS hỗ trợ xử lý truy vấn đệ quy, bao gồm cả TRÓI BUỘC (CVE-2020-8616) Knot (CVE-2020-12667) PowerDNS (CVE-2020-10995) Máy chủ DNS Windows и cởi ra (CVE-2020-12662), cũng như các dịch vụ DNS công cộng của Google, Cloudflare, Amazon, Quad9, ICANN và các công ty khác. Việc sửa lỗi được phối hợp với các nhà phát triển máy chủ DNS, những người đồng thời phát hành các bản cập nhật để khắc phục lỗ hổng trong sản phẩm của họ. Tính năng chống tấn công được triển khai trong các bản phát hành
Không ràng buộc 1.10.1, Trình giải quyết nút thắt 5.1.1, Bộ đệ quy PowerDNS 4.3.1, 4.2.2, 4.1.16, RIÊNG 9.11.19, 9.14.12, 9.16.3.

Cuộc tấn công dựa trên việc kẻ tấn công sử dụng các yêu cầu đề cập đến một số lượng lớn các bản ghi NS hư cấu chưa từng thấy trước đây, được ủy quyền xác định tên nhưng không chỉ định các bản ghi liên kết với thông tin về địa chỉ IP của máy chủ NS trong phản hồi. Ví dụ: kẻ tấn công gửi truy vấn để phân giải tên sd1.Attacker.com bằng cách kiểm soát máy chủ DNS chịu trách nhiệm về miền attack.com. Để đáp lại yêu cầu của người phân giải tới máy chủ DNS của kẻ tấn công, một phản hồi được đưa ra sẽ ủy quyền xác định địa chỉ sd1.Attacker.com cho máy chủ DNS của nạn nhân bằng cách chỉ ra các bản ghi NS trong phản hồi mà không nêu chi tiết về máy chủ IP NS. Do máy chủ NS được đề cập chưa từng gặp trước đây và địa chỉ IP của nó không được chỉ định nên trình phân giải sẽ cố gắng xác định địa chỉ IP của máy chủ NS bằng cách gửi truy vấn đến máy chủ DNS của nạn nhân phục vụ miền mục tiêu (victim.com).

Cuộc tấn công NXNSAttack ảnh hưởng đến tất cả các trình phân giải DNS

Vấn đề là kẻ tấn công có thể phản hồi bằng một danh sách khổng lồ các máy chủ NS không lặp lại với tên miền phụ nạn nhân hư cấu không tồn tại (fake-1.victim.com, fake-2.victim.com,... fake-1000. nạn nhân.com). Trình giải quyết sẽ cố gắng gửi yêu cầu đến máy chủ DNS của nạn nhân, nhưng sẽ nhận được phản hồi rằng không tìm thấy tên miền, sau đó nó sẽ cố gắng xác định máy chủ NS tiếp theo trong danh sách, v.v. cho đến khi nó thử hết tất cả các yêu cầu. Bản ghi NS được liệt kê bởi kẻ tấn công. Theo đó, đối với yêu cầu của một kẻ tấn công, trình phân giải sẽ gửi một số lượng lớn yêu cầu để xác định máy chủ NS. Vì tên máy chủ NS được tạo ngẫu nhiên và đề cập đến các tên miền phụ không tồn tại nên chúng không được truy xuất từ ​​bộ nhớ đệm và mỗi yêu cầu từ kẻ tấn công đều dẫn đến một loạt yêu cầu tới máy chủ DNS phục vụ miền của nạn nhân.

Cuộc tấn công NXNSAttack ảnh hưởng đến tất cả các trình phân giải DNS

Các nhà nghiên cứu đã nghiên cứu mức độ dễ bị tổn thương của các trình phân giải DNS công cộng đối với vấn đề này và xác định rằng khi gửi truy vấn tới trình phân giải CloudFlare (1.1.1.1), có thể tăng số lượng gói (PAF, Packet Amplification Factor) lên 48 lần, Google (8.8.8.8) - 30 lần, FreeDNS (37.235.1.174) - 50 lần, OpenDNS (208.67.222.222) - 32 lần. Các chỉ số đáng chú ý hơn được quan sát thấy đối với
Cấp 3 (209.244.0.3) - 273 lần, Quad9 (9.9.9.9) - 415 lần
SafeDNS (195.46.39.39) - 274 lần, Verisign (64.6.64.6) - 202 lần,
Ultra (156.154.71.1) - 405 lần, Comodo Secure (8.26.56.26) - 435 lần, DNS.Watch (84.200.69.80) - 486 lần và Norton ConnectSafe (199.85.126.10) - 569 lần. Đối với các máy chủ dựa trên BIND 9.12.3, do yêu cầu song song nên mức khuếch đại có thể lên tới 1000. Trong Knot Resolver 5.1.0, mức khuếch đại xấp xỉ vài chục lần (24-48), do việc xác định Tên NS được thực hiện tuần tự và dựa trên giới hạn nội bộ về số bước phân giải tên được phép cho một yêu cầu.

Có hai chiến lược phòng thủ chính. Đối với hệ thống có DNSSEC đề xuất sử dụng RFC-8198 để ngăn chặn việc bỏ qua bộ đệm DNS vì các yêu cầu được gửi với tên ngẫu nhiên. Bản chất của phương pháp này là tạo ra phản hồi tiêu cực mà không cần liên hệ với các máy chủ DNS có thẩm quyền, sử dụng tính năng kiểm tra phạm vi thông qua DNSSEC. Một cách tiếp cận đơn giản hơn là giới hạn số lượng tên có thể được xác định khi xử lý một yêu cầu được ủy quyền, nhưng phương pháp này có thể gây ra sự cố với một số cấu hình hiện có do giới hạn không được xác định trong giao thức.

Nguồn: opennet.ru

Thêm một lời nhận xét