Bản chất của Tấn công DNS Spoofing Attack đối với các DNS Client, các kiến thức đưa ra ở đây sẽ giúp cho chúng ta hiểu một cách rõ ràng hơn, từ đó ta có thể dễ dàng phát hiện ra một cuộc tấn công kiểu này cũng như ngăn chặn nó.
1. Giới thiệu
Tài liệu này sẽ giới thiệu về kiểu tấn công DNS Spoofing Attack đối với các DNS Client. Các kiến thức đưa ra ở đây sẽ giúp cho chúng ta hiểu được bản chất của vấn đề, từ đó ta có thể dễ dàng phát hiện ra một cuộc tấn công kiểu này cũng như ngăn chặn nó. Các RFC có liên quan sẽ được đưa vào xem xét và tham khảo.
Ngoài ra, để thấy rõ hậu quả của việc tuân theo RFC một cách máy móc mà không chú ý đến những yêu cầu về bảo mật, bài viết này có đưa ra một ví dụ về kiểu tấn công này đối với DNS Resolver Client của Windows XP. Nó cho thấy rõ sự yếu kém trong việc xây dựng DNS Resolver Client của Windows XP. Cụ thể là Windows XP sẽ chấp nhận những gói tin DNS Reply hợp lệ (kiểm tra một số thông tin ở header) mà không cần kiểm tra xem nội dung của nó có phù hợp với nội dung đã truy vấn hay không. Điều này khiến cho Attacker có thể tạo ra những gói tin DNS Reply “giả” với những thông tin được kiểm tra là đúng (một phần header) và những thông tin khác là giả mạo theo ý muốn của Attacker (phần nội dung).
Bài viết này cũng đề cập đến một số kỹ năng nâng cao cho phép Attacker có thể thực hiện thành công kiểu tấn công này đối với một lượng lớn máy tính sử dụng Windows XP mà Attacker không cần biết đến những Request đã gửi ra.
Tài liệu này sẽ giới thiệu về kiểu tấn công DNS Spoofing Attack đối với các DNS Client. Các kiến thức đưa ra ở đây sẽ giúp cho chúng ta hiểu được bản chất của vấn đề, từ đó ta có thể dễ dàng phát hiện ra một cuộc tấn công kiểu này cũng như ngăn chặn nó. Các RFC có liên quan sẽ được đưa vào xem xét và tham khảo.
Ngoài ra, để thấy rõ hậu quả của việc tuân theo RFC một cách máy móc mà không chú ý đến những yêu cầu về bảo mật, bài viết này có đưa ra một ví dụ về kiểu tấn công này đối với DNS Resolver Client của Windows XP. Nó cho thấy rõ sự yếu kém trong việc xây dựng DNS Resolver Client của Windows XP. Cụ thể là Windows XP sẽ chấp nhận những gói tin DNS Reply hợp lệ (kiểm tra một số thông tin ở header) mà không cần kiểm tra xem nội dung của nó có phù hợp với nội dung đã truy vấn hay không. Điều này khiến cho Attacker có thể tạo ra những gói tin DNS Reply “giả” với những thông tin được kiểm tra là đúng (một phần header) và những thông tin khác là giả mạo theo ý muốn của Attacker (phần nội dung).
Bài viết này cũng đề cập đến một số kỹ năng nâng cao cho phép Attacker có thể thực hiện thành công kiểu tấn công này đối với một lượng lớn máy tính sử dụng Windows XP mà Attacker không cần biết đến những Request đã gửi ra.
2. Nguyên lý của DNS Spoofing Attack
Khi người dùng gõ vào trình duyệt một địa chỉ trang Web ví dụ như www.abc.com, trình duyệt sẽ gửi đi một gói tin DNS Request đến DNS Server để yêu cầu cung cấp địa chỉ IP tương ứng với domain đó. Một Attacker có thể xen vào quá trình này bằng cách gửi đến máy tính của người dùng một gói tin DNS Reply với địa chỉ IP giả mạo trước khi họ nhận được gói tin DNS Reply thật sự từ DNS Server.
3. Cách thức xử lý gói tin DNS Reply của DNS Client
Sau khi gửi đi gói tin DNS Request, DNS Client sẽ chờ để nhận được gói tin DNS Reply trên port đã sử dụng để gửi DNS Request. Có 3 bước xử lý khi nhận DNS Reply được đề ra trong tài liệu RFC:
• Kiểm tra header xem có phải là DNS Reply hợp lệ hay không?
• Kiểm tra cấu trúc của gói tin để đảm bảo là gói tin đúng định dạng.
• Kiểm tra TTL xem còn hiệu lực hay không?
Các điều kiện cần và đủ để một gói DNS Reply được coi là hợp lệ, theo suy nghĩ logic thông thường:
Sau khi gửi đi gói tin DNS Request, DNS Client sẽ chờ để nhận được gói tin DNS Reply trên port đã sử dụng để gửi DNS Request. Có 3 bước xử lý khi nhận DNS Reply được đề ra trong tài liệu RFC:
• Kiểm tra header xem có phải là DNS Reply hợp lệ hay không?
• Kiểm tra cấu trúc của gói tin để đảm bảo là gói tin đúng định dạng.
• Kiểm tra TTL xem còn hiệu lực hay không?
Các điều kiện cần và đủ để một gói DNS Reply được coi là hợp lệ, theo suy nghĩ logic thông thường:
1. Địa chỉ IP nguồn của gói tin DNS Reply phải là địa chỉ đích của gói tin DNS Request.
2. Địa chỉ IP đích của gói tin DNS Reply phải là địa chỉ nguồn của gói tin DNS Request.
3. Port nguồn trong gói tin DNS Reply phải trùng với port đích trong gói tin DNS Request.
4. Post đích trong gói tin DNS Reply phải trùng với post nguồn trong gói tin DNS Query.
5. UDP checksum phải có giá trị đúng, phù hợp với nội dung gói tin.
6. Transaction ID trong gói tin DNS Reply phải trùng với Transaction ID trong gói tin DNS Request.
7. Domain name trong phần Question của gói tin DNS Request phải trùng với domain name trong phần Question và Asnwer (nếu có) của gói tin DNS Reply.
Các suy nghĩ chủ quan khi xây dựng DNS Client dẫn đến khả năng bị tấn công Spoofing:
1. Điều kiện (1) không hoàn toàn đúng vì có trường hợp DNS Server có nhiều địa chỉ IP và thực tế là có những DNS Server gửi gói tin DNS Reply cho DNS Client với địa chỉ IP nguồn khác với địa chỉ IP đích trong gói tin DNS Request mà nó nhận được. Vì vậy điều kiện này là không cần thiết để kiểm tra.
2. Điều kiện (2) cũng không hoàn toàn chính xác bởi một Client cũng có thể có nhiều địa chỉ IP. Nó sẽ nhận gói tin DNS Reply khi địa chỉ IP đích trong đó trùng với một trong những địa chỉ IP mà nó sở hữu, không nhất thiết phải là địa chỉ IP nguồn trong gói tin DNS Request. Một ví dụ đơn giản nhất là máy tính bao giờ cũng nhận một gói tin có địa chỉ đích là địa chỉ Broadcast.
3. Điều kiện (3) cũng không cần thiết vì theo như RFC 768 (User Datagram Protocol) có viết “Port nguồn là một trường tùy chọn”. Bên nhận một gói UDP sẽ không quan tâm đến trường port nguồn nếu nó không cần reply ngược trở lại. Trong trường hợp này DNS Reply từ server trả về client được truyền đi bằng UDP và client sẽ không có nhu cầu giao tiếp DNS nào khác với server nữa nên sẽ có thể bỏ qua mà không ảnh hưởng đến hoạt động. Tuy nhiên về mặt kiểm tra logic session DNS thì là một thiếu sót.
4.Đối với điều kiện (4) ta cần xem lại quá trình hoạt động. Khi DNS Client gửi gói tin DNS Request, nó sẽ chờ để nhận gói tin DNS Reply tại port nguồn được ghi trong gói tin DNS Request. Những gói tin Reply gửi đến những port khác là vô nghĩa vì nó không được nhận và xử lý bởi DNS Client. Vì vậy điều kiện này là bắt buộc.
5. Điều kiện (5) có thể là không cần thiết theo RFC1122 (Requirements for Internet Hosts -- Communication Layers) có viết “UDP Checksum là tùy chọn và có giá trị là những bit 0 khi không được sử dụng”. Trong RFC1122 cũng có viết “Một ứng dụng có thể cho tùy chọn việc có sinh ra UDP Checksum hay không nhưng phải đặt mặc định là có sử dụng UDP Checksum”.
6. Điều kiện (6) phải tuân theo RFC1035 (Domain names - implementation and specification) có viết Transaction ID được dùng để “xác định các cặp gói tin Request vào Reply tương ứng”. Vì vậy điều kiện này là bắt buộc.
7. Điều kiện (7) cũng không cần thiết phải tuân theo bởi trong RFC1035 có viết điều kiện này chỉ là để một lần nữa “xác nhận lại phần Question đó đúng là thông tin mà DNS Client muốn biết”. Trong RFC cũng nói rằng trong gói tin DNS Reply bị khuyết phần Question vẫn là hợp lệ và DNS Client sẽ xử lý dựa vào Transaction ID như trên đã nói. Ngoài ra, phần Answer trong gói tin DNS Reply cũng không bắt buộc phải có khi phần Authority đã trỏ tới DNS Server khác, đây chính là trường hợp DNS Server trả về một lời giới thiệu đến một DNS Server khác.
Phân tích các điều kiện với mục đích tấn công:
Qua những phân tích ở trên ta thấy các trường trong header của gói tin không phải lúc nào cũng được kiểm tra chặt chẽ. Tùy thuộc vào cách hiện thực từ RFC vào chương trình ứng dụng mà mỗi chương trình có thể sẽ có các tiêu chí kiểm tra khác nhau. Attacker sẽ lợi dụng việc đó để thực hiện tấn công đối với những chương trình có cơ chế kiểm tra lỏng lẻo, dễ bị đánh lừa.
7. Điều kiện (7) cũng không cần thiết phải tuân theo bởi trong RFC1035 có viết điều kiện này chỉ là để một lần nữa “xác nhận lại phần Question đó đúng là thông tin mà DNS Client muốn biết”. Trong RFC cũng nói rằng trong gói tin DNS Reply bị khuyết phần Question vẫn là hợp lệ và DNS Client sẽ xử lý dựa vào Transaction ID như trên đã nói. Ngoài ra, phần Answer trong gói tin DNS Reply cũng không bắt buộc phải có khi phần Authority đã trỏ tới DNS Server khác, đây chính là trường hợp DNS Server trả về một lời giới thiệu đến một DNS Server khác.
Phân tích các điều kiện với mục đích tấn công:
Qua những phân tích ở trên ta thấy các trường trong header của gói tin không phải lúc nào cũng được kiểm tra chặt chẽ. Tùy thuộc vào cách hiện thực từ RFC vào chương trình ứng dụng mà mỗi chương trình có thể sẽ có các tiêu chí kiểm tra khác nhau. Attacker sẽ lợi dụng việc đó để thực hiện tấn công đối với những chương trình có cơ chế kiểm tra lỏng lẻo, dễ bị đánh lừa.
Ba điều kiện quan trọng mà Attacker cần chú ý đến là
1. Port đích của gói tin DNS Reply phải đúng là port mà DNS Client đang chờ để nhận gói tin DNS Reply. Trường này là một số 2 byte, tùy vào hệ điều hành sẽ có các khoảng giá trị hợp lệ khác nhau. Attacker có thể gửi cùng lúc nhiều gói tin DNS Reply với port đích nằm trong khoảng đó để gói tin DNS Reply có port đích đúng với port mà DNS Client đang sử dụng.
2. Số Transaction ID của gói tin DNS Reply phải trùng với Transaction ID của gói tin DNS Request mà DNS Client đã gửi đi. Đây cũng là một số 2 byte, một số hệ điều hành sử dụng ID này là một số tăng dần, điều này cho phép Attacker có thể dễ dàng đoán nhận được Transaction ID của gói tin DNS Request đã được gửi đi. Attacker cũng có thể cùng lúc gửi đi nhiều gói tin với Transaction ID khác nhau nhằm mục đích sẽ có một gói tin có Transaction ID trùng với gói DNS Request.
3. Để thành công thì gói tin DNS Reply “giả” của Attacker phải được DNS Client tiếp nhận trước gói tin DNS Reply “thật” của DNS Server.
Như vậy, Attacker có thể thực hiện cuộc tấn công này mà không lo bị phát hiện vì có thể giả mạo địa chỉ IP nguồn. Một khi gói tin DNS Reply “giả” đã được DNS Client tiếp nhận thì những thông tin được đọc ra từ đó sẽ được lưu lại trong cache với thời gian được chỉ định trong gói tin. Điều này chính là nguyên nhân khiến cho máy tính truy cập một địa chỉ trang web nhưng nội dung hiện ra không đúng với địa chỉ đó. Điều này sẽ càng nguy hiểm hơn khi máy tính bị tấn công là một DNS Server, lúc đó tất cả những máy tính nào truy vấn domain đó trên DNS Server này cũng sẽ nhận được một kết quả sai trong thời gian thông tin giả mạo đó còn hiệu lực (còn trong thời hạn TimeToLive).
4. Một số kết quả tổng hợp được:
Dưới đây là một số kết quả thu được trong quá trình thử nghiệm. Qua đó ta sẽ thấy đối với mỗi hệ điều hành khác nhau sẽ thu được những kết quả khác nhau. Những trường hợp dưới đây tìm được trong quá trình thử nghiệm với Windows.
WinXP SP1 đang chạy dịch vụ DNS Client:
UDP Client => Server Port 3453 => 53
UDP Client => Server Port 3453 => 53
UDP Client => Server Port 3453 => 53
UDP Client => Server Port 3453 => 53
UDP Client => Server Port 3453 => 53
Các gói tin được gửi đi với port nguồn không đổi. Ngoài ra, khi dịch vụ DNS Client bắt đầu chạy thì DNS Transaction ID là 1 và tăng dần.
WinXP SP1 đang tắt dịch vụ DNS Client:
UDP Client => Server Port 3440 => 53
UDP Client => Server Port 3441 => 53
UDP Client => Server Port 3442 => 53
UDP Client => Server Port 3443 => 53
UDP Client => Server Port 3444 => 53
Các gói tin có port nguồn tăng dần và DNS Transaction ID luôn là 1.
Dưới đây là một số kết quả thu được trong quá trình thử nghiệm. Qua đó ta sẽ thấy đối với mỗi hệ điều hành khác nhau sẽ thu được những kết quả khác nhau. Những trường hợp dưới đây tìm được trong quá trình thử nghiệm với Windows.
WinXP SP1 đang chạy dịch vụ DNS Client:
UDP Client => Server Port 3453 => 53
UDP Client => Server Port 3453 => 53
UDP Client => Server Port 3453 => 53
UDP Client => Server Port 3453 => 53
UDP Client => Server Port 3453 => 53
Các gói tin được gửi đi với port nguồn không đổi. Ngoài ra, khi dịch vụ DNS Client bắt đầu chạy thì DNS Transaction ID là 1 và tăng dần.
WinXP SP1 đang tắt dịch vụ DNS Client:
UDP Client => Server Port 3440 => 53
UDP Client => Server Port 3441 => 53
UDP Client => Server Port 3442 => 53
UDP Client => Server Port 3443 => 53
UDP Client => Server Port 3444 => 53
Các gói tin có port nguồn tăng dần và DNS Transaction ID luôn là 1.
Thử nghiệm đối với WindowsXP Pro Sp2 cho thấy: Mỗi lần khởi động, Windows sẽ tự động truy vấn địa chỉ IP của domain time.windows.com. Truy vấn này được gửi bằng UDP với port nguồn luôn là 1025, port đích là 53 và Transaction ID ngẫu nhiên đến DNS Server.
Nếu Windows nhận được gói tin ICMP Port Unreachable trả lời về thì sẽ tiếp tục gửi truy vấn với port nguồn là 1027. Ngược lại, nếu sau một thời gian mà không nhận được câu trả lời hợp lệ (port và Transaction ID) thì Windows sẽ tiếp tục gửi đi các gói tin như vậy nhưng với port nguồn là 1029. Khi đã biết được những thông tin này, Attacker có thể dùng các công cụ để liên tiếp gửi đi các gói tin DNS Reply “giả” đến các máy tính trong mạng với Transaction ID thay đổi. Một máy tính đang ở trong quá trình truy vấn như vậy nếu nhận được một trả lời với Transaction ID và port đích đúng thì những thông tin trong gói tin đó sẽ được sử dụng và cache vào máy tính. Nói cách khác, một máy tính mới bật lên bao giờ cũng xảy ra quá trình này và có nguy cơ bị tấn công như vậy.
Tài liệu tham khảo:
http://www.infosecwriters.com/text_resources/pdf/ predictability_of_Windows_DNS_resolver.pdf
http://www.phrack.org
Tác giả: bitZero
Nguồn Connection Magazine