| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 01:09:50 (+0700) | #31 | 143484 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
hì, thông tin trả về không chính xác đơn giản vì traffic DNS đi ra ngoài gặp phải NAT device, làm thay đổi thông tin source port mà thôi.
nếu bồ nào sử dụng DNS của VDC, sẽ thấy là mặc dù public DNS là 203.162.4.190 và 203.162.4.191, nhưng khi đi ra ngoài, đám DNS này sẽ lấy IP nằm trong dãy 203.162.4.195-199 và source port luôn thay đổi (tui đoán là đứng sau đám DNS này là một con Cisco PIX làm dynamic NAT).
thành ra nếu cái cách của tôi trả về kết quả sai, thì cái cách của đám bkis cũng không thể nào đoán đúng được, bởi lẽ nguyên tắc kiểm tra của hai bên là như nhau.
nếu như DNS resolver bồ muốn kiểm tra, đã tự động forward query đến một nhóm DNS resolver khác, mà không tự đi tìm câu trả lời, thì việc bồ có an toàn hay không là phụ thuộc vào tình trạng DNS resolver mà bồ forward đến, do đó cái cách của tôi mới trả về kết quả chính xác.
còn với cách của bkis, dẫu DNS resolver được kiểm tra an toàn, nhưng do nó forward đến DNS resolver không an toàn, thảnh ra cuối cùng nếu DNS resolver này bị đầu độc, thì người dùng cũng sẽ bị ảnh hưởng.
--m
|
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
 |
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 02:08:30 (+0700) | #32 | 143492 |
hoanghono
Member
![[Minus]](/hvaonline/templates/viet/images/minus.gif "[Minus]") |
0 |
![[Plus]](/hvaonline/templates/viet/images/plus.gif "[Plus]")
|
|
Joined: 28/06/2008 01:48:13
Messages: 6
Offline
|
|
mrro wrote:
hì, thông tin trả về không chính xác đơn giản vì traffic DNS đi ra ngoài gặp phải NAT device, làm thay đổi thông tin source port mà thôi.
Con DNS tui test ở trên, địa chỉ 203.162.X.X của VDC, chẳng qua cái NAT nào cả, nhưng report về từ porttest.dns-oarc.net lại dành cho con DNS Server của VNNIC (203.119.8.X) ==> chắc chắn cách của Mrro không xài được !
mrro wrote:
thành ra nếu cái cách của tôi trả về kết quả sai, thì cái cách của đám bkis cũng không thể nào đoán đúng được, bởi lẽ nguyên tắc kiểm tra của hai bên là như nhau.
nếu như DNS resolver bồ muốn kiểm tra, đã tự động forward query đến một nhóm DNS resolver khác, mà không tự đi tìm câu trả lời, thì việc bồ có an toàn hay không là phụ thuộc vào tình trạng DNS resolver mà bồ forward đến, do đó cái cách của tôi mới trả về kết quả chính xác.
còn với cách của bkis, dẫu DNS resolver được kiểm tra an toàn, nhưng do nó forward đến DNS resolver không an toàn, thảnh ra cuối cùng nếu DNS resolver này bị đầu độc, thì người dùng cũng sẽ bị ảnh hưởng.
--m
Cái này Mrro sai nữa rồi. Minh họa thế này cho đơn giản nhé: giả sử chuỗi các DNS Resolver (dùng forwarder) như sau: A -> B -> C
Mrro nói là việc kiểm tra A, B là không cần thiết vì đều phụ thuộc và C, và nếu C không an toàn thì A, B cũng bị ảnh hưởng. Cái này đúng 1 phần. Đồng ý là C bị đầu độc thì kết quả A, B trả về đều đã là kết quả giả mạo.
Nhưng nếu A, B chưa được vá, và bị tấn công, bị đầu độc ? lúc này, toàn bộ client dùng A, B đều bị ảnh hưởng (client dùng C thì ok, không sao, do C đã được vá)
Tóm lại, việc check tất cả các DNS Server đều *rất* quan trọng. Chỉ cần 1 con DNS Server bị lỗi, thì tất cả những client nào dùng DNS Server lỗi này đều bị ảnh hưởng. (hình dung như cái cây, chỉ cần 1 node bị lỗi thì tất cả các nốt của cây con của node này đều bị ảnh hưởng) ==> cần kiểm tra cho tất cả các node của cây (tất cả các DNS Server), tức là việc kiểm tra từng node rất quan trọng và cách làm của BKIS đáp ứng được điều này: cho phép kiểm tra từng con DNS Server cụ thể.
Bản thân trong post của Mrro cũng giới thiệu cách, với mục tiêu ban đầu, là để check con DNS Server của chính người muốn test, nhưng cách của Mrro hướng dẫn đã không cho phép làm được điều này. Và trong post này, Mrro lại nói là việc test con DNS Server mà mình muốn là không cần thiết ???
Để chống lỗ hổng và cách khai thác mà Dan đã trình bày, điều tối quan trọng là tất cả các DNS Server trên Internet đều cần được vá.
|
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 02:29:03 (+0700) | #33 | 143496 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
hoanghono wrote:
Con DNS tui test ở trên, địa chỉ 203.162.X.X của VDC, chẳng qua cái NAT nào cả, nhưng report về từ porttest.dns-oarc.net lại dành cho con DNS Server của VNNIC (203.119.8.X) ==> chắc chắn cách của Mrro không xài được !
Hì, bồ thử nghĩ xem, nếu không phải do NAT, hoặc không phải do con 203.162.x.x của bồ forward đến server của VNNIC thì thằng porttest.dns-oarc.net lấy dữ liệu ở đâu?
Nếu không qua cái NAT nào cả, thì chắc chắn là cấu hình con DNS của bồ đã forward các recursive query đến con server của VNNIC.
Tôi không kết luận chắc chắn nguyên nhân là đâu, nhưng thể nào thì nó cũng gói gọn trong những nguyên nhân mà tôi đưa ra.
hoanghono wrote:
Cái này Mrro sai nữa rồi. Minh họa thế này cho đơn giản nhé: giả sử chuỗi các DNS Resolver (dùng forwarder) như sau: A -> B -> C
Mrro nói là việc kiểm tra A, B là không cần thiết vì đều phụ thuộc và C, và nếu C không an toàn thì A, B cũng bị ảnh hưởng. Cái này đúng 1 phần. Đồng ý là C bị đầu độc thì kết quả A, B trả về đều đã là kết quả giả mạo.
Nhưng nếu A, B chưa được vá, và bị tấn công, bị đầu độc ? lúc này, toàn bộ client dùng A, B đều bị ảnh hưởng (client dùng C thì ok, không sao, do C đã được vá)
Tóm lại, việc check tất cả các DNS Server đều *rất* quan trọng. Chỉ cần 1 con DNS Server bị lỗi, thì tất cả những client nào dùng DNS Server lỗi này đều bị ảnh hưởng. (hình dung như cái cây, chỉ cần 1 node bị lỗi thì tất cả các nốt của cây con của node này đều bị ảnh hưởng) ==> cần kiểm tra cho tất cả các node của cây (tất cả các DNS Server), tức là việc kiểm tra từng node rất quan trọng và cách làm của BKIS đáp ứng được điều này: cho phép kiểm tra từng con DNS Server cụ thể.
Bản thân trong post của Mrro cũng giới thiệu cách, với mục tiêu ban đầu, là để check con DNS Server của chính người muốn test, nhưng cách của Mrro hướng dẫn đã không cho phép làm được điều này. Và trong post này, Mrro lại nói là việc test con DNS Server mà mình muốn là không cần thiết ???
Để chống lỗ hổng và cách khai thác mà Dan đã trình bày, điều tối quan trọng là tất cả các DNS Server trên Internet đều cần được vá.
bồ thử trả lời cho tôi 02 câu hỏi:
1. làm sao tấn công được DNS resolver A và B nếu như hai con này đều forward tất cả recursive query đến con C?
2. nếu con DNS resolver A và B forward đến là con C, nằm ngoài sự kiểm soát của sysadmin (như trường hợp của bồ) thì cái tool của bkis có giúp được gì hay không?
nhớ trả lời hai câu hỏi này nhé, đừng có đánh trống lãng. nếu bồ không trả lời được thì tôi nghĩ chẳng còn gì để tranh luận ở đây nữa.
cái cách tôi đưa ra, để check những con DNS resolver mà chấp nhận recursive query, chứ không phải để check những con DNS forwarder. Việc check những con DNS forwarder là thừa thãi, không cần thiết (cho đến khi nào chúng vẫn chỉ là forwarder), bởi lẽ dẫu chúng có an toàn mà những con recursive chúng forward đến không an toàn thì cũng như không.
cách làm của bkis sẽ dẫn đến tình trạng: sysadmin kiểm tra DNS forwarder của họ, thấy là nó đã an toàn. nhưng không kiểm tra được (do không thể thay đổi được cấu hình) những con DNS recursive resolver mà con DNS forwarder của họ này forward đến. dẫn đến trình trạng họ nghĩ là họ an toàn nhưng rốt cuộc thì không.
cái câu kết luận cuối cùng cho thấy mức độ thấu hiểu của bồ về vấn đề này như thế nào. không phải tất cả DNS server đều phải vá lỗi, mà chỉ những con recursive DNS resolver mới cần phải vá.
Cập nhật: nói lại cho rõ, cái định nghĩa về *dns forwarder* của tôi nó hơi khác so với những định nghĩ thông thường. dẫu vậy nếu ai đọc theo logic của tôi thì sẽ hiểu ý tôi muốn nói *dns forwarder* là gì.
nếu sửa lại cho chính xác, thì C sẽ được gọi là DNS forwarder, còn A và B chỉ là DNS cache, không chấp nhập recursive query mà sử dụng C để resolve name <--> IP. Nên nếu cần phải patch, thì phải patch C, A và B có thể không cần patch.
--m |
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 02:57:38 (+0700) | #34 | 143506 |
val3ntjn3
Member
|
|
0 |
|
|
Joined: 17/07/2008 12:39:10
Messages: 3
Offline
|
|
mrro wrote:
cái câu kết luận cuối cùng cho thấy mức độ thấu hiểu của bồ về vấn đề này như thế nào. không phải tất cả DNS server đều phải vá lỗi, mà chỉ những con recursive DNS resolver mới cần phải vá.
--m
Người không thấu hiểu DNS theo tôi chính là mrro đấy.
Bạn không hiểu hết về hoạt động của DNS sao? Nếu một tên miền không phải do mình quản lý DNS Server nào chả cần phải đi hỏi một DNS khác, lúc đó thì nó sẽ trở thành forwarder. Như vậy không thể nói bất kì Server nào forwarder cũng không phải là resolver.
Bạn query một tên miền nào đó với một DNS resolver (DNS A), nó không biết, lúc đấy nó sẽ phải đi hỏi một DNS khác (DNS B), như vậy bạn kết luận luôn là A thì không cần vá, B phải vá ? như vậy thật nực cười.
Mình cũng thấy buồn cười với suy nghĩ này của bạn ở một điểm nữa. Trong các bài trước, mrro hướng dẫn mọi người là dùng Open DNS để thay thế cho DNS trong nước. Thế theo bạn Open DNS chứa được tất cả tên miền trên thế giới à? Điều này là không đúng không. Như vậy với các tên miền nó không quản lý, nó sẽ phải đi hỏi các DNS khác, và nếu DNS được hỏi đấy đã bị đầu độc rồi thì Open DNS cũng không thể giúp "an toàn" cho người sử dụng được. |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 03:58:22 (+0700) | #35 | 143509 |
![[Avatar]](/hvaonline/images/avatar/089f41810321eefc3f4eef5d4a388e42.png "[Avatar]")
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
Tôi có vài nhận xét.
val3ntjn3 wrote:
mrro wrote:
cái câu kết luận cuối cùng cho thấy mức độ thấu hiểu của bồ về vấn đề này như thế nào. không phải tất cả DNS server đều phải vá lỗi, mà chỉ những con recursive DNS resolver mới cần phải vá.
--m
Người không thấu hiểu DNS theo tôi chính là mrro đấy.
Bạn không hiểu hết về hoạt động của DNS sao? Nếu một tên miền không phải do mình quản lý DNS Server nào chả cần phải đi hỏi một DNS khác, lúc đó thì nó sẽ trở thành forwarder. Như vậy không thể nói bất kì Server nào forwarder cũng không phải là resolver.
Lý giải trên bị nhập nhằng bởi vì cách ứng dụng của BIND khiến cho người dùng DNS bị lẫn lộn hoặc không rạch ròi thế nào là authoritative answer và thế nào là name resolver. Những ai dùng djbdns của Dan Bernstein mới thấy rõ điều này.
djbdns có hai phần rạch ròi:
1) tinydns: nó là phần cung cấp thông tin của DNS do mình quản lý (authoritative answer).
2) dnscache: nó là phần giải danh tên miền (ip <-> host domain resolver).
Một client A hỏi thông tin về một site B.
Client A ---> DNS trực tiếp nó được gán (ISP hoặc local caching DNS), tạm gọi là DNS A (resolver).
DNS A mới tìm xem nó đã có cache của site B chưa, nếu chưa, nó mới liên lạc với root DNS servers. Một trong các root dns servers này mới trỏ xuống các resolvers ở tầng kế tiếp (theo đúng namespace) cho đến khi nào tiếp xúc được authoritative answer, tạm gọi là AUTH A.
Nếu AUTH A cũng chính là server chạy DNS A (nếu dùng BIND) thì AUTH A trả lời cho DNS A trước khi DNS A trả lời cho client A chớ không bao giờ AUTH A trả lời trực tiếp cho client A cả.
Bởi thế, sơ đồ thế này:
Client A --> DNS A --> root DNSs --> AUTH A --> DNS A --> client A.
Và bởi thế, lý giải Nếu một tên miền không phải do mình quản lý DNS Server nào chả cần phải đi hỏi một DNS khác, lúc đó thì nó sẽ trở thành forwarder. Như vậy không thể nói bất kì Server nào forwarder cũng không phải là resolver là thiếu chính xác. Bởi vì đúng theo nguyên tắc chức năng authoriative answer và resolver không bao giờ có chuyện không thể nói bất kì Server nào forwarder cũng không phải là resolver được. Resolver chính là forwarder. Nó chưa nhận được thông tin của authoritative answerer thì nó tiếp tục forward cho đến khi nhận được answer mà thôi. Nói một cách khác, forward là một chức năng của resolver chớ không phải là 1 bộ phận tách rời.
val3ntjn3 wrote:
Bạn query một tên miền nào đó với một DNS resolver (DNS A), nó không biết, lúc đấy nó sẽ phải đi hỏi một DNS khác (DNS B), như vậy bạn kết luận luôn là A thì không cần vá, B phải vá ? như vậy thật nực cười.
Nói một cách chính xác hơn, DNS A không phải forward hoặc "hỏi" DNS B một cách vô căn cứ hoặc vô mục đích. Để DNS A hỏi DNS B thì DNS B phải thuộc namespace nhất định và phải có delegation dựa vào namespace mà DNS A cần biết. Nếu DNS A chưa có cache (nên chưa bị poisoned) thì nó không cần phải vá bởi vì chính bản thân nó không phải là authoritative answerer mà nó chỉ đóng vai trò resolver mà thôi. Nó chỉ có thể hỏi delegator (DNS B) sau khi một trong các root DNSs trỏ DNS A đến DNS B mà hỏi.
DNS A là most inner (gần client A nhất) thì đòi hỏi được patch ít nhất. DNS Z (xa client A hơn nữa và đã phải hỏi nhiều delegators) thì cần được patch nhiều hơn.
Nếu đường đi từ client A đến AUTH A chỉ có DNS A đứng giữa thì không có cái gì cần patch cả bởi vì không có cái gì xen vào để.... đầu độc hết.
Nếu đường đi từ client A đến AUTH A phải xuyên qua DNS A, DNS B, DNS C thì cơ hội DNS C có cache bị đầu độc sẵn cao hơn DNS A và DNS B vì DNS A và DNS B không có cache mới hỏi.
Nói tóm lại, lý giải của mrro không phải là nực cười và vô lý mà thiếu phân tích sâu hơn mà thôi.
val3ntjn3 wrote:
Mình cũng thấy buồn cười với suy nghĩ này của bạn ở một điểm nữa. Trong các bài trước, mrro hướng dẫn mọi người là dùng Open DNS để thay thế cho DNS trong nước. Thế theo bạn Open DNS chứa được tất cả tên miền trên thế giới à? Điều này là không đúng không. Như vậy với các tên miền nó không quản lý, nó sẽ phải đi hỏi các DNS khác, và nếu DNS được hỏi đấy đã bị đầu độc rồi thì Open DNS cũng không thể giúp "an toàn" cho người sử dụng được.
Bồ nói thế này mà không thử tìm hiểu OpenDNS trước khi phát biểu thì kẹt đấy. Nên tự tìm hiểu nhiều hơn về Open DNS trước khi phản bác (và buồn cười) về nó.
1) Open DNS là hệ thống có bộ cache cực lớn. Chứa hết tất cả các tên miền trên thế giới thì có lẽ không nhưng tên miền mà các clients truy cập đến openDNS để "hỏi" từ trước thì đều đã cache cả.
2) Open DNS sử dụng giá trị TTL ấn định từ authoritative answerer và trong chuỗi các resolvers của openDNS đã cache entries của một domain nào nếu có sự thiếu đồng bộ (đáng ngờ) thì chúng sẽ liên lạc trực tiếp với authoritative answerer để lấy thông tin mới nhất (chớ không lấy thông tin từ cache nào khác - không phải là authoritative answerer).
Bởi thế, việc mrro đề nghị dùng openDNS là an toàn thì không ngoa đâu. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 04:10:55 (+0700) | #36 | 143512 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
he he he, cái định nghĩa về *dns forwarder* của tôi nó hơi khác so với những định nghĩ thông thường. dẫu vậy nếu ai đọc theo logic của tôi thì sẽ hiểu ý tôi muốn nói *dns forwarder* là gì.
nếu sửa lại cho chính xác, thì C sẽ được gọi là DNS forwarder, còn A và B chỉ là DNS cache, không chấp nhập recursive query mà sử dụng C để resolve name <--> IP.
Bạn query một tên miền nào đó với một DNS resolver (DNS A), nó không biết, lúc đấy nó sẽ phải đi hỏi một DNS khác (DNS B), như vậy bạn kết luận luôn là A thì không cần vá, B phải vá ? như vậy thật nực cười.
Có hai cách hỏi lận bồ ơi, một cách (non-recursive) là nó chỉ quăng câu hỏi cho thằng B, rồi thằng B sẽ làm cách nào đó để có câu trả lời, và trả kết quả lại cho thằng A. Trong cách hỏi này, thằng A sẽ chẳng cần phải patch (bởi nó không thực hiện recursive query).
Cách thứ hai là thằng A sẽ tự đi hỏi. Lúc đó thằng B có thể là root dns server, hay là authorative dns server chịu trách nhiệm quản lý cái domain mà client đang hỏi. Trong cách hỏi này, thằng A sẽ phải bị patch (bởi nó thực hiện recursive query).
Mình cũng thấy buồn cười với suy nghĩ này của bạn ở một điểm nữa. Trong các bài trước, mrro hướng dẫn mọi người là dùng Open DNS để thay thế cho DNS trong nước. Thế theo bạn Open DNS chứa được tất cả tên miền trên thế giới à? Điều này là không đúng không. Như vậy với các tên miền nó không quản lý, nó sẽ phải đi hỏi các DNS khác, và nếu DNS được hỏi đấy đã bị đầu độc rồi thì Open DNS cũng không thể giúp "an toàn" cho người sử dụng được.
Bồ buồn cười thì cứ cười cho đã rồi đọc những gì tôi viết ở đây. OpenDNS là máy chủ open DNS recursive resolver, nó sẽ có trách nhiệm đi hỏi những authorative DNS server về những tên miền mà client hỏi nó. Nó đã được vá lỗi và nó chỉ hỏi authorative DNS servers (which are immutable to this type of attack) nên sử dụng nó là an toàn.
Tôi nghĩ bồ nên tìm một cuốn DNS for dummies nào đó về đọc rồi hãy quay lên tranh luận tiếp.
--m
|
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 04:41:28 (+0700) | #37 | 143519 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
Để tôi tổng kết lại những tình huống mà cái tool của bkis sẽ làm sai, false negative hay false positive:
1. client --> A --> B --> Authorative DNS servers
* A là dns cache thuộc quyền kiểm soát của sysadmin, được cấu hình để forward recursive query đến B, một dns cache nằm ngoài tầm của sysadmin.
* false negative sẽ xảy ra khi A đã vá, nhưng B chưa vá. Công cụ của bkis sẽ báo là an toàn, nhưng thực tế tất cả client sử dụng A đều đứng trước nguy cơ bị tấn công.
* false positive sẽ xảy ra khi A không vá, nhưng B đã vá. Công cụ của bkis sẽ báo là không an toàn, yêu cầu vá (không phải lúc nào cũng muốn vá là vá :-p), nhưng thực tế tất cả client sử dụng A đều an toàn trước loại tấn công này.
Trong cả hai trường hợp, cách làm của tôi đưa ra đều thông báo chính xác là bạn có đang an toàn hay không an toàn (lưu ý là nó quan tâm đến người sử dụng, bất kể DNS có được vá hay chưa vá). Và nó áp dụng được cả cho người dùng bình thường lẫn sysadmin.
2. client --> A --> NAT device --> Authorative DNS servers
* A là dns cache thuộc quyền kiểm soát của sysadmin, được cấu hình chấp nhận recursive query từ client.
* phía sau A (trước khi ra Internet) là một thiết bị NAT, làm thay đổi dest IP hoặc source port của các packet đi ra từ A
* false negative sẽ xảy ra khi A không vá, nghĩa là dùng fixed source port, nhưng khi đi ra đến NAT device, NAT device lại thay đổi source port, làm cho nó ngẫu nhiên, nên tool của bkis sẽ báo là an toàn.
tuy gọi là false negative nhưng NAT device trong trường hợp này lại vô tình bảo vệ cái lỗ hổng của A, làm cho việc khai thác trở nên rất khó.
* false postivie sẽ xảy ra khi A đã vá, nghĩa là source port đã được randomized, nhưng khi đi ra đến NAT device, NAT device lại thay đổi source port, làm cho nó hết ngẫu nhiên, nên tool của bkis sẽ báo là không an toàn.
tuy gọi là false postive, nhưng NAT device trong trường hợp này lại vô tình làm cho việc A có vá hay không vá trở nên vô nghĩa.
trong hai trường hợp này, cái cách làm của tôi cho kết quả giống với cách làm của bkis.
tóm gọn lại: có ai cần một phần mềm trả về kết quả sai (và phải cấu hình lung tung mới dùng được, và chỉ dành cho sysadmin :-p), trong khi chỉ cần gõ một lệnh là được kết quả chính xác hơn, ngay cả người dùng bt cũng có thể kiểm tra được?
--m |
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 05:16:13 (+0700) | #38 | 143527 |
boom_jt
Member
|
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
Hic mọi người viết dài quá làm boom đọc đến mệt. Nhờ bác conmale mà boom hiểu là thằng OpenDNS nó hay vậy  ngoài việc đc fix lỗi, nó chỉ hỏi authorative chứ ko hỏi thằng trung gian -> tránh được việc bị thằng trung gian đã dính chưởng "lây nhiễm" .
Đến gần cuối thì boom lười đọc  lướt lướt thôi ^^ mà lướt được câu này thấy có vẻ ko đúng lắm nè:
mrro wrote:
false postivie sẽ xảy ra khi A đã vá, nghĩa là source port đã được randomized, nhưng khi đi ra đến NAT device, NAT device lại thay đổi source port, làm cho nó hết ngẫu nhiên, nên tool của bkis sẽ báo là không an toàn.
đâu chắc là qua NAT nó hết ngẫu nhiên? Cái Nat device nó cũng kiếm 1 cổng ngẫu nhiên chưa dùng thì sao nè Trường hợp đi qua NAT này thì có vẻ làm rắc rối câu chuyện, nhưng cũng vô tình làm cho việc khai thác lỗi là khó như mrro đã nói ^^
Còn việc kiểm tra đích danh 1 DNS server là cần thiết đó chớ: "tôi là admin!  tôi cần fix lỗi để ăn ngon ngủ yên, hãy cho tôi biết DNS server của tôi có dính lỗi ko ?"
1 số điểm boom thấy chưa ổn lắm, nhưng từ từ để boom kiếm tài liệu đọc lại đã, chắc chắn rồi thì sẽ phát biểu |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 06:50:06 (+0700) | #39 | 143530 |
hoanghono
Member
|
|
0 |
|
|
Joined: 28/06/2008 01:48:13
Messages: 6
Offline
|
|
Tui nghĩ Mrro đã hiểu sai mục đích của công cụ của BKIS rồi.
Theo tui hiểu, công cụ của BKIS dùng để check xem máy chủ DNS cụ thể nào đó đã được vá hay chưa (vá rồi nghĩa là đã hạn chế được kiểu tấn công bộ đệm DNS mới phát hiện), và máy chủ đó là an toàn hay không đối với kiểu tấn công mới từ Internet.
mrro wrote:
Để tôi tổng kết lại những tình huống mà cái tool của bkis sẽ làm sai, false negative hay false positive:
1. client --> A --> B --> Authorative DNS servers
* A là dns cache thuộc quyền kiểm soát của sysadmin, được cấu hình để forward recursive query đến B, một dns cache nằm ngoài tầm của sysadmin.
* false negative sẽ xảy ra khi A đã vá, nhưng B chưa vá. Công cụ của bkis sẽ báo là an toàn, nhưng thực tế tất cả client sử dụng A đều đứng trước nguy cơ bị tấn công.
Cái này không phải tool của BKIS sai, vì tool của BKIS chỉ check xem máy A đã vá hay chưa. Còn việc A đã vá rồi, mà nghe trả lời sai của B để client của A bị ảnh hưởng là 1 chuyện khác.
mrro wrote:
* false positive sẽ xảy ra khi A không vá, nhưng B đã vá. Công cụ của bkis sẽ báo là không an toàn, yêu cầu vá (không phải lúc nào cũng muốn vá là vá :-p), nhưng thực tế tất cả client sử dụng A đều an toàn trước loại tấn công này.
Mrro không hiểu rõ bản chất của kiểu tấn công này rồi. Mrro chỉ cho tui xem chỗ nào nói là trường hợp DNS Server A forward hết các query cho B thì A sẽ không bị tấn công theo kiểu này?
Cứ là caching DNS Server chưa vá thì đều có khả năng bị tấn công DNS cache poisoning theo kiểu mới này.
Minh họa thế này cho dễ hiểu nhé, hacker biết A sẽ phải đi hỏi B, hacker hỏi A hàng triệu tên miền giả, và gửi hàng triệu trả lời giả mạo B cho A. Nếu A có dùng cache, thì chỉ cần 1 lần trả lời giả mạo trúng, thì A sẽ bị lừa (đầu độc). Và lúc này là client của A bị ảnh hưởng (không còn an toàn như Mrro nói)
mrro wrote:
Trong cả hai trường hợp, cách làm của tôi đưa ra đều thông báo chính xác là bạn có đang an toàn hay không an toàn (lưu ý là nó quan tâm đến người sử dụng, bất kể DNS có được vá hay chưa vá). Và nó áp dụng được cả cho người dùng bình thường lẫn sysadmin.
Kết luận này sai theo phân tích bên trên. Điều quan trọng là cần kiểm tra xem DNS Server của tui có bị hổng hay không theo lỗi này. Vì nếu DNS server của tui thuộc loại caching, thì ngay cả tui forward toàn bộ query đi cho DNS Server khác, thì DNS Server của tui nếu chưa vá vẫn có nguy cơ bị tấn công DNS Caching Poisoning. Và nếu bị tấn công thì client của tui sẽ bị ảnh hưởng.
mrro wrote:
2. client --> A --> NAT device --> Authorative DNS servers
* A là dns cache thuộc quyền kiểm soát của sysadmin, được cấu hình chấp nhận recursive query từ client.
* phía sau A (trước khi ra Internet) là một thiết bị NAT, làm thay đổi dest IP hoặc source port của các packet đi ra từ A
* false negative sẽ xảy ra khi A không vá, nghĩa là dùng fixed source port, nhưng khi đi ra đến NAT device, NAT device lại thay đổi source port, làm cho nó ngẫu nhiên, nên tool của bkis sẽ báo là an toàn.
tuy gọi là false negative nhưng NAT device trong trường hợp này lại vô tình bảo vệ cái lỗ hổng của A, làm cho việc khai thác trở nên rất khó.
* false postivie sẽ xảy ra khi A đã vá, nghĩa là source port đã được randomized, nhưng khi đi ra đến NAT device, NAT device lại thay đổi source port, làm cho nó hết ngẫu nhiên, nên tool của bkis sẽ báo là không an toàn.
tuy gọi là false postive, nhưng NAT device trong trường hợp này lại vô tình làm cho việc A có vá hay không vá trở nên vô nghĩa.
trong hai trường hợp này, cái cách làm của tôi cho kết quả giống với cách làm của bkis.
Như tui đã nói, tool của BKIS giúp check xem DNS Server cụ thể nào đó có còn lỗ hổng này hay không, có an toàn với kiểu tấn công mới từ Internet. Như trong phân tích và xác nhận bên trên của Mrro, thì nguy cơ đối với DNS Server sau NAT cũng sẽ được tool của BKIS xác định chính xác. Như vậy, tool của BKIS là hữu dụng và chính xác ngay cả trong trường hợp bị NAT.
Ngoài ra, đoạn bôi đỏ trên không hiểu tại sao Mrro nói "làm thay đổi dest IP"? hiểu nhầm hay viết nhầm?
mrro wrote:
tóm gọn lại: có ai cần một phần mềm trả về kết quả sai (và phải cấu hình lung tung mới dùng được, và chỉ dành cho sysadmin :-p), trong khi chỉ cần gõ một lệnh là được kết quả chính xác hơn, ngay cả người dùng bt cũng có thể kiểm tra được?
--m
Nói tóm lại là Mrro không ưa BKIS và chưa hiểu hết vấn đề, nên mới có những nhận định chưa chính xác như trên.
PS: chưa kể là Mrro còn hiểu sai khái niệm "false negative" và "false postive". Mrro cần đọc thêm wiki về khái niệm này nhé.
mrro wrote:
* false negative sẽ xảy ra khi A đã vá, nhưng B chưa vá. Công cụ của bkis sẽ báo là an toàn, nhưng thực tế tất cả client sử dụng A đều đứng trước nguy cơ bị tấn công.
Khái niệm này hiểu đúng phải như sau:
Khi kiểm tra 1 hệ thống có an toàn hay không, nếu kết quả báo là an toàn, mà thực tế là không, thì gọi là "false positive" chứ không phải gọi là "false negative".
Tất cả các chỗ dùng "false negative" và "false postive" khác của Mrro cũng đều nhầm lẫn khái niệm.
|
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 07:42:43 (+0700) | #40 | 143538 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
boom_jt: bồ àh, tôi đưa ra trường hợp đó, ý nói là trong những trường hợp mà NAT device chọn một fixed source port (hoặc là một range nhỏ source port), thì sẽ dẫn đến những sai lầm trong nhận định. Đây là trường hợp đã xảy ra trong thực tế. Tự nhiên bồ lại dẫn ra một trường hợp khác để nói là sao? Có nhiều trường hợp có thể xảy ra, trường hợp của tôi đưa ra và của bồ đưa ra đều có khả năng xảy ra, điều quan trọng là ở chỗ đó.
Không hiểu là bồ có hiểu bồ đang nói về cái gì và tôi đang nói về cái gì không? Nếu chưa hiểu thì làm ơn đọc lại cho kỹ rồi hãy tham gia tranh luận, nhé.
--m |
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 07:58:23 (+0700) | #41 | 143542 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
hoanghono wrote:
Theo tui hiểu, công cụ của BKIS dùng để check xem máy chủ DNS cụ thể nào đó đã được vá hay chưa (vá rồi nghĩa là đã hạn chế được kiểu tấn công bộ đệm DNS mới phát hiện), và máy chủ đó là an toàn hay không đối với kiểu tấn công mới từ Internet.
Haha thế tôi mới nói là bkis đã làm chuyện vô ích. tự vì kiểm tra là phải kiểm tra xem có người sử dụng sử dụng dịch vụ của máy chủ DNS có an toàn hay không, còn việc vá hay không vá là việc tính sau.
Tôi đã chỉ ra những trường hợp, dẫu vá hay không vá, thì người sử dụng vẫn có khả năng bị tấn công, thế thì mục đích kiểm tra có vá hay không ở đây là để làm gì? Hay là cứ có lỗi thì vá, mặc kệ nguyên nhân chính xác cần phải khắc phục là gì?
Mrro không hiểu rõ bản chất của kiểu tấn công này rồi. Mrro chỉ cho tui xem chỗ nào nói là trường hợp DNS Server A forward hết các query cho B thì A sẽ không bị tấn công theo kiểu này?
Cứ là caching DNS Server chưa vá thì đều có khả năng bị tấn công DNS cache poisoning theo kiểu mới này.
Minh họa thế này cho dễ hiểu nhé, hacker biết A sẽ phải đi hỏi B, hacker hỏi A hàng triệu tên miền giả, và gửi hàng triệu trả lời giả mạo B cho A. Nếu A có dùng cache, thì chỉ cần 1 lần trả lời giả mạo trúng, thì A sẽ bị lừa (đầu độc). Và lúc này là client của A bị ảnh hưởng (không còn an toàn như Mrro nói)
Tôi coi đây là câu trả lời của bồ cho câu hỏi số 1 của tôi ở trên. Thế bồ cho tôi biết làm sao hacker biết được source port trong query mà A gửi cho B, để gửi gói tin giả mạo?
Như tui đã nói, tool của BKIS giúp check xem DNS Server cụ thể nào đó có còn lỗ hổng này hay không, có an toàn với kiểu tấn công mới từ Internet. Như trong phân tích và xác nhận bên trên của Mrro, thì nguy cơ đối với DNS Server sau NAT cũng sẽ được tool của BKIS xác định chính xác. Như vậy, tool của BKIS là hữu dụng và chính xác ngay cả trong trường hợp bị NAT.
Ngoài ra, đoạn bôi đỏ trên không hiểu tại sao Mrro nói "làm thay đổi dest IP"? hiểu nhầm hay viết nhầm?
Hehe tôi viết nhầm, lẽ ra phải là src IP. Còn trường hợp có NAT hay không NAT, tôi đã liệt kê ra những sai lầm có thể có trong nhận định nếu dựa vào công cụ của bkis (cách của tôi cũng có thể gây ra những sai lầm này).
Khi kiểm tra 1 hệ thống có an toàn hay không, nếu kết quả báo là an toàn, mà thực tế là không, thì gọi là "false positive" chứ không phải gọi là "false negative".
Haha thế thì nó là định nghĩa của bồ. Bồ hiểu chữ "positive" ở đây nghĩa là gì? Haha về cái này, tôi nghĩ tôi chẳng cần phải đọc tài liệu lại đâu. Bồ nghĩ tôi viết sai thì cứ nghĩ, kô có vấn đề gì cả.
Thực tế tôi chưa bao giờ phải vừa tranh luận vừa đọc tài liệu làm gì, bởi nếu tôi không rõ về một đề tài nào đó, tôi đã không tranh luận rồi.
--m |
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 08:15:24 (+0700) | #42 | 143549 |
boom_jt
Member
|
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
mrro nè, bồ có thể đọc kĩ lại câu nói của bồ mà tôi đã quote đi, nó mang tính khẳng định cao lắm, cho nên tôi mới góp ý vậy á. Có chỗ nào chưa hợp lý thì ta tranh luận, có gì đâu mà bồ phải phản ứng thế. Mrro cũng thừa hiểu là tôi nói đâu có sai. Mà thấy bồ có vẻ khinh thường người khác quá, dùng những lời lẽ...
Tôi cũng không muốn nói thêm nhiều kẻo lại bị cảnh cáo  |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 08:23:13 (+0700) | #43 | 143553 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
@boom_jt: hì, nếu bồ đọc lại toàn bộ bài viết đó của tôi, thì bồ sẽ thấy tôi đang liệt kê ra các trường hợp có thể gây ra lỗi. ngay trước đó, tôi có liệt kê ra một trường hợp ngược lại hoàn toàn, nghĩa là source port không randomized, nhưng đi ra bị NAT device làm cho randomized. Nếu bồ đọc kỹ và thật sự hiểu những gì tôi nói, chứ không phải kiểu bắt bẻ mà không có lập luận, thì bồ đã thấy tôi không hề có ý khẳng định (kiểu như hễ đi ra đến NAT device là source port sẽ không đổi), mà chỉ là đang đưa ra những trường hợp có thể có mà thôi.
Bồ xem cái đoạn màu xanh dưới đây có phải là ý của bồ không?
2. client --> A --> NAT device --> Authorative DNS servers
* A là dns cache thuộc quyền kiểm soát của sysadmin, được cấu hình chấp nhận recursive query từ client.
* phía sau A (trước khi ra Internet) là một thiết bị NAT, làm thay đổi dest IP hoặc source port của các packet đi ra từ A
* false negative sẽ xảy ra khi A không vá, nghĩa là dùng fixed source port, nhưng khi đi ra đến NAT device, NAT device lại thay đổi source port, làm cho nó ngẫu nhiên, nên tool của bkis sẽ báo là an toàn.
tuy gọi là false negative nhưng NAT device trong trường hợp này lại vô tình bảo vệ cái lỗ hổng của A, làm cho việc khai thác trở nên rất khó.
* false postivie sẽ xảy ra khi A đã vá, nghĩa là source port đã được randomized, nhưng khi đi ra đến NAT device, NAT device lại thay đổi source port, làm cho nó hết ngẫu nhiên, nên tool của bkis sẽ báo là không an toàn.
tuy gọi là false postive, nhưng NAT device trong trường hợp này lại vô tình làm cho việc A có vá hay không vá trở nên vô nghĩa.
tôi có phản ứng với bồ vì tôi không thích những người không hiểu những gì mình đang nói và không đọc kỹ những gì người ta viết nhưng lại thích đi bắt bẻ người khác. nếu là tôi, tôi sẽ cảm thấy rất xấu hổ, bởi mình đang làm mất thời gian của người khác một cách rất vô duyên, hơn là tự ái vì người khác nói mình kô hiểu vấn đề và kô đọc kỹ (trong khi sự thật là vậy).
--m |
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 08:35:48 (+0700) | #44 | 143557 |
FaL
Moderator
|
Joined: 14/04/2006 09:31:18
Messages: 1232
Offline
|
|
[thời sự]
Bản tin thời sự VTV vừa đưa tin về lỗi này với cảnh báo của VNCert và phát biểu của đại diện VDC
[/thời sự]
|
|
| Hãy giữ một trái tim nóng và một cái đầu lạnh |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 08:48:49 (+0700) | #45 | 143560 |
boom_jt
Member
|
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
@mrro: nghe nè, tôi ko hề và cũng chẳng có lý do gì để phải tự ái và xấu hổ vì những lời nói của bồ, và đề nghị bồ cũng bỏ kiểu nói khích bác người khác đi, hãy nói chuyện với nhau thẳng thắn. 1 chủ đề hay như thế do chính bồ tạo nên cũng không nên bị nhiễu bởi những lời vào ra không đáng có.
Là người nghiên cứu thì trong những bài mang tính tranh luận cao như vậy, hãy cố để làm bài viết của mình sáng tỏ và ít gây tranh cãi. Đằng này chỉ có 1 chút vậy mà bồ đã dựng ngược lên rồi. Còn câu nói này của bồ thì tôi thật sự ngạc nhiên đó:
mrro wrote:
tự vì kiểm tra là phải kiểm tra xem có người sử dụng sử dụng dịch vụ của máy chủ DNS có an toàn hay không, còn việc vá hay không vá là việc tính sau.
Xin hỏi bồ nếu vậy khi đã xác định người sử dụng dịch vụ của máy chủ DNS của bồ là không an toàn rồi thì bồ làm sao?
Boom cũng có điều đang chưa rõ, là theo hoanghono thì tool bkis có thể đúng ngay cả trong trường hợp bị NAT, vậy nguyên lý hoạt động của nó có thể là gì? (nói nhỏ @mrro: 1 vấn đề ko biết thì hỏi, chẳng có gì là đáng xấu hổ cả). |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 09:06:51 (+0700) | #46 | 143562 |
hoanghono
Member
|
|
0 |
|
|
Joined: 28/06/2008 01:48:13
Messages: 6
Offline
|
|
mrro wrote:
hoanghono wrote:
Theo tui hiểu, công cụ của BKIS dùng để check xem máy chủ DNS cụ thể nào đó đã được vá hay chưa (vá rồi nghĩa là đã hạn chế được kiểu tấn công bộ đệm DNS mới phát hiện), và máy chủ đó là an toàn hay không đối với kiểu tấn công mới từ Internet.
Haha thế tôi mới nói là bkis đã làm chuyện vô ích. tự vì kiểm tra là phải kiểm tra xem có người sử dụng sử dụng dịch vụ của máy chủ DNS có an toàn hay không, còn việc vá hay không vá là việc tính sau.
Tôi đã chỉ ra những trường hợp, dẫu vá hay không vá, thì người sử dụng vẫn có khả năng bị tấn công, thế thì mục đích kiểm tra có vá hay không ở đây là để làm gì? Hay là cứ có lỗi thì vá, mặc kệ nguyên nhân chính xác cần phải khắc phục là gì?
Tui không hiểu Mrro nói gì nữa? Nhu cầu kiểm tra từng DNS Server là có, như tui, tui cần biết xem DNS Server ở Công ty của tui có lỗ hổng không, để mà vá.
Vì tui đã nói, cứ DNS Server thuộc loại caching, không vá, thì nguy cơ bị tấn công DNS Cache Poisoning theo phương pháp mới là rất cao, bất kể nó có forward toàn bộ query đi hay nó tự đi hỏi. Điều này có nghĩa là mọi DNS Server thuộc loại có nguy cơ trên toàn Internet đều cần phải được kiểm tra và vá lỗi. Càng nhiều DNS Server được vá lỗi, thì nguy cơ đối với cộng đồng càng giảm (lại ví dụ bằng hình cái cây - đúng hơn là cái mạng lưới, quan trọng nhất là các node ở trên gốc (hay các node lớn ở mạng lưới) được vá lỗi, nhưng quan trọng không kém là tất cả các node trong cái mạng lưới to đùng đó đều được vá, nếu không, sẽ ảnh hưởng tới các client và thậm chí cả các node lân cận)
mrro wrote:
Mrro không hiểu rõ bản chất của kiểu tấn công này rồi. Mrro chỉ cho tui xem chỗ nào nói là trường hợp DNS Server A forward hết các query cho B thì A sẽ không bị tấn công theo kiểu này?
Cứ là caching DNS Server chưa vá thì đều có khả năng bị tấn công DNS cache poisoning theo kiểu mới này.
Minh họa thế này cho dễ hiểu nhé, hacker biết A sẽ phải đi hỏi B, hacker hỏi A hàng triệu tên miền giả, và gửi hàng triệu trả lời giả mạo B cho A. Nếu A có dùng cache, thì chỉ cần 1 lần trả lời giả mạo trúng, thì A sẽ bị lừa (đầu độc). Và lúc này là client của A bị ảnh hưởng (không còn an toàn như Mrro nói)
Tôi coi đây là câu trả lời của bồ cho câu hỏi số 1 của tôi ở trên. Thế bồ cho tôi biết làm sao hacker biết được source port trong query mà A gửi cho B, để gửi gói tin giả mạo?
Đúng đây là ý tui trả lời. Làm sao hacker đoán được port trong query hả?  Mrro không biết điều này vì không hiểu rõ bản chất của tấn công DNS Cache Poisoning mà Dan vừa công bố rồi.
Nói nôm na thế này cho dễ hiểu (chứ mô tả chi tiết làm thế nào thì phải hỏi Dan hoặc chờ tới ngày 6/8 tới ):
hacker cứ gửi hàng triệu query tới A, A buộc phải đi hỏi B vì các query đó là về tên miền mới, đồng thời hacker gửi hàng triệu reply giả mạo B tới A, với hi vọng chỉ cần 1 reply được A chấp nhận (trùng QID, trùng source port, trùng 1 loạt cái khác nữa) và xác suất thành công với hàng triệu yêu cầu như vậy là cao. Chính vì thế, các bản vá hiện nay, ngoài 1 loạt cải tiến, có 1 cải tiến quan trọng là cho source port random, nhằm giảm xác suất đoán trúng cổng nguồn.
mrro wrote:
Hehe tôi viết nhầm, lẽ ra phải là src IP. Còn trường hợp có NAT hay không NAT, tôi đã liệt kê ra những sai lầm có thể có trong nhận định nếu dựa vào công cụ của bkis (cách của tôi cũng có thể gây ra những sai lầm này).
làm tui đọc và suy nghĩ muốn nổ óc. Hi vọng những chỗ khác cũng chỉ là nhầm hoặc do chưa hiểu hết.
mrro wrote:
Khi kiểm tra 1 hệ thống có an toàn hay không, nếu kết quả báo là an toàn, mà thực tế là không, thì gọi là "false positive" chứ không phải gọi là "false negative".
Haha thế thì nó là định nghĩa của bồ. Bồ hiểu chữ "positive" ở đây nghĩa là gì? Haha về cái này, tôi nghĩ tôi chẳng cần phải đọc tài liệu lại đâu. Bồ nghĩ tôi viết sai thì cứ nghĩ, kô có vấn đề gì cả.
Thực tế tôi chưa bao giờ phải vừa tranh luận vừa đọc tài liệu làm gì, bởi nếu tôi không rõ về một đề tài nào đó, tôi đã không tranh luận rồi.
--m
Tui chẳng có định nghĩa của riêng mình đâu. Đó là định nghĩa của giới khoa học đó, toán học, logic học, xác suất học... đều chung 1 khái niệm như tui nói cả. Mrro cần kiểm tra lại "định nghĩa" của Mrro đi, cho nó giống thế giới. |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 09:35:54 (+0700) | #47 | 143567 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
@boom_jt: tôi ngạc nhiên với thái độ của bồ. không hiểu tôi hay là bồ đang ruin cái cuộc tranh luận này?
sao bồ không thử đọc lại, xem tôi nói có đúng hay không, xem cái bắt bẻ ban đầu của bồ nó có chính xác hay không? rồi mình hãy nói tiếp.
@hoanghono: có lẽ nên dừng tranh luận ở đây, bởi tôi nghĩ tranh luận với bồ không đem lại lợi ích gì cả.
haha một điều mà tôi cảm thấy đáng chán nhất trong đa số các cuộc tranh luận là cuối cùng chẳng ai chịu nhận mình sai. thôi thì đành phải tự sướng vậy :p.
--m |
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 10:08:13 (+0700) | #48 | 143572 |
lamer
Elite Member
|
|
0 |
|
|
Joined: 26/02/2008 13:28:49
Messages: 215
Offline
|
|
[truyện hài]
Hổm bữa mình đi test HIV (hiểm họa mà), nhận được giấy kết quả ghi là Positif (tiếng Pháp, vì viện Pasteur trong này nó nguyên là theo Pháp, dịch ra tiếng Anh là Positive). Vậy là mình đã an toàn rồi phải không các bạn?
[hết truyện hài]
[truyện hài thứ hai]
Ngày hôm qua mình có viết 1 cái chương trình vét cạn tên người dùng của một máy chủ kia. Chương trình của mình chỉ gửi vài chục bytes (cho là 100 đi cho dễ tính) qua mạng cho mỗi câu truy vấn thôi. Mình cứ ngỡ là mạng mình nhanh, có thể gửi cả triệu truy vấn trong tíc tắc được, nhưng ai dè đâu mình vét có 3 ký tự mà tốn hơn 10 phút. Cuối cùng mình phải ngắt nó giữa chừng vì không chờ nổi. Có cách nào gửi cả triệu truy vấn (hoặc trả lời giả) trong vài giây đồng hồ (để tránh timeout của UDP) không các bạn?
[hết truyện hài thứ hai] |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 10:27:05 (+0700) | #49 | 143577 |
boom_jt
Member
|
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
hì hì truyện hài vui quá khổ thế sao bác lại nhận đc cái kết quả Positif mà nếu viện Pasteur họ sai thì đúng là bác an toàn rồi  |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 13:06:25 (+0700) | #50 | 143598 |
val3ntjn3
Member
|
|
0 |
|
|
Joined: 17/07/2008 12:39:10
Messages: 3
Offline
|
|
lamer wrote:
[truyện hài thứ hai]
Ngày hôm qua mình có viết 1 cái chương trình vét cạn tên người dùng của một máy chủ kia. Chương trình của mình chỉ gửi vài chục bytes (cho là 100 đi cho dễ tính) qua mạng cho mỗi câu truy vấn thôi. Mình cứ ngỡ là mạng mình nhanh, có thể gửi cả triệu truy vấn trong tíc tắc được, nhưng ai dè đâu mình vét có 3 ký tự mà tốn hơn 10 phút. Cuối cùng mình phải ngắt nó giữa chừng vì không chờ nổi. Có cách nào gửi cả triệu truy vấn (hoặc trả lời giả) trong vài giây đồng hồ (để tránh timeout của UDP) không các bạn?
[hết truyện hài thứ hai]
[Truyện cực hài thứ ba]
Có một người cực hài hước, có chữ security ở chữ ký mà không biết rằng đã tấn công thì không cần phải chờ time out. Không biết làm thế nào để gửi nhiều truy vấn mà phải ngồi hì hụi gửi từng truy vấn 1. Đọc xong cười chảy nước mắt
[/hết truyện cực cực hài] |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 13:16:29 (+0700) | #51 | 143599 |
![[Avatar]](/hvaonline/images/avatar/3f44f3018ff71ff4a7d22a98f3babb55.png "[Avatar]")
|
quanta
Moderator
|
Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
|
|
| Chỉnh giùm mrro: Tất cả những chỗ đáng lẽ là authoritative, mrro viết nhầm thành authorative. |
|
| Let's build on a great foundation! |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch |
27/07/2008 13:33:19 (+0700) | #52 | 143603 |
![[Avatar]](/hvaonline/images/avatar/7f11b15655b2342b01a2db7edb7961cd.jpeg "[Avatar]")
|
gamma95
Researcher
|
Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline
|
|
Đúng đây là ý tui trả lời. Làm sao hacker đoán được port trong query hả? Mrro không biết điều này vì không hiểu rõ bản chất của tấn công DNS Cache Poisoning mà Dan vừa công bố rồi.
Nói nôm na thế này cho dễ hiểu (chứ mô tả chi tiết làm thế nào thì phải hỏi Dan hoặc chờ tới ngày 6/8 tới ):
hacker cứ gửi hàng triệu query tới A, A buộc phải đi hỏi B vì các query đó là về tên miền mới, đồng thời hacker gửi hàng triệu reply giả mạo B tới A, với hi vọng chỉ cần 1 reply được A chấp nhận (trùng QID, trùng source port, trùng 1 loạt cái khác nữa) và xác suất thành công với hàng triệu yêu cầu như vậy là cao. Chính vì thế, các bản vá hiện nay, ngoài 1 loạt cải tiến, có 1 cải tiến quan trọng là cho source port random, nhằm giảm xác suất đoán trúng cổng nguồn.
Trong
bồ nên tham khảo ý này của lamer:
[truyện hài thứ hai]
Ngày hôm qua mình có viết 1 cái chương trình vét cạn tên người dùng của một máy chủ kia. Chương trình của mình chỉ gửi vài chục bytes (cho là 100 đi cho dễ tính) qua mạng cho mỗi câu truy vấn thôi. Mình cứ ngỡ là mạng mình nhanh, có thể gửi cả triệu truy vấn trong tíc tắc được, nhưng ai dè đâu mình vét có 3 ký tự mà tốn hơn 10 phút. Cuối cùng mình phải ngắt nó giữa chừng vì không chờ nổi. Có cách nào gửi cả triệu truy vấn (hoặc trả lời giả) trong vài giây đồng hồ (để tránh timeout của UDP) không các bạn?
[hết truyện hài thứ hai]
Hóa ra bồ hoanghono là một người hoang tưởng. Cái chuyện DNS cache poisioning tấn công thế nào thì ai cũng biết. Nhưng phương pháp của Dan vừa công bố mới đây ko hề có chuyện đoán source port mà có vài típ+tricks để detect hẳn hoi (source port bị fixed trong các phiên bản cũ DNS). Vì suy nghĩ hoang tưởng đó của bồ (gởi vài triệu request trong thời gian UDP chưa time out) mà giờ tui mới hiểu là tại sao bồ cứ nằng nặc khẳng định rằng: BKAV DNS check vẫn đúng trong trường hợp có bị NAT (tương đương với source port bị random khi patch) .
Thôi, mọi việc đã rõ ràng rồi nhé.
|
|
Cánh chym không mỏi
lol |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 13:39:56 (+0700) | #53 | 143604 |
facialz
Elite Member
|
|
0 |
|
|
Joined: 20/07/2004 03:48:17
Messages: 197
Location: HoChiMinh city
Offline
|
|
Về positive (dương tính) và negative (âm tính).
Hai từ này mượn từ thống kê, khi xét nghiệm một giả thuyết nào đó gọi là giả thuyết null. Nếu kết quả xét nghiệm ủng hộ giả thuyết ấy thì kết quả được gọi là dương tính, còn nếu không ủng hộ thì kết quả ấy được gọi là âm tính.
Như thế nếu giả thuyết null ở đây là "hệ thống an toàn" thì kết quả dương tính nói rằng hệ thống an toàn, kết quả âm tính không ủng hộ giả thuyết này. Còn nếu giả thuyết null là "hệ thống không an toàn" thì kết quả dương tính nói rằng hệ thống không an toàn, kết quả âm tính không ủng hộ giả thuyết này.
Không tồn tại công cụ xét nghiệm nào để khẳng định một hệ thống là an toàn cả. Tất cả các công cụ xét nghiệm đều hoạt động theo hướng tìm lỗi. Nói cách khác, giả thuyết null không bao giờ là giả thuyết "hệ thống an toàn" mà luôn luôn là "hệ thống không an toàn". Vì thế, dùng từ "dương tính" và "âm tính" theo cách mà mrro đã dùng là chính xác. |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch |
27/07/2008 13:44:09 (+0700) | #54 | 143605 |
|
gamma95
Researcher
|
Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline
|
|
val3ntjn3 wrote:
lamer wrote:
[truyện hài thứ hai]
Ngày hôm qua mình có viết 1 cái chương trình vét cạn tên người dùng của một máy chủ kia. Chương trình của mình chỉ gửi vài chục bytes (cho là 100 đi cho dễ tính) qua mạng cho mỗi câu truy vấn thôi. Mình cứ ngỡ là mạng mình nhanh, có thể gửi cả triệu truy vấn trong tíc tắc được, nhưng ai dè đâu mình vét có 3 ký tự mà tốn hơn 10 phút. Cuối cùng mình phải ngắt nó giữa chừng vì không chờ nổi. Có cách nào gửi cả triệu truy vấn (hoặc trả lời giả) trong vài giây đồng hồ (để tránh timeout của UDP) không các bạn?
[hết truyện hài thứ hai]
[Truyện cực hài thứ ba]
Có một người cực hài hước, có chữ security ở chữ ký mà không biết rằng đã tấn công thì không cần phải chờ time out. Không biết làm thế nào để gửi nhiều truy vấn mà phải ngồi hì hụi gửi từng truy vấn 1. Đọc xong cười chảy nước mắt
[/hết truyện cực cực hài]
Ho ho, bồ hài hước vô địch , cái câu "đã tấn công thì không cần phải chờ time out" ở đâu ra vậy?? anh lamer nói để tránh time out chứ ai nói tấn công phải chờ time out đâu ông nội ? Còn chuyện bồ có thể gởi đc nhiều request cụ thể là bao nhiêu request/s ? dung lượng mỗi gói? bandwitch của bồ bao nhiêu??Hay là bồ có một mạng botnet với hàng trăm nghìn máy tính để điều khiển ???
@facialz: rất chính xác
@boom_jt: Tui còn thấy vài topic ko mang tính kỹ thuật của bồ trong topic này tui sẽ del ko báo trước. |
|
Cánh chym không mỏi
lol |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 14:12:47 (+0700) | #55 | 143609 |
![[Avatar]](/hvaonline/images/avatar/00e78c6cccd994a47d19650362edcd93.jpg "[Avatar]")
|
instcode
Member
|
|
0 |
|
|
Joined: 09/09/2004 21:42:44
Messages: 13
Offline
|
|
hoanghono wrote:
mrro wrote:
Khi kiểm tra 1 hệ thống có an toàn hay không, nếu kết quả báo là an toàn, mà thực tế là không, thì gọi là "false positive" chứ không phải gọi là "false negative".
Haha thế thì nó là định nghĩa của bồ. Bồ hiểu chữ "positive" ở đây nghĩa là gì? Haha về cái này, tôi nghĩ tôi chẳng cần phải đọc tài liệu lại đâu. Bồ nghĩ tôi viết sai thì cứ nghĩ, kô có vấn đề gì cả.
Thực tế tôi chưa bao giờ phải vừa tranh luận vừa đọc tài liệu làm gì, bởi nếu tôi không rõ về một đề tài nào đó, tôi đã không tranh luận rồi.
--m
Tui chẳng có định nghĩa của riêng mình đâu. Đó là định nghĩa của giới khoa học đó, toán học, logic học, xác suất học... đều chung 1 khái niệm như tui nói cả. Mrro cần kiểm tra lại "định nghĩa" của Mrro đi, cho nó giống thế giới.
Chuyện: Em (E), Anh (A), Trung Tâm Dự Báo Thời Tiết (T) và Ông Trời (O):
1. Tình huống 1:
False Positive:
E: Em sẽ đi chơi với anh nếu trời nắng!
T: Sắp có nắng to!
A: Nắng đẹp quá em ơi, anh đến đón em nhé?
E: Ừa.
O: Mưa cho tụi mày chết nè!
False Negative:
E: Em sẽ đi chơi với anh nếu trời nắng!
T: Sắp có mưa lớn!
E: Thôi sắp có mưa, anh khỏi đến!
O: Êh, nắng mà?
A: Huhuh, thằng TTDBTT khốn nạn!
2. Tình huống 2:
False Positive:
E: Em sẽ kô đi chơi với anh nếu trời nắng!
T: Sắp có mưa lớn!
A: Trời sắp mưa rồi, đẹp quá em ơi, anh đến đón em nhé?
E: Ừa.
O: Nắng nè!
False Negative:
E: Em sẽ kô đi chơi với anh nếu trời nắng!
T: Sắp có nắng to!
E: Thôi trời nắng to quá, em ở nhà.
O: Ủa? Mưa mà! Nè!
A: Thằng TTDBTT mất nết.
Hi vọng giúp hoanghono ngộ ra được cái gì đó  |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 14:17:58 (+0700) | #56 | 143610 |
PXMMRF
Administrator
|
Joined: 26/09/2002 07:17:55
Messages: 946
Offline
|
|
Thấy các bác thảo luận sôi nổi quá, cũng thấy nhiều bài tôi học hỏi đựoc nhiều, nên dù trình độ thấp kém, tôi cũng mạo muội góp vài ý kiến, gọi là thêm mắm, thêm muối mà thôi.
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ế.
Về ý kiến của gamma95 ở trên nói về hacker tư thiết lâp một DNS server trên local network và cấu hình trên A record để ta không thể truy câp vào một website mong muốn, thì tôi thấy đúng. Tôi đã làm thử, nhân khi mò mẫm về DNS cache poisoning. Tuy nhiên việc này chỉ thành công khi recursive DNS server của ISP bị hỏng, config. sai hay lão Admin. tự nhiên lai disable cái recursion đi cơ.
Có thời gian tôi sẽ xin phép phân tích đôi điều về cơ chế "Birthday Attack" và cơ chế tấn công mà Dan Kaminsky có thể đề câp. |
|
The absence of disagreement is not harmony, it's apathy.
(Socrates)
Honest disagreement is often a good sign of progress.
(Mahatma Gandhi)
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 18:15:24 (+0700) | #57 | 143612 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
tôi thấy nhiều bạn cứ thắc mắc tại sao tôi nói tự vì kiểm tra là phải kiểm tra xem có người sử dụng dịch vụ của máy chủ DNS có được bảo vệ an toàn hay không, còn việc vá hay không vá là việc tính sau..
cái ý tưởng "có lỗi thì phải vá" thường xuất hiện ở một số bạn nghĩ là mình hiểu về bảo mật nhưng sự thật thì kô hiểu được bao nhiêu. bản thân tôi cũng đã phải mất một thời gian dài mới ngộ được ra vấn đề này, thôi thì hôm nay chia sẻ ở đây.
"có lỗi trong phần mềm tôi đang sử dụng, nên tôi cập nhật nó", một lý lẽ xem ra rất thuyết phục, nếu như không có các ràng buộc từ phía business.
mục tiêu cốt lõi và cuối cùng của một hệ thống không phải là để vá hết lỗi, mà là để phục vụ những yêu cầu của người sử dụng, như họ mong đợi, theo đúng thiết kế ban đầu của hệ thống.
đôi khi, chính cái ràng buộc, chính cái yêu cầu cốt lõi này, làm cho chúng ta phải chấp nhận vận hành một hệ thống, mà trong đó, chúng ta biết là có lỗi có thể bị khai thác. đối với nhiều bạn mới tìm hiểu về bảo mật, sẽ thấy luận điểm này khá là phản trực giác, chạy một hệ thống không an toàn là một điều không thể chấp nhận được đối với họ. rồi cuối cùng họ bị sa thải :-p, bởi hành động vá lỗi, mà họ nghĩ là tích cực, rốt cuộc lại làm tê liệt hoàn toàn hệ thống, làm thiệt hại hàng trăm nghìn, hàng triệu USD.
trở lại với vấn đề DNS. nếu bạn nào theo dõi kỹ sự kiện này, sẽ thấy những cảnh báo sau đây "the patches will have a noticeable impact on the performance of BIND caching resolvers with query rates at or above 10,000 queries per second. Đây là một vấn đề không thể xem nhẹ, nhất là đối với các ISP lớn, bởi lẽ nếu DNS resolver của họ chết, thì toàn bộ cái mục tiêu cốt lõi của họ cũng sẽ đi tong.
ngoài ra, việc vá lỗi, dẫn đến source port sẽ bị ngẫu nhiên hóa, và sẽ có thể dẫn đến những thay đổi lớn trong cấu hình mạng của hệ thống. chẳng hạn như cấu hình firewall hay cấu hình của các thiết bị NAT. mà những thay đổi về cấu hình mạng đôi khi không phải cứ muốn làm là được.
hơn nữa, trong các doanh nghiệp hay ISP to, việc cập nhật phần mềm đối với một hệ thống critical như DNS không phải là việc các tay sysadmin muốn là có thể làm. tất cả những việc này đều có quy trình, và quy trình thì cần có thời gian. một số DNS resolver của AT&T cho đến nay vẫn chưa vá lỗi, bởi họ vẫn đang còn trong giai đoạn thử nghiệm, trước khi triển khai chính thức các miếng vá.
nói cách khác, biết là có lỗi, biết là có thể bị khai thác, biết là người dùng có thể bị ảnh hưởng nhưng vẫn không vá được ngay, thì tại sao phải vội vã hấp tấp vá, nếu như biết là có lỗi, nhưng không thể bị khai thác hay người dùng không bị ảnh hưởng?
đừng nghĩ tôi tự đặt ra những câu hỏi thế này. nếu bạn làm trong lĩnh vực này đủ lâu, sẽ có ngày một ông ở cấp C hỏi bạn câu hỏi này. không thể có chuyện vá chỉ để sướng :-p.
thành ra, nếu như DNS resolver của tôi có lỗi, nhưng do tôi đang forward toàn bộ recursive query đến một DNS forwarder đã vá lỗi, thì tôi chưa cần phải vá lỗi ngay tức thì, bởi lẽ người dùng của tôi vẫn an toàn, nghĩa là cái mục tiêu cốt lõi của hệ thống DNS vẫn được đáp ứng.
thực tế đây chính là một trong những giải pháp được rất nhiều chuyên gia trên thế giới đề nghị, kể cả Dan Kaminsky, và rất nhiều người đã áp dụng nó bằng cách forward các recursive query của họ đến cho OpenDNS, để có thêm thời gian đánh giá vấn đề.
điểm cốt yếu phân biệt giữa những tay nghĩ là họ làm về security với những người thực sự làm về security là mấy tay đầu luôn nghĩ security là một vấn đề kĩ thuật, có thể giải quyết bằng các giải pháp kỹ thuật; còn mấy tay sau, sau vài năm lăn lộn với đám làm business, biết rằng security là một vấn đề của business, không thể tách ra khỏi cái mục tiêu của business, chỉ có thể xem là được giải quyết thành công nếu vẫn đáp ứng được yêu cầu của business.
điều đáng buồn là đa số những người đi làm tư vấn bảo mật, và đa số các công ty tư vấn bảo mật chuyên nghiệp ở VN, mà công việc cho phép tôi gặp khá nhiều, thường chưa từng kinh qua công việc làm bảo mật cho các doanh nghiệp trước đó. mục tiêu của họ là làm sao cho hệ thống an toàn, trong khi mục tiêu cần phải đạt được của doanh nghiệp là các chỉ tiêu kinh doanh. khác mục tiêu, sẽ dẫn đến xung đột :-p.
--m |
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
27/07/2008 22:13:20 (+0700) | #58 | 143623 |
![[Avatar]](/hvaonline/images/avatar/be6622984d88496a6fb459da46813e23.png "[Avatar]")
|
meomeo_bebong
Locked
|
|
0 |
|
|
Joined: 27/06/2006 23:07:44
Messages: 700
Location: vô gia cư
Offline
|
|
Kiến thức về mạng của em gần như là con số 0 . Nhưng em chỉ có vài câu hỏi về chủ đề này muốn được bà con giải đáp hộ
1/ Dùng Open DNS có giảm bớt hậu quả của lỗi này k0 ? Giảm được bao nhiêu ạ ?
2/ Nếu như có IP động (hình như là Dynamic IP), thì tại sao lại k0 có DNS động nhỉ ? Ở nhà em thêm vào network rất nhiều các DNS ? Liệu có đủ an toàn chưa ạ ?
3/ Có cần thêm công cụ offline tại client/server để check DNS nữa k0 ?
4/ Tại sao k0 mã hoá tất cả các gói tin truyền đi trên mạng (giữa server và client), có thể mã hoá bằng chữ kí MD5, SHA và check bằng chúng luôn ?
PS : Nếu như dịch từ Anh = > Việt k0 hoàn toàn chính xác , thì có thể tham khảo thêm dịch Anh = > giải nghĩa từ tiếng Anh đó = > từ đó giải nghĩa đoạn tiếng Anh sang tiếng Việt đuợc mà ? |
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch |
28/07/2008 00:05:51 (+0700) | #59 | 143636 |
![[Avatar]](/hvaonline/images/avatar/0eecd470a1629be722eb0e2e486700cc.png "[Avatar]")
|
tranhuuphuoc
Moderator
|
Joined: 05/09/2004 06:08:09
Messages: 865
Location: Lầu Xanh
Offline
|
|
Tôi thấy trên internet có cách thử DNS Cache Poisoning khá hay .
Tôi sử dụng internet thông qua nhà cung cấp dịch vụ internet là VDC . Sau khi sử dụng lệnh dig thì thấy thông tin như sau :
DNS cache poisoning (also known as DNS cache pollution) is a maliciously created or unintended situation that provides data to a Domain Name Server that did not originate from authoritative DNS sources. It occur if DNS "spoofing attack" has been encountered. An attacker will send malicious data / non-secure data in response to a DNS query. For example dns query for www.cyberciti.biz can be wwwected to www.example.com.
# dig +short @203.162.4.190 porttest.dns-oarc.net txt
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"203.162.4.198 is GOOD: 26 queries in 6.7 seconds from 26 ports with std dev 17985.45"
# dig +short @203.162.4.190 porttest.dns-oarc.net txt
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"203.162.4.198 is POOR: 26 queries in 6.7 seconds from 26 ports with std dev 17985.45"
Nếu bạn dùng hệ điều hành Windows thì bạn có thể sử dụng công cụ nslookup tuy nhiên tôi không dùng Windows cho nên chưa thấy thông tin chính xác của output ở Command Prompt
nslookup -type=txt -timeout=30 porttest.dns-oarc.net
nslookup -type=txt -timeout=30 porttest.dns-oarc.net ns1.your-isp.com
nslookup -type=txt -timeout=30 porttest.dns-oarc.net NS-SERVER-IP
http://www.cyberciti.biz/tips/windows-verify-dns-cache-posinging-bug.html
http://www.cyberciti.biz/faq/dns-cache-poisoning-test/
|
|
|
|
|
| [Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý |
28/07/2008 01:25:37 (+0700) | #60 | 143642 |
![[Avatar]](/hvaonline/images/avatar/5a1716dddbf77d0667089f90e9a58215.jpg "[Avatar]")
|
vippro123
Locked
|
|
0 |
|
|
Joined: 22/03/2007 18:15:50
Messages: 111
Location: HuẾ MộNg mơ
Offline
|
|
và đây là cuộc tấn công đầu tiên :
Code:
http://quantrimang.com/baomat/bao-mat/tin-bao-mat/47406_Vu_tan_cong_dau_tien_loi_dung_lo_hong_DNS.aspx
Code:
http://www.vnunet.com/vnunet/news/2222592/first-dns-attacks-reported
|
|
|
| Users currently in here |
|
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|
![[Rule]](/hvaonline/templates/viet/images/icon_mini_rule.gif "[Rule]"){kind=icon}
![[Home]](/hvaonline/templates/viet/images/icon_mini_groups.gif "[Home]"){kind=icon}
![[Portal]](/hvaonline/templates/viet/images/icon_mini_portal.gif "[Portal]"){kind=icon}
![[Members]](/hvaonline/templates/viet/images/icon_mini_members.gif "[Members]"){kind=icon}
![[Statistics]](/hvaonline/templates/viet/images/icon_mini_stats.gif "[Statistics]"){kind=icon}
![[Search]](/hvaonline/templates/viet/images/icon_mini_search.gif "[Search]"){kind=icon}
![[Reading Room]](/hvaonline/templates/viet/images/icon_mini_book.gif "[Reading Room]"){kind=icon}
![[Register]](/hvaonline/templates/viet/images/icon_mini_register.gif "[Register]"){kind=icon}
Register![[Login]](/hvaonline/templates/viet/images/icon_mini_login.gif "[Login]"){kind=icon}
Login [
Thông tin new bugs và exploits
![[Profile]](/hvaonline/templates/viet/images/en_US/icon_profile.gif "[Profile]"){kind=icon}
![[PM]](/hvaonline/templates/viet/images/en_US/icon_pm.gif "[PM]"){kind=icon}
![[Up]](/hvaonline/templates/viet/images/en_US/icon_up.gif "[Up]"){kind=icon}
![[Print Copy]](/hvaonline/templates/viet/images/en_US/icon_print.gif "[Print Copy]"){kind=icon}
![[ICQ]](/hvaonline/templates/viet/images/icon_icq_add.gif "[ICQ]"){kind=icon}
![[WWW]](/hvaonline/templates/viet/images/icon_www.gif "[www]"){kind=icon}
![[Yahoo!]](/hvaonline/templates/viet/images/icon_yim.gif "[YIM]"){kind=icon}
![[MSN]](/hvaonline/templates/viet/images/icon_msnm.gif "[MSN]"){kind=icon}
![[digg]](/hvaonline/templates/viet/images/digg.gif "[digg]")
![[delicious]](/hvaonline/templates/viet/images/delicious.gif "[delicious]")
![[google]](/hvaonline/templates/viet/images/google.gif "[google]")
![[yahoo]](/hvaonline/templates/viet/images/yahoo.gif "[yahoo]")
![[technorati]](/hvaonline/templates/viet/images/technorati.gif "[technorati]")
![[reddit]](/hvaonline/templates/viet/images/reddit.gif "[reddit]")
![[stumbleupon]](/hvaonline/templates/viet/images/stumbleupon.gif "[stumbleupon]")