Các nhà nghiên cứu bảo mật từ Đại học Tsinghua và Đại học Nankai đã tiết lộ một lỗ hổng nghiêm trọng trong Dnsmasq , một phần mềm DNS được sử dụng rộng rãi có mặt trong vô số router và thiết bị mạng trên toàn thế giới. Lỗ hổng này, được gọi là cuộc tấn công SHAR ( Single-character Hijack via ASCII Resolver-silence ), cho phép kẻ tấn công đầu độc bộ nhớ đệm DNS bằng cách khai thác cách phần mềm xử lý các truy vấn chứa ký tự đặc biệt.
Các Ký Tự Dễ Bị Tấn Công:
- Các ký tự đặc biệt kích hoạt tình trạng im lặng upstream: ~, !, *, _
- Phần mềm bị ảnh hưởng: Dnsmasq (tất cả các phiên bản)
- Tác động: Đầu độc bộ nhớ đệm của bất kỳ tên miền nào
- Loại tấn công: Off-path, không yêu cầu phân mảnh IP
Vấn đề cốt lõi: Phản hồi im lặng từ Upstream
Lỗ hổng tập trung vào sự không khớp cơ bản trong cách các thành phần DNS khác nhau xử lý các truy vấn có ký tự đặc biệt. Khi Dnsmasq nhận được một truy vấn DNS chứa các ký tự như ~, !, hoặc*, nó sẽ chuyển tiếp yêu cầu đến các máy chủ DNS upstream một cách trung thành. Tuy nhiên, một số resolver upstream lại âm thầm loại bỏ các truy vấn này thay vì phản hồi bằng thông báo lỗi thích hợp. Điều này tạo ra tình huống nguy hiểm khi Dnsmasq chờ đợi vô thời hạn một phản hồi sẽ không bao giờ đến.
Trong khoảng thời gian chờ đợi kéo dài này, kẻ tấn công có thể khai thác nghịch lý sinh nhật để brute-force cả transaction ID 16-bit và source port 16-bit. Mặc dù điều này đại diện cho hơn 4 tỷ kết hợp có thể, thực tế toán học lại thuận lợi cho kẻ tấn công hơn nhiều so với vẻ ngoài.
Tranh luận cộng đồng về chi tiết kỹ thuật
Việc tiết lộ đã khơi dậy cuộc thảo luận kỹ thuật sôi nổi trong cộng đồng chuyên gia DNS . Một số thành viên cộng đồng cho rằng việc đóng khung các ký tự đặc biệt là gây hiểu lầm, chỉ ra RFC 2181 nêu rõ rằng bất kỳ chuỗi nhị phân nào cũng có thể được sử dụng trong tên miền. Vấn đề thực sự, họ tranh luận, nằm ở việc các resolver upstream không chính xác khi loại bỏ các yêu cầu hợp lệ và Dnsmasq không xử lý được các phản hồi bị thiếu một cách đúng đắn.
Những người khác lưu ý rằng các nhà cung cấp DNS lớn như Google 8.8.8.8 và Cloudflare 1.1.1.1 phản hồi chính xác các truy vấn này với thông báo lỗi thích hợp, hiệu quả đóng cửa sổ tấn công. Điều này cho thấy tác động của lỗ hổng thay đổi đáng kể tùy thuộc vào việc máy chủ DNS upstream nào được cấu hình.
Các Tùy Chọn Giảm Thiểu:
- Tức thì: Chuyển sang Google DNS (8.8.8.8) hoặc Cloudflare (1.1.1.1)
- Bảo Mật Truyền Tải: Kích hoạt DNS-over-HTTPS (DoH) hoặc DNS-over-TLS (DoT)
- Dài hạn: Triển khai xác thực DNSSEC
- Cấp độ mạng: Triển khai DNS cookies để bảo vệ bổ sung
Tác động tấn công thực tế
Các nhà nghiên cứu đã chứng minh tỷ lệ thành công 100% trên 20 lần thử tấn công, với thời gian thực hiện trung bình khoảng 9,469 giây (khoảng 2.6 giờ). Thời gian này làm cho cuộc tấn công trở nên khả thi cho các tình huống thực tế, đặc biệt xem xét rằng nhiều cài đặt Dnsmasq chạy trên router tiêu dùng có thể không bao giờ nhận được cập nhật bảo mật.
Lỗ hổng trở nên đặc biệt đáng lo ngại khi kết hợp với các kỹ thuật tấn công hiện có như SADDNS và Tudoor , mà các nhà nghiên cứu lưu ý có thể được khuếch đại bởi lỗ hổng này. Khả năng đầu độc bộ nhớ đệm DNS mà không cần kỹ thuật tiên tiến hoặc định vị mạng làm giảm đáng kể rào cản cho các kẻ tấn công tiềm năng.
Thống kê Tấn công:
- Tỷ lệ Thành công: 20/20 (100%) lần thử thành công
- Thời gian Thực hiện Trung bình: ~9,469 giây (2.6 giờ)
- Bề mặt Tấn công: Brute force 32-bit (16-bit TxID + 16-bit source port)
- Số Gói tin Cần thiết Hiệu quả: ~65,535 (do nghịch lý sinh nhật)
Chiến lược giảm thiểu và giải pháp dài hạn
Trong khi các nhà nghiên cứu khuyến nghị triển khai cơ chế phát hiện cho sự im lặng upstream và giới hạn tốc độ tương tự như PowerDNS , cuộc thảo luận cộng đồng tiết lộ rằng giải pháp cơ bản nằm ở việc xác thực mật mã thích hợp. DNSSEC , được thiết kế đặc biệt để giải quyết các cuộc tấn công giả mạo DNS , vẫn là biện pháp bảo vệ mạnh mẽ nhất chống lại các nỗ lực đầu độc bộ nhớ đệm.
Tuy nhiên, thực tế là việc áp dụng DNSSEC vẫn còn hạn chế, và nhiều tên miền sẽ là mục tiêu trong các cuộc tấn công như vậy thiếu chữ ký thích hợp. Để bảo vệ ngay lập tức, các quản trị viên mạng có thể chuyển sang các nhà cung cấp DNS công cộng lớn xử lý các truy vấn sai định dạng một cách chính xác, hoặc triển khai DNS-over-HTTPS ( DoH ) và DNS-over-TLS ( DoT ) để thêm mã hóa truyền tải.
Việc tiết lộ làm nổi bật vấn đề rộng lớn hơn với các lỗ hổng vốn có của giao thức DNS , đã được biết đến từ năm 1993 nhưng tiếp tục ảnh hưởng đến các hệ thống hiện đại do việc triển khai rộng rãi giao thức và những thách thức trong việc triển khai các biện pháp bảo mật toàn diện trên các môi trường mạng đa dạng.
Tham khảo: [Dnsmasq-discuss] [Security Report] Critical Cache Poisoning Vulnerability in Dnsmasq