HOANG ANH

Nhiều hệ thống DNS đang hoạt động chấp nhận xử lý đồng thời nhiều yêu cầu truy vấn (query) của một tên miền duy nhất, đặc điểm này cho phép tin tặc dễ dàng tấn công vào các DNS server có chức năng hỏi hộ (recursive) và lưu giữ kết quả (caching) với mục đích làm thay đổi ánh xạ tên miền và hướng người dùng đến một địa chỉ IP bất hợp lệ tuỳ ý.

1. Mô tả

Sơ đồ tổng quan kịch bản tấn công:
Đối tượng tin tặc nhắm đến là các DNS server có các đặc điểm sau đây:

• Phục vụ nhiều người dùng.
• Có chức năng hỏi hộ (recursive) và lưu giữ kết quả (caching).
• Có điểm yếu: chấp nhận xử lý đồng thời nhiều yêu cầu truy vấn (query) của một tên miền duy nhất.
• Sử dụng 1 port nguồn (UDP hay TCP) cố định và duy nhất cho tất cả các request.
• (Tuỳ chọn) không kiểm tra chặt chẽ tính chính xác và logic của phần thông tin thêm (addition records) trong các DNS reply trả về.

Ghi chú: khảo sát sơ bộ cho thấy hầu hết các DNS server đang hoạt động tại Việt Nam đang có các đặc điểm này!

Kịch bản tấn công:

- Tin tặc gửi đồng loạt Q request về một tên miền bất kỳ (trong hình trên là ) cho DNS server có điểm yếu (trong hình trên là máy chủ DNS RA).

- Ngay sau đó sẽ đồng loạt gửi R reply giả mạo trả lời từ máy chủ AA về máy chủ RA với các giá trị định danh QID thăm dò là ngẫu nhiên.

- Nếu QID trong một reply giả mạo được chấp nhận (khả năng các nhà toán học tính toán được là rất cao, xin xem thêm phần tính toán thống kê bên dưới) RA sẽ cập nhật vào cache và từ đó về sau sẽ trả lời tên miền có địa chỉ là 169.15.X.X là địa chỉ mà tin tặc muốn người dùng hướng vào (địa chỉ đúng là 203.162.X.X).

Tính toán thống kê:

Tính toán của Vagner Sacramento (Department of Computer Science and Applied Mathematics / Federal University of Rio Grande do Norte) tại địa chỉ được tóm tắt trong bảng sau:

Máy chủ DNS Số lượng request cần gửi đồng thời (Q) Số lượng gói tin giả mạo tin tặc cần gửi (R) Không random port 1 32.7 ngàn (215) Không random port 4 10.4 ngàn Không random port 200 427 Không random port Không giới hạn 426 Có random port 1 2.1 tỷ (231) Có random port 4 683 triệu Có random port 200 15 triệu Có random port Không giới hạn 109 ngàn Bảng tính toán: Số lượng gói tin (giả mạo reply từ AA) mà tin tặc cần gửi (giá trị R trong hình minh hoạ trên) để có xác xuất thành công 50% Như vậy chỉ cần gửi Q=200 request đồng thời về một tên miền và gửi R=427 reply giả mạo thì tin tặc có khả năng dự đoán QID thành công là 50%.

2. Tác hại

Hacker có thể lợi dụng yếu điểm này để triển khai tấn công quy mô lớn và toàn diện vào các hệ thống DNS gây tác hại trực tiếp đến người dùng internet, phát tán mã độc, lừa đảo. Thông qua việc hướng số lượng lớn người dùng vào một website để phát động tấn công DDOS quy mô lớn vào các hệ thống thông tin bất kỳ.

3. Giải pháp

a) Dành cho các ISP, hosting provider, cá nhân-tổ chức sở hữu và quản lý máy chủ DNS

Theo dõi và cập nhật ngay lập tức các bản vá dịch vụ DNS đang sử dụng trên các DNS server.
Kiểm tra, rà soát và khắc phục khẩn trương các đặc điểm của DNS server mà tin tặc đang lợi dụng để tấn công (không random port, phục vụ nhiều request đồng thời, không kiểm tra phần addition records, …). Có thể áp dụng chức năng hỗ trợ random port của firewall nếu phần mềm DNS đang sử dụng không hỗ trợ (tham khảo ).

Tăng cường theo dõi, thống kê và có kế hoạch phản ứng thích hợp khi phát hiện dấu hiệu tấn công (tăng vọt số lượng DNS request đồng thời của một tên miền hay người dùng thông báo các hiện tượng lạ).

Xem xét giảm thời gian lưu giữ tạm thời (TTL) các bản ghi trên cache máy chủ DNS (nếu có thể)

b) Dành cho người dùng Internet

Tạm thời nên sử dụng các DNS server đã khắc phục lỗi. Tạm thời người dùng có thể sử dụng máy chủ OpenDNS có địa chỉ 208.67.222.222, 208.67.220.220.

Cập nhật đầy đủ các bản vá của hệ điều hành, phần mềm diệt virus và tăng cường phòng bị trong thời gian tới.

Các hệ thống có khả năng bị ảnh hưởng

Hãng
Trạng thái
Ngày cập nhật


Not Vulnerable
15 - 11 - 2002


Vulnerable
3 - 12 - 2002


Unknown
18 - 11 - 2002


Unknown
15 - 11 - 2002


Not Vulnerable
4 - 11 - 2002

Unknown
29 - 10 - 2002


Unknown
15 - 11 - 2002


Unknown
29 - 10 - 2002


Vulnerable
24 - 07 - 2003


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Vulnerable
3 - 12 - 2002

Not Vulnerable
18 - 11 - 2002


Unknown
15 - 11 - 2002


Unknown
15 - 11 - 2002


Vulnerable
18 - 10 - 2004


Vulnerable
18 - 11 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Vulnerable
18 - 11 - 2002


Vulnerable
19 - 11 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Vulnerable
21 - 11 - 2002


Not Vulnerable
19 - 11 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Unknown
18 - 11 - 2002


Vulnerable
4 - 12 - 2002


Unknown
15 - 11 - 2002

Unknown
29 - 10 - 2002


Unknown
5 - 12 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Unknown
15 - 11 - 2002


Unknown
15 - 11 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Unknown
29 - 10 - 2002


Not Vulnerable
30 - 05 - 2003

Tham khảo














Cám ơn

Dan Kaminsky, Vagner Sacramento, CAIS/RPN, US-CERT/CC, Dương Ngọc Thái và nhiều cá nhân tổ chức đã nỗ lực đóng góp nhiều thông tin và ý kiến quý báu.

Thông tin khác

23/07/2008
23/07/2008
CBND 08-003
cao

Theo VNCERT



Hôm thứ 2 vừa qua, một công ty bảo mật đã vô tình công bố chi tiết về một lỗ hổng lớn trên hệ thống tên miền (DNS) Internet, sớm hơn vài tuần trước khi những thông tin này được phép chính thức công bố.

Lỗ hổng này được phát hiện vài tháng trước bởi Dan Kaminsky, một nhà nghiên cứu của IOActive, người làm việc từ đầu năm nay với các nhà cung cấp phần mềm Internet như Microsoft, Cisco và Internet Systems Consortium để khắc phục lỗi bảo mật này.

Các công ty đã đưa ra bản vá lỗi 2 tuần trước, đồng thời khuyến kích người sử dụng và các nhà cung cấp dịch vụ Internet vá lỗi trên các hệ thống tên miền của họ càng sớm càng tốt. Theo Kaminsky, mặc dù vấn đề này có thể ảnh hưởng đến một vài người sử dụng gia đình, nhưng nó không được coi là vấn đề lớn đối với đa số khách hàng.

Vào thời điểm công bố lỗ hổng này, Kaminsky đề nghị các thành viên của hội nghiên cứu về bảo mật mạng không tiết lộ bản chất cụ thể của nó nhằm giúp người sử dụng có thêm thời gian để sửa hệ thống của họ. Kaminsky đã lên kế hoạch công bố thông tin chi tiết về lỗ hổng này vào buổi thuyết trình tại hội nghị bảo mật Black Hat, được tổ chức vào ngày 6/8 tới.

Một vài nhà nghiên cứu coi đề nghị này như là một lời thách thức tìm ra lỗ hổng đó trước buổi thuyết trình của Kaminsky. Một vài người khác thì lại phàn nàn về việc không được biết các thông tin chi tiết kỹ thuật của lỗi này.

Bí mật bị tiết lộ

Thứ 2 vừa qua, giám đốc điều hành của Zynamics.com – Thomas Dullien (người có biệt danh là Halvar Flake) đã đưa ra pỏng đoán về lỗi bảo mật DNS này và thừa nhận rằng ông biết không nhiều về DNS.

Phát hiện này của ông sau đó đã nhanh chóng được xác nhận lại bởi Matasano Security, hãng bảo mật đã cung cấp thông tin chi tiết đầu tiên về vụ việc này trước đó. “Bí mật đã bị tiết lộ. Halvar Flake đã khám phá ra lỗ hổng mà Dan Kaminsky định công bố tại Black Hat” Matasano nói trên một bài blog. Bài viết này đã bị xóa đi ngay sau đó 5 phút, vào lúc 1h30’ chiều. Nhưng các bản sao bài viết lập tức đã nhanh chóng được chuyền tay nhau trên Internet, và một trong số chúng đã được đọc bởi IDG News Service.

Bài viết của Matasano thảo luận về các thông tin kỹ thuật chi tiết của lỗi này, nói rằng bằng cách sử dụng kết nối Internet nhanh, một hacker có thể tấn công "đầu độc bộ nhớ cache DNS" (DNS cache poisoning attack) thành công vào một máy chủ tên miền, nhằm chuyển hướng truy cập một địa chỉ web nhiều người truy cập (chẳng hạn ) sang một website có chứa mã độc chỉ trong vòng 10 giây.

Một nhà nghiên cứu của hãng Matasano – Thomas Ptacek đã từ chối bình luận về việc liệu Flake có thực sự khám phá ra lỗi đó hay không, nhưng trong một cuộc phỏng vấn qua điện thoại ông có nói vấn đề đã được “vô tình công bố quá sớm”. Ptacek là một trong số ít các nhà nghiên cứu bảo mật được thông tin chi tiết về lỗi này. Ông cũng đã đồng ý không bình luận gì về lỗi này trước khi thông tin chi tiết được công bố chính thức.

Bài viết của Matasanno đã vô tình khẳng định rằng Flake đã mô tả đúng lỗi này, Ptacek thừa nhận.

Thứ 2 vừa qua, Ptacek đã xin lỗi Kaminsky trên blog công ty ông. Ông viết “Chúng tôi rất lấy làm tiếc về việc này. Chúng tôi đã gỡ bỏ bài viết này ngay khi phát hiện ra, nhưng không may là chỉ cần vài giây là thông tin đã được lan truyền khắp Internet”.

Sự kết hợp nguy hiểm

Sau khi xem xong bài viết của Matasano, Cricket Liu – phó chủ tịch kiến trúc ứng dụng DNS hãng Infoblox - nói, Phương thức tấn công được Kaminsky mô tả bằng cách lợi dụng một vài lỗi DNS đã biết, kết hợp chúng với nhau theo một cách mới.

Lỗi này liên quan đến cách các máy trạm và máy chủ DNS tiếp nhận thông tin từ các máy chủ DNS khác trên Internet. Khi một phần mềm DNS không biết địa chỉ số IP của một máy tính, nó sẽ truy vấn tới các máy chủ DNS khác. Với cách “tấn công đầu độc bộ nhớ cache DNS”, kẻ tấn công có thể lừa phần mềm hệ thống DNS tin rằng đó là một tên miền hợp pháp, như idg.com, cho các địa chỉ IP cài mã độc.

Trong kịch bản tấn công của Kaminsky, nỗ lực đầu độc bộ nhớ cache còn bao gồm dữ liệu “Bản ghi tài nguyên bổ sung” (Additional Resource Record). Bằng cách thêm vào dữ liệu này, việc tấn công sẽ trở nên dữ dội hơn rất nhiều, các chuyên gia bảo mật cho biết. Liu nói “Việc kết hợp chúng khá kinh khủng”.

Một kẻ tấn công có thể tấn công các máy chủ tên miền của một nhà cung cấp dịch vụ Internet và sau đó chuyển hướng chúng tới các máy chủ độc khác. Bằng cách đầu độc bản ghi tên miền cho, ví dụ, , kẻ tấn công có thể chuyển người sử dụng của nhà cung cấp dịch vụ Internet đó tới một máy chủ độc mỗi khi họ cố gắng truy cập trang web ngân hàng này.

Kaminsky từ chối xác nhận rằng Flake đã khám phá ra vấn đề của ông, nhưng trong một bài viết trên website của mình, ông đã viết “13>0”, có lẽ hàm ý rằng các nhà quản lý đã phải vá lỗi này 13 ngày trước khi nó được công bố rộng rãi còn hơn là không có ngày nào cả.

“Vá lỗi. Hôm nay. Bây giờ. Vâng, vẫn chậm!” ông viết.

Trên website của mình, Kaminsky đã đưa lên một công cụ kiểm tra cho phép mọi người cũng có thể biết liệu phần mềm DNS hệ thống của họ có bị sửa hay không.
Theo - VietNamNet (PC World)