Sunday, November 22, 2009

DNS - PXMMRF

Quá trình phân giải một tên miền thành một public IP giúp ta có thể kết nối với một server muc tiêu, thí du một webserver, theo các bứoc cơ bản sau:

1- Đánh tên miền, thí dụ www.hvaonline.net, trên thanh đia chỉ của trình duyệt hay đánh tên miền vào một vị trí qui định trong một tiện ích với DNS-enabled.

2- DNS client (hay còn gọi là DNS lookup client) trong HDH sẽ đựoc kích hoạt. DNS client trong Windows được kích hoạt với sự giúp đỡ của một file Dynamic loaded library (DLL). DNS client sẽ kích hoạt Library Function của DLL và sau đó DLL sẽ tiến hành quá trình kết nối với một DNS server. (Còn trong Linux quá trình có khác một chút: application liên quan (thí dụ trình duyệt web) sẽ chuyển Domain name đến DNS client và chờ nó trả lời).

Các DNS client của Microsoft đều có tính năng Local caching (lưu trữ một bảng phân giài tên miền có sẵn trong máy), tính năng này gọi là DNS client service (hay còn gọi là DNSCACHE).
Từ Windows prompt đánh lệnh ipconfig/displaydns, chúng ta sẽ thấy một bảng phân giải tên miền khá dài, kẻm theo các thông số liên quan như: Record type, TTL, Data Length, A record.. (Hãy thử xem các bạn! Xem xem có những tên miền độc hại, hay tên miền XXX đang bị lưu trữ, ngoài mong muốn của ta hay không ? Hề hề
)
Bảng phân giải tên miền trong DNSCACHE này đựoc DNS client lưu lại sau các lần ta thừong xuyên truy cập đến các website quen thuộc. Nếu ta lại truy cập lần sau đến các website này, thì DNS client sẽ sử dụng các dữ liệu lưu trữ và chuyển đến application (trình duyệt), mà không cần kết nối với một DNS server bên ngoải, nếu như TTL chưa expired.

3-DNS client bắt đầu gửi các truy vấn (request) đến DNS server. Nhưng ta cần nhớ điều này: DNS client sẽ gửi request đến một DNS server "gần" nhất. Đó chính là DNS server đựoc lắp đặt trên local network của user (của ta), thửong là các DNS server của ISP. [Cũng chú ý là DNS client của Windows 2K SP4 và Windows mới hơn đã đựoc cấu hình để trứoc hết gửi request đến ISP Primary DNS server, nếu tại đây tên miền không đựoc phân giải thì nó mới gửi request tiếp đến Secondary DNS server ( hay Slave DNS server)]
Các ISP DNS server chính là recursive DNS server, chúng còn đựoc gọi là các "non-authoritative DNS server", hay là Resolver, mặc dù tôi không thích gọi chúng là Resolver, vì có thể nhầm với một trình Resolver trong HDH.

Nếu tính năng Recursion (Recursion- là hỏi DNS server khác hộ cho ta về việc phân giải tên miền) trên recursive DNS server không bị disabled (một vài Admin. quá cẩn thận làm việc kỳ như vậy đấy) thì nó sẽ tiêp nhận các request từ DNS client và bắt đầu phân giải tên miền. Nếu tên miền cần phân giải đã có trong CACHE của DNS server thì nó sẽ lấy dữ liệu trả lời ngay cho DNS client. DNS client tiếp nhân thông tin trả lởi và chuyển (convert) thông tin từ ngôn ngữ mà DNS server hiểu sang ngôn ngữ mà application (trình duyệt) có thể hiểu đựoc, cho application này. Nếu trong CACHE không có sẵn thì recursive DNS server bắt đầu quá trình hỏi các DNS khác, các DNS bên ngoài (trong RFC 1035-1987, mục 2: Common configuration, ngừoi ta gọi các DNS server bên ngoài này là "Foreign name server"). Vậy chúng thưc sư là các DNS server gì?

4- Recursive DNS server lúc này phải tìm trên mạng các DNSserver chịu trách nhiệm quản lý các hậu tố DNS của tên miền cần phân giải, là .com, .net..., trong thí dụ của ta tên miền cần phân giải là www.hvaonline.net thì recursive DNS server phải tìm ra các DNS server quản lý .net.
Nhưng làm thế nào mà tìm ra đựoc những DNS server quản lý .net trong hàng triệu DNS server trên mạng?
Cũng có cách đấy, recursive DNS server sẽ phải hỏi 13 Root DNS server xem những DNS server nào quản lý .net. Nhưng các Root DNS server ở đâu? Danh sách 13 Root DNS server này, kèm public IP đựoc lưu trữ trong chínhDNS server (phần mềm quàn lý DNS cài trong hệ thống- như Windows DNS, BIND...). Ai đã từng thiết lâp một DNS server sẽ tìm thấy chúng, nếu mở lần lựot các thẻ trên các giao diện của phần mềm. Ngoài ra cũng có thể thấy nó trong 1 file có tên là cache.dns tai thư mục \winnt\system32\dns hay windows\system32\dns.
Recursive DNS server, căn cứ danh sách 13 root DNS server và IP của chúng sẽ gửi các truy vấn đến các root DNS server này.

5- Tiếp nhận các request từ recursive DNS server, một hay một vài root DNS server sẽ trả lởi (respond) vả gửi dữ liệu đến recursive DNS server. Căn cứ thông tin cung cấp từ root DNS server, recursive DNS server sẽ gửi các request đến tất cả DNS server quản lý .net, vì nó không biết rõ trong các DNS server thì cái nào lưu trữ trong cache tên miền hvaonline.net. Môt hay một vài DNS server quản lý hvaonline.net sẽ trả lời recursive DNS server.
Tiếp nhân thông tin phân giải tên miền hvaonline.net từ DNS server nói trên, recursive DNS server sẽ chuyển thông tin phân giải tên miền về cho DNS client của máy ta và DNS client sẽ chuyển tiếp thông tin này cho application (trình duyệt). Chú ý là các DNS server quản lý tên miền hvaonline.net này mới chính là các Authoritative DNS server của tên miền hvaonline.net.

Hơi dài dòng nhỉ phải không các bạn. Nhưng phân tích kỹ quá trình phân giải tên miền chúng ta sẽ thấy rõ những yếu tố làm tiền đề cho các cuộc tấn công "DNS cache poisoning" như kiểu tấn công "Birthday Paradox" hay có thể kiểu tấn công mà Dan Kaminsky đề cập (nói có thể vì cho đến nay anh ta- Dan Kaminsky còn khá trẻ-chưa nói bất cứ chi tiết cụ thể nào về cơ chế tấn công). Anh ta hứa là sẽ chỉ nói vào ngày 6.8.08 tại diễn đàn Black Hat.

Các yếu tố làm tiền đề cho cuôc tấn công "DNS cache poisoning" là:

1- Muc tiêu của cuôc tấn công chủ yếu là các ISP recursive DNS server, không phải là các Foreign name server (hay Authoritative DNS server) vì thừong các user (hay hacker) không "liên hệ" trưc tiếp với chúng.

2- Tên miền gửi kèm theo request gửi từ hacker không có trong recursive DNS server cache.

3- Recursive DNS server phải enable option recursion (nhưng thừong như vậy)

4- Các gói tin trả lời giả mạo gửi từ máy hacker đến Victim recursive DNS server phải hiểu là giả mạo trả lời cùa, từ Authoritative DNS servers (hay gọi là Foreign name servers).

5- Khi hacker gửi các gói tin trả lời giả mạo đến recursive DNS server thì đồng thời các Authoritative DNS cũng gửi các gói tin trả lời thật (hợp lệ) đến recursive DNS server này. Có một sự "cạnh tranh" giữa 2 dòng thông tin. Các Authoritative DNS server thừong khá mạnh, hay rất mạnh. Do vậy muốn thành công hacker có thể phải tìm cách làm chúng "chạy chậm" lại, bằng cách DoS vào các Authoritative DNS server chẳng hạn.

6- Vì các recursive DNS server (hay chính xác hơn là các phần mềm quản lý DNS trong hệ thống) lại đồng thời gửi nhiều request đến tất cả các Authoritative DNS server nên tạo điều kiện thuân lơi khá lớn cho hacker gửi gói tin trả lởi giả mạo có transaction ID (hay còn gọi là requestID) trùng với transaction ID mà recursive DNS server tạo ra một cách xác xuất. Vì vậy gói tin trả lời giả mạo của hacker có thuân lợi hơn để đựoc recursive DNS server coi là hợp lệ và chấp nhận.

7- Nếu recursive DNS server đựoc cấu hình cho TTL đủ ngắn, dù hacker có poisoning đựoc cache của DNS server, thì tác dụng thưc tế của cuộc tấn công cũng rất hạn chế.

No comments:

Post a Comment