Mơ Hồ
Moderator
-
24/03/2020
-
11
-
15 bài viết
Tấn công đầu độc DNS cache trở lại do điểm yếu trong Linux
Các nhà nghiên cứu từ Đại học Tsinghua và Đại học California vừa phát hiện một cách thức mới có thể bị khai thác để thực hiện tấn công làm nhiễm độc DNS cache (CVE-2020-25705).
Phát hiện mới này gợi lại lỗ hổng năm 2008 có vẻ đã được xử lý triệt để.
Giả mạo DNS hoặc nhiễm độc bộ nhớ cache là gì?
DNS (Domain name system) có thể được hiểu là một cuốn danh bạ trên Internet. Ví dụ khi bạn muốn gọi điện cho ai đó, bạn sẽ cần vào phần danh bạ để tìm số của người đó.
Tương tự, khi bạn muốn đi đến một tên miền, trình duyệt của bạn sẽ cố gắng xác thực địa chỉ IP của tên miền đó bằng cách tra cứu trên DNS. Nhưng trên thực tế, quá trình này không phải lúc nào cũng đơn giản như vậy.
Bạn hoặc ai đó sử dụng máy tính của bạn để truy cập một trang web, địa chỉ IP của trang web đó sẽ được lưu vào bộ nhớ cache trên máy tính hoặc máy chủ trung gian. Lần tiếp theo khi truy cập vào trang web này, máy tính hoặc trình duyệt web của bạn sẽ biết vị trí của trang web mà không cần tra cứu trên DNS nữa.
Hãy tưởng tượng nếu bộ nhớ cache trả lại một địa chỉ IP không chính xác thì sao? Những kẻ tấn công có thể phá huỷ mạng Internet nếu như chúng có thể đầu độc DNS cache.
Ảnh mô phỏng giả mạo DNS hoặc tấn công đầu độc DNS
Nguồn: Bluecat
Năm 2008, nhà nghiên cứu bảo mật Dan Kaminsky phát hiện khi một thiết bị tra cứu địa chỉ IP của tên miền bằng DNS, sẽ chỉ có một ‘transaction ID' duy nhất trong yêu cầu tới máy chủ DNS.
Khi máy chủ phản hồi (ví dụ domain.com có thể được tìm thấy tại 104.20.60.209), thiết bị sẽ chỉ chấp nhận câu trả lời là hợp lệ nếu khớp với ‘transaction ID' ban đầu.
Nếu không được kiểm tra, một máy chủ DNS giả mạo có thể dễ dàng cung cấp cho người dùng một địa chỉ IP giả mạo và khi kết nối với một trang web, người dùng sẽ được chuyển hướng đến máy chủ của kẻ tấn công thay vì máy chủ hợp pháp.
Tuy nhiên, Kaminsky đã phát hiện ra chỉ có 65.536 ‘transaction ID'. Do đó, kẻ tấn công có thể gửi nhiều phản hồi DNS giả với ID từ 0 đến 65.535, đồng thời ngăn phản hồi đầu tiên được lưu vào bộ nhớ cache.
Để làm được điều này, kẻ tấn công sẽ gửi phản hồi với các biến thể nhỏ của miền, chẳng hạn như mọi phản hồi có chứa miền phụ khác nhau: 1.domain.com, 2.domain.com ...
Cuối cùng, kẻ tấn công sẽ có thể đoán đúng transacsion ID của một yêu cầu DNS và đồng thời cung cấp IP máy chủ độc hại của chúng thông qua phản hồi DNS. Lần tới, người dùng truy cập domain.com, tên miền sẽ điều hướng tới máy chủ của kẻ tấn công.
Đầu độc DNS cache quay trở lại như thế nào?
Để ngăn chặn các cuộc tấn công nhiễm độc bộ nhớ cache DNS, cổng nguồn (source port) được thực hiện ngẫu nhiên. Có nghĩa là, kẻ tấn công có thể đoán đúng được một trong những 65.536 ‘transaction ID’ được xác định trong một truy vấn DNS trên thiết bị của bạn. Bạn không biết địa chỉ gửi phản hồi DNS vì thiết bị đang thực hiện tìm kiếm DNS từ một cổng ngẫu nhiên thay vì cổng 53.
Giải pháp này hầu như ngăn chặn được các cuộc tấn công đầu độc DNS cache theo phát hiện của Kaminsky. Nhưng phương pháp lợi dụng tấn công kênh bên mới (Side-channel attack) để suy ra số cổng nguồn của DNS của máy client lại hoàn toàn mới.
Với việc cổng nguồn được tiết lộ, thì rất có thể xảy ra các cuộc tấn công đầu độc DNS cache bằng cách đoán các transaction ID giao dịch. Việc đoán cổng nguồn sẽ trở nên khả thi vì Linux kernel xử lý các yêu cầu ICMP (ping hoặc tracert).
Để tiết kiệm băng thông, bộ giới hạn tốc độ được tích hợp trong Linux mặc định số lượng request gửi đi là 1000 lần/giây và sử dụng bộ đếm để theo dõi các yêu cầu này. Với mọi request nhận được tại một cổng đã đóng trên máy chủ Linux, bộ đếm sẽ giảm đi 1 và máy chủ sẽ trả lời "không thể truy cập".
Có nghĩa là, trong một giây, nếu bạn gửi 1000 gói tin đến các cổng ngẫu nhiên khác nhau trên một máy chủ và tất cả các cổng đó đều đóng, máy chủ sẽ ngắt kết nối bạn trong giây đó.
Vì vậy, cứ mỗi giây kẻ tấn công có thể làm ngập bộ phân giải DNS với 1,000 gói tin giả mạo dành cho các cổng ngẫu nhiên.
Từ đó, chỉ trong vài giây kẻ tấn công sẽ có thể đoán được tất cả các cổng đang mở trên trình phân giải DNS mà chúng muốn đầu độc và tiến hành khai thác lỗ hổng theo cách của Kaminsky.
Cách khắc phục
Giống như việc ngẫu nhiên hóa cổng nguồn có thể gây khó khăn cho kẻ tấn công, Linux kernel ngẫu nhiên hóa giá trị tối đa của bộ giới hạn tốc độ thay vì giá trị 1000.
Hay một bản sửa lỗi được thực hiện đối với tệp icmp.c của Linux Kernel hiện chỉ định một giá trị ngẫu nhiên cho bộ đếm (được gọi là 'credit').
Các giải pháp được đề xuất khác gồm phá hủy kênh bên, vô hiệu hóa ICMP gửi đi hoặc ngẫu nhiên hóa giá trị giới hạn tốc độ (như các nhà phát triển Linux đã làm), giảm thời gian chờ truy vấn DNS để giảm thiểu cửa sổ tấn công và sử dụng các công nghệ như DNSSEC, Cookie DNS hoặc mã hóa 0x20 bit để thêm bí mật cho thông báo DNS.
Ngoài ra, theo các nhà nghiên cứu, lỗ hổng này cũng ảnh hưởng đến các hệ điều hành khác nhưng chưa có bản vá như:
Linux 3.18-5.10 (Bản vá cho Linux được tích hợp vào 5.10)
Windows Server 2019 (phiên bản 1809 trở lên)
FreeBSD (version > 12.1.0)
Theo BleepingComputer
Phát hiện mới này gợi lại lỗ hổng năm 2008 có vẻ đã được xử lý triệt để.
Giả mạo DNS hoặc nhiễm độc bộ nhớ cache là gì?
DNS (Domain name system) có thể được hiểu là một cuốn danh bạ trên Internet. Ví dụ khi bạn muốn gọi điện cho ai đó, bạn sẽ cần vào phần danh bạ để tìm số của người đó.
Tương tự, khi bạn muốn đi đến một tên miền, trình duyệt của bạn sẽ cố gắng xác thực địa chỉ IP của tên miền đó bằng cách tra cứu trên DNS. Nhưng trên thực tế, quá trình này không phải lúc nào cũng đơn giản như vậy.
Bạn hoặc ai đó sử dụng máy tính của bạn để truy cập một trang web, địa chỉ IP của trang web đó sẽ được lưu vào bộ nhớ cache trên máy tính hoặc máy chủ trung gian. Lần tiếp theo khi truy cập vào trang web này, máy tính hoặc trình duyệt web của bạn sẽ biết vị trí của trang web mà không cần tra cứu trên DNS nữa.
Hãy tưởng tượng nếu bộ nhớ cache trả lại một địa chỉ IP không chính xác thì sao? Những kẻ tấn công có thể phá huỷ mạng Internet nếu như chúng có thể đầu độc DNS cache.
Ảnh mô phỏng giả mạo DNS hoặc tấn công đầu độc DNS
Nguồn: Bluecat
Năm 2008, nhà nghiên cứu bảo mật Dan Kaminsky phát hiện khi một thiết bị tra cứu địa chỉ IP của tên miền bằng DNS, sẽ chỉ có một ‘transaction ID' duy nhất trong yêu cầu tới máy chủ DNS.
Khi máy chủ phản hồi (ví dụ domain.com có thể được tìm thấy tại 104.20.60.209), thiết bị sẽ chỉ chấp nhận câu trả lời là hợp lệ nếu khớp với ‘transaction ID' ban đầu.
Nếu không được kiểm tra, một máy chủ DNS giả mạo có thể dễ dàng cung cấp cho người dùng một địa chỉ IP giả mạo và khi kết nối với một trang web, người dùng sẽ được chuyển hướng đến máy chủ của kẻ tấn công thay vì máy chủ hợp pháp.
Tuy nhiên, Kaminsky đã phát hiện ra chỉ có 65.536 ‘transaction ID'. Do đó, kẻ tấn công có thể gửi nhiều phản hồi DNS giả với ID từ 0 đến 65.535, đồng thời ngăn phản hồi đầu tiên được lưu vào bộ nhớ cache.
Để làm được điều này, kẻ tấn công sẽ gửi phản hồi với các biến thể nhỏ của miền, chẳng hạn như mọi phản hồi có chứa miền phụ khác nhau: 1.domain.com, 2.domain.com ...
Cuối cùng, kẻ tấn công sẽ có thể đoán đúng transacsion ID của một yêu cầu DNS và đồng thời cung cấp IP máy chủ độc hại của chúng thông qua phản hồi DNS. Lần tới, người dùng truy cập domain.com, tên miền sẽ điều hướng tới máy chủ của kẻ tấn công.
Đầu độc DNS cache quay trở lại như thế nào?
Để ngăn chặn các cuộc tấn công nhiễm độc bộ nhớ cache DNS, cổng nguồn (source port) được thực hiện ngẫu nhiên. Có nghĩa là, kẻ tấn công có thể đoán đúng được một trong những 65.536 ‘transaction ID’ được xác định trong một truy vấn DNS trên thiết bị của bạn. Bạn không biết địa chỉ gửi phản hồi DNS vì thiết bị đang thực hiện tìm kiếm DNS từ một cổng ngẫu nhiên thay vì cổng 53.
Giải pháp này hầu như ngăn chặn được các cuộc tấn công đầu độc DNS cache theo phát hiện của Kaminsky. Nhưng phương pháp lợi dụng tấn công kênh bên mới (Side-channel attack) để suy ra số cổng nguồn của DNS của máy client lại hoàn toàn mới.
Với việc cổng nguồn được tiết lộ, thì rất có thể xảy ra các cuộc tấn công đầu độc DNS cache bằng cách đoán các transaction ID giao dịch. Việc đoán cổng nguồn sẽ trở nên khả thi vì Linux kernel xử lý các yêu cầu ICMP (ping hoặc tracert).
Để tiết kiệm băng thông, bộ giới hạn tốc độ được tích hợp trong Linux mặc định số lượng request gửi đi là 1000 lần/giây và sử dụng bộ đếm để theo dõi các yêu cầu này. Với mọi request nhận được tại một cổng đã đóng trên máy chủ Linux, bộ đếm sẽ giảm đi 1 và máy chủ sẽ trả lời "không thể truy cập".
Có nghĩa là, trong một giây, nếu bạn gửi 1000 gói tin đến các cổng ngẫu nhiên khác nhau trên một máy chủ và tất cả các cổng đó đều đóng, máy chủ sẽ ngắt kết nối bạn trong giây đó.
Vì vậy, cứ mỗi giây kẻ tấn công có thể làm ngập bộ phân giải DNS với 1,000 gói tin giả mạo dành cho các cổng ngẫu nhiên.
Từ đó, chỉ trong vài giây kẻ tấn công sẽ có thể đoán được tất cả các cổng đang mở trên trình phân giải DNS mà chúng muốn đầu độc và tiến hành khai thác lỗ hổng theo cách của Kaminsky.
Cách khắc phục
Giống như việc ngẫu nhiên hóa cổng nguồn có thể gây khó khăn cho kẻ tấn công, Linux kernel ngẫu nhiên hóa giá trị tối đa của bộ giới hạn tốc độ thay vì giá trị 1000.
Hay một bản sửa lỗi được thực hiện đối với tệp icmp.c của Linux Kernel hiện chỉ định một giá trị ngẫu nhiên cho bộ đếm (được gọi là 'credit').
Các giải pháp được đề xuất khác gồm phá hủy kênh bên, vô hiệu hóa ICMP gửi đi hoặc ngẫu nhiên hóa giá trị giới hạn tốc độ (như các nhà phát triển Linux đã làm), giảm thời gian chờ truy vấn DNS để giảm thiểu cửa sổ tấn công và sử dụng các công nghệ như DNSSEC, Cookie DNS hoặc mã hóa 0x20 bit để thêm bí mật cho thông báo DNS.
Ngoài ra, theo các nhà nghiên cứu, lỗ hổng này cũng ảnh hưởng đến các hệ điều hành khác nhưng chưa có bản vá như:
Linux 3.18-5.10 (Bản vá cho Linux được tích hợp vào 5.10)
Windows Server 2019 (phiên bản 1809 trở lên)
FreeBSD (version > 12.1.0)
Theo BleepingComputer