(Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thông tin new bugs và exploits

(Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

[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 02:33:03 (+0700) \| #61 \| 143650

anhsuytu
Member

Joined: 11/01/2004 03:24:46
Messages: 62
Offline

Em thử chạy cmd test giống như bác M nói .. thì thấy cả FPT và Viettel đều chưa vá, ko biết VNN và chưa nhỉ? smilie

[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 05:20:50 (+0700) \| #62 \| 143674

gamma95
Researcher

Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline

ko thấy hoanghono+val3ntjn3 vào đây to tiếng nữa, buồn quá mrro smilie

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	28/07/2008 08:09:51 (+0700) \| #63 \| 143690

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

tranhuuphuoc wrote:

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/

Testing tool nói trên đựoc dns-oarc.net. công bố một ngày sau ngày Dan Kaminsky thông báo lỗi DNS cache poisoning.
Theo các bạn thì "nôi dung", "muc đích" (hay nói theo cách của các nhà xã hội học thì "bản chất" ) của Testing tool này là gì?

Hình như các công ty như ISC (BIND), Microsoft và Cisco cũng đang cố gắng fix các sản phẩm của mình theo hứong mà dns-oarc.net ngầm chỉ tới, ngầm khuyến cáo. Nhưng Cisco thì có vẻ khôn ngoan hơn.

Theo các bạn các giải pháp mà dns-oarc.net "ngầm" khuyến cáo (thông qua Tool của họ nói trên) và các giải pháp mà các công ty trên đề ra đã thật hợp lý không? Có điểm nào còn chưa phù hợp với kết cấu hạ tầng DNS công ty, quốc gia và thế giới vốn rất phức tạp và rất critical không?

Có giải pháp nào hay hơn, toàn diện hơn không?

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ú ý	28/07/2008 10:42:57 (+0700) \| #64 \| 143710

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

Như đã nói ở trên, tôi xin viết đôi điều về cơ chế cuôc tấn công "BirthDay paradox" hay có thể các cuộc tấn công mà Dan Kaminsky thông báo. Có gì sai xin các bạn chỉ giáo.
=================

Các cuộc tấn công với mục đích "DNS cache poisoning" như tấn công "BirthDay attack" hay có thể các cuộc tấn công vào hệ thống DNS mà Dan Kaminsky đã thông báo vào ngày 7.7.2008 trên mạng, đều dựa trên một cơ sở khoa học liên quan đến việc xác định khả năng xảy ra của một sư kiện trong những điều kiện, tình huống cụ thể.

I- Thế nào là một cuộc tấn công "BirthDay paradox'

"A birthday attack is a name used to refer to a class of brute-force attacks. It gets its name from the surprising result that the probability that two or more people in a group of 23 share the same birthday is greater than 1/2; such a result is called a birthday paradox"

("BirthDay attack" là tên của một cuôc tấn công, tên này được sử dụng để nói về một lọai tấn công "brute-force".Tên cuộc tấn công đựoc đặt như vậy xuất phát từ một kết quả khảo sát đầy ngạc nhiên: Trong một nhóm 23 người, khả năng 2 người hay nhiều hơn 2 ngươi có cùng ngày sinh sẽ đạt xác xuất lớn hơn 1/2.) .Người dịch PXMMRF-HVA.

Một tác giả (chưa rõ tên) đã tổng kết các trường hợp tương tự như "BirthDay Paradox" nói trên thành một quy luật như sau:

"If some function, when supplied with a random input, returns one of k equally-likely values, then by repeatedly evaluating the function for different inputs, we expect to obtain the same output after about 1.2k1/2. For the above birthday paradox, replace k with 365."

(Nếu một hàm số nào đó, khi đưa vào một biến số ngẫu nhiên, cho ra một kết quả có giá trị nằm trong vùng giá trị bằng, giống nhau k, thì sau khoảng 1,2 k ^1/2 [1,2 x căn k] phép thử lặp lại với các biến số đầu vào khác nhau, ta sẽ có các kết quả giống hệt nhau. Trong trường hợp "BirthDay paradox" thì thay k=365) Người dịch PXMMRF với sự góp ý của facialz-HVA.

Trong trình bầy đề cập trên đây, chúng ta cần chú ý đến yếu tố: ""cho ra một kết quả có giá trị nằm trong vùng giá trị bằng, giống nhau k"", đây có thể coi là một trường hợp, tình huống riêng, đặc biệt, xác định. Với "BirthDay paradox" thì xác xuất sự kiện 2 người hay nhiều hơn có cùng một ngày sinh trong số 23 người chọn ngẫu nhiên, sẽ rất nhỏ, nếu như một năm có nhiều hơn 365 ngày, thí dụ 1500 ngày chẳng han, nghỉa là k>>365 (ngày). Khi ấy trong tháng 8 chẳng hạn, biết đâu sẽ có người sinh vào ngày 32/8 hay 37/8.

Vậy thì trong các cuộc tấn công "DNS cache poisoning" kiểu "BirthDay attack" hay có thể cuộc tấn công mà Dan Kaminsky thông báo, thì k là gì và có giá trị bao nhiêu, hay có ý nghĩa gì?, trong khi mỗi lần hacker từ máy của mình gủi một gói tin đến Victim recursive DNS server, giả mạo gói tin trả lời của Authoritative DNS server, được coi là một lần thử. Cũng như khái niệm "obtain the same output " (có các kết quả giống hệt nhau) đựoc hiểu là hacker thâm nhập thành công vào Victim recursive DNS server, nghĩa là gói tin giả mạo của hacker đã được DNS server này chấp nhận.

(Còn xin viết tiế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	28/07/2008 22:50:00 (+0700) \| #65 \| 143773

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

PXMMRF wrote:

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.

Em xin phép mấy đại ca cho em phát biểu ngoài lề một tí . Đoạn quote trên nói lên điều gì ???Hãy cố gắng làm theo smilie

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch	29/07/2008 03:12:33 (+0700) \| #66 \| 143837

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

conmale wrote:

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.

@ anh conmale . Em kô hiểu cái đoạn tô đỏ cho lắm . Anh hay bạn nào giải thích giùm smilie

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch	29/07/2008 05:17:57 (+0700) \| #67 \| 143871

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

vikjava wrote:

conmale wrote:

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.

@ anh conmale . Em kô hiểu cái đoạn tô đỏ cho lắm . Anh hay bạn nào giải thích giùm

OK, BIND / DNS 101 crash course, here we come smilie

Giả sử, trên một *nix host (trên A), em telnet www.hvaonline.net 80 (trên B) chẳng hạn. Có những chuyện như sau sẽ xảy ra:

1) Tiến trình tạo ra telnet sẽ gọi hàm gethostbyname để lấy IP của www.hvaonline.net. Tiến trình này xả ra trên A.

2) Routine gethostbyname sẽ gọi BIND resolver (trên A) thực thi công tác querying đến các name servers (trên C và D). Các name servers này có thể chính là dịch vụ named chạy ngay trên host A hoặc các dịch vụ named chạy ở đâu đó trên các server khác.

3) BIND resolver này sẽ thiết lập một query và gởi đến một name server (C hoặc D). Nếu chính host A không có dịch vụ named đang chạy nó có một hồ sơ ứng hiệu /etc/resolv.conf chứa các IP trỏ đến những name servers.

4) Name server (có dịch vụ named) nhận query từ BIND resolver.

5) Giả định name server này (C) chưa hề có thông tin gì về hvaonline.net cả, nó bèn phải liên hệ một root name server -1- dựa trên namespace thích hợp (.net trong trường hợp này). Nếu DNS root server ấy không có thông tin gì về hvaonline.net, nó hồi báo name server (C) IP của authoritative answerer của hvaonline.net.

6) Name server này (C) tiếp tục query IP của authoritative answerer của hvaonline.net sau khi nhận được hồi báo từ một trong những DNS root servers ở trên (dịch vụ này có thể là BIND, có thể là djbdns, có thể là cái gì đó nhưng phải là authoritative answer).

7) authoritative answerer của hvaonline.net trả lời name server (C).

8) Name server này (C) hồi báo thông tin cho BIND resolver (trên A).

9) BIND resolver (trên A) chuyển thông tin về routine gethostbyname và cuối cùng thông tin này về đến tiến trình telnet nguyên thủy ở bước 1).

NẾU chính host A có local named service. Phần BIND resolver vẫn phải "hỏi" named service để lấy thông tin. Telnet process với routine gethostbyname không bao giờ query trực tiếp đến named mà phải qua BIND resolver.

Hy vọng giải thích (màu mè) trên làm rõ hơn smilie

Thân mến.

-1- DNS root servers:

Letter IPv4 address IPv6 address Old name Operator Location Software
A 198.41.0.4 2001:503:BA3E::2:30 ns.internic.net VeriSign Dulles, Virginia, U.S. BIND
B 192.228.79.201 2001:478:65::53 ns1.isi.edu USC-ISI Marina Del Rey, California, U.S. BIND
C 192.33.4.12 c.psi.net Cogent Communications distributed using anycast BIND
D 128.8.10.90 terp.umd.edu University of Maryland College Park, Maryland, U.S. BIND
E 192.203.230.10 ns.nasa.gov NASA Mountain View, California, U.S. BIND
F 192.5.5.241 2001:500:2f::f ns.isc.org ISC distributed using anycast BIND
G 192.112.36.4 ns.nic.ddn.mil Defense Information Systems Agency Columbus, Ohio, U.S. BIND
H 128.63.2.53 2001:500:1::803f:235 aos.arl.army.mil U.S. Army Research Lab Aberdeen Proving Ground, Maryland, U.S. NSD
I 192.36.148.17 nic.nordu.net Autonomica distributed using anycast BIND
J 192.58.128.30 2001:503:C27::2:30 VeriSign distributed using anycast BIND
K 193.0.14.129 2001:7fd::1 RIPE NCC distributed using anycast NSD
L 199.7.83.42 (since November 2007; was 198.32.64.12)[2] ICANN distributed using anycast NSD
M 202.12.27.33 2001:dc3::35 WIDE Project distributed using anycast BIND

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ú ý	30/07/2008 11:09:00 (+0700) \| #68 \| 144124

hoanghono
Member

Joined: 28/06/2008 01:48:13
Messages: 6
Offline

Và Dan đã có bài viết về hạn chế của cái tool dùng để test của Dan trên blog của mình:
http://www.doxpara.com/

Here’s the problem: I’m watching you look up Doxpara’s names. That’s how I can see what ports you’re using! If you don’t use DNS to find Doxpara, I can’t watch you finding Doxpara, and thus I can’t tell you if you’re always using the same ports.

Also, people want to have the ability to ask for a particular name server to be tested. My problem here is that I probably don’t have access to your name server, except through you — so I need your web browser to poke your name server to look up a name from me. Then, and only then, can I tell you if there’s a problem.

Như vậy, như tui đã viết trong các bài trước: nhu cầu test từng DNS Server là có. Và Dan thừa nhận là tool của mình không thể đáp ứng tất cả những nhu cầu đó. Để test những DNS Server trong chuỗi forward, cách duy nhất là phải cấu hình trên DNS Server để nó tìm tên miền từ server của Dan, lúc đó tool của Dan mới check được xem DNS Server đó có lỗi hay không. Nhưng cách làm của Dan không hỗ trợ cách thực hiện này.

Cách làm của Mrro cũng vậy, giống của Dan, chỉ cho phép kiểm tra DNS Server cuối cùng trong chuỗi forward, DNS Server trực tiếp đi hỏi tên miền (connect vào server kiểm tra)

Còn cách làm của BKIS thì cho phép test bất kỳ DNS Server nào: quản trị mạng chỉ cần cấu hình trên DNS Server cần kiểm tra và chạy công cụ của BKIS để check lỗi.

Còn việc nhận định của Mrro về việc không cần phải vá lỗi là hoàn toàn sai lầm. Đồng ý là việc vá lỗi có thể phải kéo dài, cần phải cân nhắc nhiều yếu tố, có thể mất thời gian, nhưng chắc chắn là phải vá lỗi. Có thể việc này đòi hỏi phải có 1 kế hoạch kỹ càng, cần kiểm tra kỹ lưỡng trước khi triển khai thực tế đối với các hệ thống lớn, nhưng không thể không thực hiện. Mrro làm trong lĩnh vực ngân hàng mà có nhận định như vậy thì thật là yếu. Ngân hàng, tài chính đòi hỏi sự an ninh cao độ, việc vá lỗi đòi hỏi phải có kế hoạch chi tiết, cụ thể, nhưng không thể là không tính cách để vá lỗi. Đặc biệt là lỗ hổng nghiêm trọng như lỗ hổng DNS này.

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý	30/07/2008 12:19:46 (+0700) \| #69 \| 144147

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

@hoanghono: tôi nghĩ tôi (và nhiều người khác) sẽ respect bồ hơn nếu bồ thừa nhận những sai sót của bồ. chứ còn cái kiểu "lập lờ đánh lận con đen" thế này thì đáng khinh lắm bồ àh.

1. cái cách mà tôi đưa ra nó khác với cái cách của Dan, và nó có thể dùng để kiểm tra cho từng server nếu muốn.

2. những hạn chế của cái tool của bkis thì tôi đã chứng minh rồi, tôi nghĩ những người đọc topic này cũng đã có kết luận của họ rồi.

3. tôi không nói là không cần phải vá, mà tôi nói là có những trường hợp không phải muốn vá là vá. có thể bồ nói đúng, tại tôi "yếu" quá, lại làm cho đám ngân hàng, business của chúng chẳng có gì nghiêm trọng hết, sao mà so với "bắt virus sỉ và lẻ" được, nên tôi mới có kết luận như vậy. thôi thì cứ coi như đó là kết luận của riêng tôi, tôi dốt thì tôi chịu 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ú ý	30/07/2008 13:48:47 (+0700) \| #70 \| 144171

hoanghono
Member

Joined: 28/06/2008 01:48:13
Messages: 6
Offline

mrro wrote:

@hoanghono: tôi nghĩ tôi (và nhiều người khác) sẽ respect bồ hơn nếu bồ thừa nhận những sai sót của bồ. chứ còn cái kiểu "lập lờ đánh lận con đen" thế này thì đáng khinh lắm bồ àh.

Tui chưa thấy Mrro chỉ ra cái sai của tui?
Cũng giống như boom_jt đã reply cho Mrro: "hãy nói chuyện với nhau thẳng thắn", Mrro còn là Mod nữa, hãy giữ thái độ tranh luận chuẩn mực.

mrro wrote:

1. cái cách mà tôi đưa ra nó khác với cái cách của Dan, và nó có thể dùng để kiểm tra cho từng server nếu muốn.

Hãy chứng minh đi !
Tại sao tui check con DNS Server của tui 203.162.X.X thì cách của Mrro cứ trả lời kết quả check con DNS Server 203.119.8.X của VNNIC ? (chi tiết như tui đã post ở http://hvaforum.net/hvaonline/posts/list/20/23739.html )

mrro wrote:

2. những hạn chế của cái tool của bkis thì tôi đã chứng minh rồi, tôi nghĩ những người đọc topic này cũng đã có kết luận của họ rồi.

Những "hạn chế" nào mà Mrro nói chưa bị tui phản biện? Chưa thấy Mrro phản biện lại những ý kiến đó của tui? Cứ trao đổi thẳng thắn để tìm ra chân lý, sẽ tốt cho rất nhiều người quan tâm tới vấn đề này. Còn nếu Mrro không còn ý kiến phản bác, thì đừng nên nói theo kiểu này, đây mới gọi là kiểu "lập lờ đánh lận con đen".

mrro wrote:

3. tôi không nói là không cần phải vá, mà tôi nói là có những trường hợp không phải muốn vá là vá. có thể bồ nói đúng, tại tôi "yếu" quá, lại làm cho đám ngân hàng, business của chúng chẳng có gì nghiêm trọng hết, sao mà so với "bắt virus sỉ và lẻ" được, nên tôi mới có kết luận như vậy. thôi thì cứ coi như đó là kết luận của riêng tôi, tôi dốt thì tôi chịu vậy.
--m

Như vậy vá những lỗ hổng nghiêm trọng là cần thiết phải không? smilie

Tui hiểu hoàn cảnh của Mrro, tại sao Mrro lại có suy nghĩ kiểu "không phải cứ có lỗi là vá", rồi các ràng buộc "business" mà Mrro nói. Đúng là trong ngành Ngân hàng thì giới IT VN chẳng là cái đinh gì cả, dù mình có giữ chức gì đi chăng nữa. Hệ thống thì toàn lấy của Tây, chẳng có quyền can thiệp gì cả. Lỗi, sự cố, cần vá... đều phải có quy nghiêm ngặt, phải thông qua các hãng cung cấp giải pháp của Tây, và chỉ khi bọn nó nói yes, ok, thì IT ngân hàng mới có thể làm theo, chứ đâu được tự quyền quyết, như mấy bác ở các công ty thuộc ngành khác, hay mấy bác IT ở ISP. Nhưng dù sao, ngồi theo dõi xem hệ thống mạng của 1 ngân hàng chạy có vấn đề gì hay không cũng là 1 việc quan trọng không thể không có, vì lúc có sự cố cũng phải có người phát hiện và đề đạt lên để sửa chứ. Cũng giống như vấn đề DNS cache poisoning này chẳng hạn.

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý	30/07/2008 15:09:29 (+0700) \| #71 \| 144179

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

hoanghono wrote:

Hãy chứng minh đi !
Tại sao tui check con DNS Server của tui 203.162.X.X thì cách của Mrro cứ trả lời kết quả check con DNS Server 203.119.8.X của VNNIC ? (chi tiết như tui đã post ở http://hvaforum.net/hvaonline/posts/list/20/23739.html )

Haha nếu bồ thực sự làm chủ con server 203.162.X.X của bồ, thì để kiểm tra, bồ cần phải điều chỉnh cấu hình của nó lại, để nó đừng forward recursive query đến server của VNNIC nữa.

Còn nếu như bồ không làm chủ con server của bồ, hay là bồ không thể thay đổi cấu hình của nó, thì việc kiểm tra con server lúc này trở nên vô ích. Lý do thì tôi đã nói ở trên.

hoanghono wrote:

Những "hạn chế" nào mà Mrro nói chưa bị tui phản biện? Chưa thấy Mrro phản biện lại những ý kiến đó của tui? Cứ trao đổi thẳng thắn để tìm ra chân lý, sẽ tốt cho rất nhiều người quan tâm tới vấn đề này. Còn nếu Mrro không còn ý kiến phản bác, thì đừng nên nói theo kiểu này, đây mới gọi là kiểu "lập lờ đánh lận con đen".

Tôi đã nói ở trên rồi, chẳng còn gì để nói lại ở đây cả. Tôi cũng hết kiên nhẫn với bồ rồi. Chắc sẽ có ai đó nói chuyện tiếp với bồ vậy :-p.

Tôi cũng tranh luận với nhiều người rồi, nên tôi biết, nhiều lúc người ta không trả lời lại, không phải vì ý kiến của mình quá hay ho, quá mạnh, mà cũng có thể là vì ý kiến của mình quá dốt, người ta chẳng muốn nói nữa :-p.

hoanghono wrote:

Như vậy vá những lỗ hổng nghiêm trọng là cần thiết phải không?
Tui hiểu hoàn cảnh của Mrro, tại sao Mrro lại có suy nghĩ kiểu "không phải cứ có lỗi là vá", rồi các ràng buộc "business" mà Mrro nói. Đúng là trong ngành Ngân hàng thì giới IT VN chẳng là cái đinh gì cả, dù mình có giữ chức gì đi chăng nữa. Hệ thống thì toàn lấy của Tây, chẳng có quyền can thiệp gì cả. Lỗi, sự cố, cần vá... đều phải có quy nghiêm ngặt, phải thông qua các hãng cung cấp giải pháp của Tây, và chỉ khi bọn nó nói yes, ok, thì IT ngân hàng mới có thể làm theo, chứ đâu được tự quyền quyết, như mấy bác ở các công ty thuộc ngành khác, hay mấy bác IT ở ISP. Nhưng dù sao, ngồi theo dõi xem hệ thống mạng của 1 ngân hàng chạy có vấn đề gì hay không cũng là 1 việc quan trọng không thể không có, vì lúc có sự cố cũng phải có người phát hiện và đề đạt lên để sửa chứ. Cũng giống như vấn đề DNS cache poisoning này chẳng hạn.

Xin lỗi nhưng những suy diễn của bồ hoàn toàn sai, trong trường hợp của tôi. Và nó cũng chẳng ăn nhập gì với cái ý khi tôi nói "không phải cứ có lỗi là vá". Sự thật là tôi chưa bao giờ nghĩ rằng vá lỗi sẽ giúp tôi an toàn. Không phải cứ vá hết lỗi là an toàn.

--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ú ý	30/07/2008 16:19:39 (+0700) \| #72 \| 144182

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

trong bài trước, tôi có nói, có nhiều trường hợp vì ràng buộc của các mục tiêu kinh doanh, chúng ta không thể vá lỗi, dù lỗi đó có nguy hiểm đến đâu đi chăng nữa. điều này thoạt nghe thì thấy hết sức nguy hiểm, nhưng nếu suy nghĩ kỹ, chúng ta sẽ thấy, sự thực là chúng ta đã, đang và sẽ sống với những hệ thống có lỗi nghiêm trọng.

khi một hệ thống nào đó bị tấn công, các *chuyên gia bảo mật* sẽ thường đổ lỗi sẽ cho đám sysadmin không chịu vá lỗi. "đã có bảng vá từ vài tháng trước, nhưng họ không chịu vá, để rồi bây giờ bị tấn công là phải rồi". đúng là việc vá lỗi là việc nên làm, nhưng lỗi không phải ở đám sysadmin.

một sự thật đáng buồn là có quá nhiều lỗ hổng bảo mật. mỗi tuần tôi nhận được một bản báo cáo từ US-CERT về số lỗ hổng bảo mật đã được phát hiện trong tuần. đây là danh sách trong tuần vừa rồi, chỉ tính riêng lỗi critical thôi là đã 25, còn tổng số là 52 lỗi tất cả.

để an toàn, sysadmin phải vá tất cả lỗi. để tấn công thành công, attacker chỉ cần khai thác thành công một lỗi. đó đã là một cuộc chiến quá có lợi cho attacker, vậy mà sự thật là sysadmin không có cách nào có thể vá hết lỗi được, bởi các điều kiện ràng buộc về mục tiêu kinh doanh như đã phân tích ở bài trước.

và dẫu cho sysadmin có vá hết lỗi, thì đó cũng chỉ là những lỗi đã biết và nhà sản xuất phần mềm đã cung cấp miếng vá rồi. còn những lỗi chưa có miếng vá thì sao? hay những lỗi đã được tìm thấy nhưng chưa được công bố rộng rãi (0-day)? hay những lỗi chưa được tìm thấy? hay những lỗi do lập trình viên cố tình tạo ra trong quá trình viết phần mềm, để trục lợi về sau (backdoor)?

nói cách khác, cái quy trình "có lỗi --> vá lỗi" không đem lại sự an toàn như mong đợi. dù muốn hay không, chúng ta phải thừa nhận rằng: luôn có lỗi trong hệ thống. vậy làm sao để bảo vệ an toàn cho một hệ thống luôn có lỗi?

tôi thấy có 3 giải pháp: theo dõi, theo dõi, và theo dõi.

phải theo dõi làm sao để có thể trả lời được câu hỏi: ai (who) làm thế nào (how) để gây ra chuyện gì (what) vào khi nào (when) trên hệ thống nào (where) của tôi?

theo dõi như thế nào? đó lại là một câu chuyện dài :-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ú ý	30/07/2008 22:08:01 (+0700) \| #73 \| 144210

Look2Me
Member

Joined: 26/07/2006 23:30:57
Messages: 235
Location: Tủ quần nào
Offline

Tôi không thích phong cách nói chuyện của một số bác ở topic này. Suốt ngày mời nhau đi đọc thêm sách smilie

Trở lại vấn đề thực ra ở đây chúng ta dường như đang đứng trên 2 cái nhìn khác nhau. Theo tôi cách làm của Dan (mà bác mrro đang ủng hộ) là cách dành cho end user, còn cách làm của Bkis là dành cho các administrator.
Điều mà người dùng quan tâm nhất là tôi có được an toàn hay không? Lỗi ở đâu không cần biết.
Điều mà quản trị quan tâm nhất là: dịch vụ của tôi cung cấp có lỗi hay không? Vì tôi chịu trách nhiệm về vấn đề đó.

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch	30/07/2008 22:16:28 (+0700) \| #74 \| 144212

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

cuối cùng thì cũng đi đến chỗ cãi lộn,khích nhau smilie

. Dừng ngay chỗ anh conmale giải thích cho mình là tốt nhất. smilie

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý	31/07/2008 10:37:27 (+0700) \| #75 \| 144389

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

boom_jt wrote:

Mình cũng đã thử dùng web kiểm tra DNS Server trên, IP của DNS server thì có lúc đúng lúc không, cái này có thể tạm cho qua, nhưng khi kiểm tra rằng DNS Server tại cùng 1 IP có vulnerable hay ko thì có vẻ chưa đúng lắm.
Mình đọc code và đã thử 2 lần như sau:

(boom_jt và 144283 trên 2 url này có thể được coi là 2 chuỗi sinh "ngẫu nhiên" nhé)

Có thể thấy: với cùng 1 DNS 203.162.0.181: source port tại 2 trường hợp là khác nhau và (có vẻ) là ngẫu nhiên. Thế nhưng vẫn bị khẳng định là "appears vulnerable". Boom cho rằng việc kiểm tra này là hơi thiếu căn cứ :-?

Cơ chế làm việc Tool check DNS server vulnerability của Dan Kaminsky trên website www.doxpara.com như sau:

1- Khi ta click vào nút "Check My DNS" trên trang mở đầu www.doxpara.com (doxpara là từ viết ngựoc của paradox, một kiểu chơi chữ của Dan Kaminsky), trình duyệt của ta sẽ khởi sự những cố gắng đầu tiên để kết nối đến đến đia chỉ:
http://xxxxx.doxdns1.com/ (tại IP là 149.20.56.5 ). Trong đó xxxxx đựoc tao ngẫu nhiên.
Đương nhiên xxxxx. .doxdns1.com, thí dụ cb99895908f6.doxdns1.com là một tên miền, chính xác hơn nó là tên miền con (subdomain) của tên miền doxdns1.com do Công ty "DoxPara Research"(tại Seattle-USA) sở hữu, Dan Kaminsky là Admin.quản lý.

2- DNS client của hệ điều hành cài trên máy ta bắt đầu quá trình kết nối với recursive DNS server của ISP (thí dụ VDC, Viettel, FPT...). Vì tên miền xxxxxxx.doxdns1.com là rất mới, rất đặc biệt (do Dan Kaminsky vừa mới thiết lập cho mục đích checking DNS server) nên tất cả các recursive DNS server của các ISP Việt nam và thế giới không thể có nó trong cache. Vì vậy các recursive DNS server này đều phải liên hệ trên mạng tìm ra một Authoritative DNS server chịu trách nhiệm phân giải tên miền doxdns1.com.

3- Dan Kaminsky sử dụng chính tên miền doxdns1.com này để thiết lâp hai name server (DNS server) là
NS1.DOXDNS1.COM (Primary)
NS2.DOXDNS1.COM
Trên NS1.DOXDNS1.COM Kaminsky chỉ cấu hình một domain là: doxdns1.com, không có bất cứ domain nào khác. Vì vậy NS1.DOXDNS1.COM chính là Authoritative DNS server của xxxxxx.doxdns1.com , thí dụ cb99895908f6.doxdns1.com và là Authoritative DNS sever duy nhất trên mạng của những domain này.
Vì lý do trên các recursive DNS server của các ISP đều phải hỏi NS1.DOXDNS1.COM để phân giải tên miền xxxxxxx.doxdns1.com cho ta. Nghĩa là các DNS server này phải mở các cổng kết nối (source ports) trên server để gửi các gói tin truy vấn đến NS1.DOXDNS1.COM.

4- Do thiết kế một hệ thống như vậy nên Admin. của DNS server NS1.DOXDNS1.COM có thể thu thập đầy đủ các thông tin kết nối từ các ISP recursive DNS server, xác định xem chúng có mở các cổng kết nối (source port) một cách ngẫu nhiên hay không, hay chỉ mở cố định một cổng. (Nếu DNS server nào mở ngẫu nhiên các cổng nguồn thì Dan Kaminsky cho là recursive DNS server ấy an toàn -safe).

5- Nhưng Tool check DNS server của Dan Kaminsky lại tích hợp trên website www.doxpara.com, như ta đã thấy.
Website này hosting trên một webserver cũng có tên là doxpara.com của chính Dan Kaminsky. Webserver này có IP là 157.22.245.20 và đặt tại California - Palo Alto - Zocalo. Trong khi Name server NS1.DOXDNS1.COM nói trên thì lại đặt tại California - Redwood City, trong khuôn viên của Internet Systems Consortium Inc (ISC), cũng xa nơi đặt webserver doxpara.com. IP của NS1.DOXDNS1.COM là 149.20.56.5, như đã nói ở trên.

Do đó để theo rõi và cập nhật kịp thời (tức khắc) các thông tin kết quả kiểm tra DNS của "khách hàng" từ NS1.DOXDNS1.COM đến webserver doxpara.com, Dan Kaminsky đã cài SunRPC (SUN Remote Procedure Call) tai port 111 với các portmapper, Ver : 2, 3, 4 (tại port TCP 111, UDP 111) trên OS cài Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.1 của webserver.

Cũng vì lý do này Dan Kaminsky đã từng phàn nàn về NAT, đây là NAT trên modem hay router đặt trứoc webserver doxpara.com của Dan Kaminsky.

Tìm hiểu về cơ chế và hệ thống check DNS server của Dan Kaminsky ta có thể giải thích các trừong hợp mà tool này trục trặc trong checking hay có khi cho kết quả sai trong một số trừong hợp, như các bạn đã dẫn ra.

Ghi chú: Những thông tin trên đây là do tôi tự ngâm cứu, tìm hiểu, check trên mạng, suy luận, không lấy từ bất cứ nguồn thông tin nào khác sẵn có. Vì vậy có thể có chi tiết sai sót. Xin các bạn chỉ giáo thêm.

Đã chỉnh lại một vài điểm trên bài viết. Thank boom_it

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ú ý	31/07/2008 10:53:02 (+0700) \| #76 \| 144393

boom_jt
Member

Joined: 02/08/2007 23:51:10
Messages: 125
Offline

boom xin phép chỉ ra 1 điểm sai trong bài viết của bác PXMMRF về cơ chế của DAN nha:

PXMMRF wrote:

trình duyệt của ta sẽ khởi sự những cố gắng đầu tiên để kết nối đến đến địa chỉ:
http://cb99895908f6.doxdns1.com/...

Xin nói rằng đoạn string đặt trước doxdns1.com được sinh ngẫu nhiên, chứ không phải mỗi lần kiểm tra đều sử dụng domain đó. Điều này có thể được kiểm chứng bằng cách đọc code javascript.
Từ sai lầm này dẫn đến sai lầm tiếp theo liên quan đến DNS server của Dan dựng lên mà ta có thể thấy rõ nếu đọc kĩ những bài thảo luận từ đầu tới h.

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý	31/07/2008 11:16:56 (+0700) \| #77 \| 144395

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

OK! Tôi đã xem lại JavaScript trên source code và thấy xxxxxx, trong xxxxxx.doxdns1.com đựoc tao một cách ngẫu nhiên và cb99895908f6 là một giá trị. Những nôi dung sau của bài viết vẫn đúng . Boom_it phải cần check thật kỹ lại. Xác định kỹ từng phần.

Những phần (đoạn): xxxxx trong xxxxx.doxdns1.com chỉ là sub của domain chính (mẹ): doxdns1.com.
Có thể truy cập và xem trang mở đầu của website với tên miền này: http://cb99895908f6.doxdns1.com
Cũng như có thể truy cập xem đựoc website: http://doxdns1.com
Nôi dung 2 website là như nhau. Config như vậy không khó gì!

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ú ý	31/07/2008 11:36:46 (+0700) \| #78 \| 144397

boom_jt
Member

Joined: 02/08/2007 23:51:10
Messages: 125
Offline

Vậy boom xin phép được nói điểm tiếp theo boom cảm thấy chưa đúng nhé:

PXMMRF wrote:

Vì tên miền cb99895908f6.doxdns1.com là rất mới, rất đặc biệt (do Dan Kaminsky vừa mới thiết lập cho mục đích checking DNS server) nên tất cả các recursive DNS server của các ISP Việt nam và thế giới không thể có nó trong cache.

Đây chính là sai lầm kéo theo mà boom nhắc tới. Nếu domain dùng để check là cố định thì chỉ cần 1 user của 1 DNS server nào đó vào test ở doxpara là DNS server đó đã lưu thông tin lại rồi, đâu còn là mới nữa? 1 DNS server có rất nhiều người dùng sử dụng thì có thể nói 1 cách tương đối là tên miền kia ko còn "mới" với số người dùng này.

PXMMRF wrote:

Trên NS1.DOXDNS1.COM Kaminsky chỉ cấu hình một domain là: doxdns1.com, không có bất cứ domain nào khác.

Theo boom phỏng đoán thì mục đích của con DNS này chỉ là kiểm tra source port và (đoạn sau này boom chưa dám khẳng định chắc chắn) xem câu trả lời với Addition RRs của nó có được chấp nhận hay ko. Vì vậy nó không cấu hình sẵn 1 subdomain nào cả...

PXMMRF wrote:

Có thể truy cập và xem trang mở đầu của website với tên miền này: http://cb99895908f6.doxdns1.com
Cũng như có thể truy cập xem đựoc website: http://doxdns1.com
Nôi dung 2 website là như nhau. Config như vậy không khó gì!

Boom đã thử sửa domain cb99895908f6.doxdns1.com thành cb99895908f4.doxdns1.com và kết quả cũng vậy thôi, vì vậy cb99895908f6.doxdns1.com chỉ là 1 giá trị ngẫu nhiên bình thường, như các giá trị khá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ú ý	31/07/2008 11:59:03 (+0700) \| #79 \| 144402

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

boom_jt wrote:

Vậy boom xin phép được nói điểm tiếp theo boom cảm thấy chưa đúng nhé:

PXMMRF wrote:

Vì tên miền cb99895908f6.doxdns1.com là rất mới, rất đặc biệt (do Dan Kaminsky vừa mới thiết lập cho mục đích checking DNS server) nên tất cả các recursive DNS server của các ISP Việt nam và thế giới không thể có nó trong cache.

A-Đây chính là sai lầm kéo theo mà boom nhắc tới. Nếu domain dùng để check là cố định thì chỉ cần 1 user của 1 DNS server nào đó vào test ở doxpara là DNS server đó đã lưu thông tin lại rồi, đâu còn là mới nữa? 1 DNS server có rất nhiều người dùng sử dụng thì có thể nói 1 cách tương đối là tên miền kia ko còn "mới" với số người dùng này.

PXMMRF wrote:

Trên NS1.DOXDNS1.COM Kaminsky chỉ cấu hình một domain là: doxdns1.com, không có bất cứ domain nào khác.

B-Theo boom phỏng đoán thì thậm chí trên con DNS này không hề có thông tin của cb99895908f6.doxdns1.com hay các domain tương tự. Mục đích của con DNS này chỉ là kiểm tra source port và (đoạn sau này boom chưa dám khẳng định chắc chắn) xem câu trả lời với Addition RRs của nó có được chấp nhận hay ko.

A OK! Thì điểm này tôi đã chỉnh lại. Thanks! Sub domain trong từng request từ DNS client gửi đến recursive DNS server phải thay đổi đoạn trên cùng (XXXX) thì recursive DNS server mới tạo ra nhiều kết nối đến Authoritative DNS server, thì mới biết source port có thay đổi hay không chứ!

B
Trên NS1.DOXDNS1.COM, tại Zone của nó phải có tên miền mẹ doxdns1.com chứ, nếu không thì làm sao 13 Root DNS server lại có thể gửi thông báo "nhắc" recursive DNS server của ISP là phải kết nối đến NS1.DOXDNS1.COM để đựoc phân giải các tên miền xxxx.doxdns1.com hay doxdns1.com. Trên mạng có tới hàng ngàn, hàng chục ngàn DNS server, hay hơn, quản lý tên miền cha ".com" đấy. Em cần đọc kỹ lại bài anh viết về trình tư phân giải tên miền ở post tại trang 3, topic này.
Ngoài ra nếu trên Zone của NS1.DOXDNS1.COM mà config. thêm một domain khác như dell.com chẳng hạn thì kết quả check DNS sẽ rối phải không? Nghĩ lại xem! Thanks

Một trong các bằng chứng đây nè:

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ú ý	31/07/2008 12:08:14 (+0700) \| #80 \| 144405

boom_jt
Member

Joined: 02/08/2007 23:51:10
Messages: 125
Offline

hi, boom rất vui vì bác PXMMRF xưng hô anh-em với boom ^^, hì hì mặc dù boom cũng có biết mình còn kém tuổi bác kha khá - đã xem ảnh bác offline với anh em rồi ạ ^^

Về ý B thì boom muốn nói là DNS server của Dan không hề cấu hình sẵn 1 subdomain cụ thể nào cả, nó có thể được cấu hình để trả lời cho *mọi* subdomain, hoặc được chỉnh trong code. Còn việc NS1.DOXDNS1.COM được đăng kí là authoritative cho doxdns1.com và mọi subdomain của nó thì là chuyện tất nhiên rồi. (ở đây boom giả sử ko còn 1 DNS con nào của thằng này 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ú ý	31/07/2008 12:45:56 (+0700) \| #81 \| 144406

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

boom_jt wrote:

hi, boom rất vui vì bác PXMMRF xưng hô anh-em với boom ^^, hì hì mặc dù boom cũng có biết mình còn kém tuổi bác kha khá - đã xem ảnh bác offline với anh em rồi ạ ^^

Về ý B thì boom muốn nói là DNS server của Dan không hề cấu hình sẵn 1 subdomain cụ thể nào cả, nó có thể được cấu hình để trả lời cho *mọi* subdomain, hoặc được chỉnh trong code. Còn việc NS1.DOXDNS1.COM được đăng kí là authoritative cho doxdns1.com và mọi subdomain của nó thì là chuyện tất nhiên rồi. (ở đây boom giả sử ko còn 1 DNS con nào của thằng này nhé ^^)

Ít nhất phải có 1 sub domain chứ. Nếu không làm sao có và xem đựoc trang web này từ trình duyệt:
http://cb99895908f6.doxdns1.com
(Ở đây không có hiện tượng URL wwwection đâu đấy).

Ngoài ra nếu tôi là Dan Kaminsky thì tôi cũng vẫn tạo các domain con (sub domain) trên zone tương ứng với các session kết nối, vì như thế hệ thống kiểm tra mới làm việc ổn định.

Gọi boom_it là em cho nó trẻ ra hơn một chút. Hì hì

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ú ý	31/07/2008 13:34:10 (+0700) \| #82 \| 144418

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

PXMMRF: boom_jt nói đúng, cái này chỉ cần tạo một cái wildcard record là được. Hồi trước khi demo cái DNS Rebinding Attack, em cũng làm như thế. Cấu hình đại loại thế này:

Code:

*.doxdns1.com IN CNAME dan-kaminsky.scanning.browse-http-on-this-site.doxdns1.com
dan-kaminsky.scanning.browse-http-on-this-site.doxdns1.com IN A 149.20.56.5

--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ú ý	31/07/2008 14:19:52 (+0700) \| #83 \| 144427

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

mrro wrote:

PXMMRF: boom_jt nói đúng, cái này chỉ cần tạo một cái wildcard record là được. Hồi trước khi demo cái DNS Rebinding Attack, em cũng làm như thế. Cấu hình đại loại thế này:

Code:
*.doxdns1.com IN CNAME dan-kaminsky.scanning.browse-http-on-this-site.doxdns1.com
dan-kaminsky.scanning.browse-http-on-this-site.doxdns1.com IN A 149.20.56.5
--m

Nhất trí với mrro. Boom_it đã nói đúng, tôi cũng đã thử lại với các giá trị bất kỳ của đoạn đầu xxxxx của subdomain xxxxx.doxdns1.com và đều thấy đựoc. Điểm này boom_it khá thông minh đấy. Hì hì

to:boom_it Em thử check cái www.doxpara.com và lấy dùm anh vài cái thông tin về lão Dan Kaminsky đi. Không phải là thông tin có link sẵn trên website đâu nhé. Một vài bài viết hay một vài thứ khác ấy! Thanks (for j/k only. Hì hì)

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ú ý	31/07/2008 15:27:24 (+0700) \| #84 \| 144430

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

mrro wrote:

sao mà so với "bắt virus sỉ và lẻ" được, nên tôi mới có kết luận như vậy. thôi thì cứ coi như đó là kết luận của riêng tôi, tôi dốt thì tôi chịu vậy.

--m

Gì vậy, hình như mrro có cùng sự nhầm lẫn giống lQ:
1. Tui ko fải là hoanghono
2. Tui cũng ko fải là người của trung tâm "sỉ và lẻ" nốt
Đính chính lại tí xíu. Mọi người thảo luận tiếp nha

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý	31/07/2008 16:35:06 (+0700) \| #85 \| 144433

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

LeVuHoang wrote:

Gì vậy, hình như mrro và lq có sự nhầm lẫn ở đây thì phải.

Haha đùa thôi bồ ơi :p. Còn cái vụ của lQ, thì cũng là đùa, đừng xem nó nghiêm trọng nhé :-p. Có lẽ lQ nói đùa nhưng mà kô biết cách nói đó :-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ú ý	02/08/2008 00:19:33 (+0700) \| #86 \| 144657

ilikehack
Member

Joined: 31/07/2008 19:32:46
Messages: 1
Offline

Nói đến vấn đề này mình xin nhờ các anh tư vấn giúp 1 vần đề như sau
;
em co 1 www.abc.com va hosting tại một nhà cung cấp hosting .
- Như vậy khi nhà cung cấp hosting die ===> Ko thể access vào www.abc.com
Vậy chỉ còn cách là chúng ta thuê một hosting khác để nhờ họ giải quyết giúp cái vần đề hostign và phân giải thằng www.abc.com
- Ngoai cách này ra ta có thề yêu cầu thằng cung cấp hosting delegate dns cho mình để về công ty mình quản lý thì có giải quyết đc vấn đề không ?

Em ko rành về DNS cho lắm ... Nên chắc câu hỏi này hơi ngu ngơ hiii.

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý	02/08/2008 03:57:04 (+0700) \| #87 \| 144697

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

ilikehack wrote:

Nói đến vấn đề này mình xin nhờ các anh tư vấn giúp 1 vần đề như sau
;
em co 1 www.abc.com va hosting tại một nhà cung cấp hosting .
- Như vậy khi nhà cung cấp hosting die ===> Ko thể access vào www.abc.com
Vậy chỉ còn cách là chúng ta thuê một hosting khác để nhờ họ giải quyết giúp cái vần đề hostign và phân giải thằng www.abc.com
- Ngoai cách này ra ta có thề yêu cầu thằng cung cấp hosting delegate dns cho mình để về công ty mình quản lý thì có giải quyết đc vấn đề không ?

Em ko rành về DNS cho lắm ... Nên chắc câu hỏi này hơi ngu ngơ hiii.

Thắc mắc cụ thể về DNS trên bình diện hosting thì vào mục "Networking" mà tạo chủ đề mới. Đừng chen vào một chủ đề để hỏi thắc mắc riêng của mình.

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ú ý	02/08/2008 04:05:50 (+0700) \| #88 \| 144700

maithangbs
Elite Member

Joined: 28/11/2007 21:39:53
Messages: 567
Location: Д.и.Р
Offline

Đề nghị các bác post ở topic này khi edit lại thông báo giùm.
Em thấy một số post, đọc lúc đầu khác, lúc sau đọc khác luôn, ví dụ như đoạn này

Còn việc nhận định của Mrro về việc không cần phải vá lỗi là hoàn toàn sai lầm. Đồng ý là việc vá lỗi có thể phải kéo dài, cần phải cân nhắc nhiều yếu tố, có thể mất thời gian, nhưng chắc chắn là phải vá lỗi. Có thể việc này đòi hỏi phải có 1 kế hoạch kỹ càng, cần kiểm tra kỹ lưỡng trước khi triển khai thực tế đối với các hệ thống lớn, nhưng không thể không thực hiện. Mrro làm trong lĩnh vực ngân hàng mà có nhận định như vậy thì thật là yếu. Ngân hàng, tài chính đòi hỏi sự an ninh cao độ, việc vá lỗi đòi hỏi phải có kế hoạch chi tiết, cụ thể, nhưng không thể là không tính cách để vá lỗi. Đặc biệt là lỗ hổng nghiêm trọng như lỗ hổng DNS này.

Chắc chắn lúc đầu bạn reply là không có đoạn này đâu.
Các bác sửa lại bài reply mà không nói gi cả là không trung thực nhá (Nhại lời bác conmale).

[Question] Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý	06/08/2008 13:56:49 (+0700) \| #89 \| 145378

PXMMRF
Administrator

Joined: 26/09/2002 07:17:55
Messages: 946
Offline

Đã mấy ngày rồi mà chưa thấy ai viết thêm bài nào trong chủ đề này. Một chủ đề rất hay và đang được nhiều chuyên gia tin học trên TG quan tâm. Thôi thì tôi xin mạo muội viết thêm đôi điều, để hâm nóng lại không khí thảo luận.

Có một vài bạn có email trao đổi với tôi để muốn thấy rõ thêm về bản chất của quá trình mà trình duyệt của ta gửi các subdomain, được tạo ra một cách ngẫu nhiên, (từ domain doxdns1.com), đến recursive DNS server và sau đó được "forward" đến NS1.DOXDNS1.COM, (một Authoritative DNS server do Dan Kaminsky mới thiết lâp). Quá trình này được thưc hiện trên tiện ích kiểm tra độ an toàn của các ISP recursive DNS server, tiện ích đang tích hợp trên website www.doxpara.com, cũng do Dan Kaminsky thiết lập.

Khi tập trung tìm hiểu, xác định sơ đồ mạng, nguyên lý hoạt động mà Dan Kaminsky thiết lập, phục vụ cho việc kiểm tra độ an toàn của các ISP recursive DNS server, tôi không chú ý nhiều đến chi tiết của quá trình nói trên.
Sau đó bạn boom_it đã hiệu chỉnh chi tiết thiếu sót trong bài viết.

Nay tôi xin nói rõ thêm về quá trình này để các bạn tham khảo. Vả lại còn một lý do khác cần nói. Đó là việc poisoning cache một DNS servver có thể liên quan đến quá trình này, hacker có thể tận dụng quá trình này: quá trình DNS WILDCARDS. Ngoài ra, Dan Kaminsky cũng có thể ít nhiều đề cập đến quá trình này trong tham luận về poisoning cache một DNS server, mà anh ta sẽ trình bầy tại Black Hat forum vào ngày 6.8.08 sắp tới.

I- ĐÔI NÉT VỀ DNS WILDCARDS

Cơ cấu DNS "Wildcard" (DNS "wildcard" mechanism) là một phần của giao thức DNS. Cơ cấu này đã được định nghĩa, mô tả và xác định (tuy chưa đầy đủ, hoàn chỉnh) cách đây hơn 20 năm, từ năm 1987, trong "RFC 1034", RFC này tôi đã nói đến ở bài viết phía trên. Ý nghĩa cơ bản của DNS Wildcards ở chỗ chúng là các qui định cho phép một Authoritative DNS server (một máy chủ chịu trách nhiệm chính trong việc phân giải tên miền) có thể tiếp nhân các truy vấn và trả lời chúng trong trường hợp nôi dung các truy vấn này thay đổi (on the fly).

DNS Wildcards sử dụng các DNS Wildcard records (dữ liệu ghi DNS Wildcard), cơ chế của nó đơn giản để hiểu qua, nhưng lại phức tạp trong chi tiết và trong sử dụng. DNS Wilcard records là những dữ liệu trong DNS file (Zone file), chúng tương thích (đáp ứng) với tất cả các truy vấn, mà các truy vấn này liên quan đến yêu cầu phân giải các tên miền(domain) hay tên miền con (subdomain) thưc tế không tồn tại.
Đó có thể là các domain (hay subdomain) bị cấm dùng (1), chưa từng đựoc đăng ký (2) (thí du domain:
"hoan-ho-ban-boom-it.com" chẳng hạn), hay đã đăng ký mà chưa đựoc sử dụng (3) (inactive domain- tên miền chưa đựoc người sở hữu tạo lập [create] một host để hosting nó- nghĩa là chưa đựoc bất kỳ một Authoritative DNS server nào quản lý). Khi người truy cập Internet đánh một tên miền không tồn tại trên thưc tế nói trên tại thanh địa chỉ trình duyệt, thay vì nhận được một HTTP error code thông báo:"Error 404" như thường lệ, thì trong trừong hợp DNS wildcards được áp dụng, trình duyệt của người truy cập bị dẫn đến một trang web khác. Trang web này có thể là một trang web hỗ trợ việc tìm kiếm trên mạng (thường kèm quảng cáo), hay trang web của tên miền mẹ, thí dụ đến webpage có tên miền doxdns1.com, trong trừong hơp DNS wildcard với các subdomain, thí dụ xxxxxx.doxdns1.com (với đoạn [part] "xxxxx" là nhóm các ký tự bất kỳ, có thể tạo ra một cách ngẫu nhiên).

Khi nói DNS Wildcard đáp ứng các tên domain và subdomain thưc tế không tồn tại, thì phải phân biệt hai trường hơp áp dụng cho domain và cho riêng subdomain. Trong trường hợp domain, thí dụ các TLD, như .com, .net, thì với DNS Wildcards, nếu ta đánh trên trình duyệt một domain không có thưc , thí dụ "137h7w83ss.com", trình duyệt sẽ của ta sẽ bị dẫn đến một trang web tìm kiếm trên mạng.

Cần chú ý là tên miền "137h7w83ss.com" thì không có thưc, nhưng tên miền cha ".com" thì có (đúng ra phải viết là ".com."). Nhiều DNS server quản lý các tên miền có hậu tố DNS là .com trên TG.

Cũng như vậy khi ta DNS wildcard với các subdomain (được tạo ra từ một domain "mẹ"), như xxxxxx.doxdns1.com, thí dụ ad345c92ss.doxdns1.com, thì phải hiểu là tên miền ad345c92ss.doxdns1.com (nếu xem xét toàn bộ tên miền này) thì không có trong thưc tế, nhưng tên miền mẹ doxdns1.com phải có trong thưc tế, phải ghi trong Zone file của một Authoritative DNS server nào đấy (kèm một configuration thích hợp). Thí dụ tại Authoritative DNS server NS1.DOXDNS1.COM của Dan Kaminsky, config. trên BIND 9 để thực hiện quá trình DNS Wildcard có thể phải như sau:

; wildcard subdomains are all directed to this IP
; of course this should be the IP of your web server
*.doxdns1.com IN A 149.20.56.1

Hay có thể config. theo một cách khác với hiệu quả tương tự, như trong một trừong hợp khác.

Code:

*.example.com   3600  MX   10 host1.example.com

( Cũng như có thể theo hướng dẫn của bạn mrro tại bài viết phía trên)

(DNS Wildcards records đựoc thể hiện với một dấu sao "*" (asterisk) duy nhất nắm ở phía bìa trái
"domain label" hay "subdomain label", thí dụ: *.hvaonline.net hay *.doxdns1.com hay *.com....
Dấu sao "*" nếu ở vị trí khác trong domain hay subdomain, thí dụ như *pxm.hvaonline.net hay pxm.*.hvaonline.net thì không phải là DNS Willdcard records)

II- NHỮNG TRỤC TRẶC KỸ THUẬT DNS WILDCARDS GÂY RA CHO HỆ THỐNG DNS

Sự sử dụng không đúng cách hay sự lạm dụng một cách bừa bãi DNS WILDCARDS có thễ gây ra những trục trặc kỹ thuật nghiêm trọng cho hệ thống DNS của một cơ quan, ISP hay của một công ty đăng ký tên miền, cũng như ảnh hưởng đến kết cấu DNS toàn cầu. Tuy nhiên, theo tôi, chính yếu tố dễ gây trục trặc nói trên lại là yếu tố mà các hacker có thể lợi dung, tận dụng trong quá trình nhiễm độc bộ nhớ đệm của DNS server (cache poisoning). Một vài tác giả cũng đã đề cập sơ bộ đến vấn đề này.

Khi hệ thống DNS hoạt động bình thường, theo các chuẩn mưc qui định, thì quá trình phân giải tên miền chỉ đơn giản là một quá trình truy vấn để được trả về câu trả lời với các resource records (RRs) nội dung phù hợp với từng yếu tố: QNAME (tên miền truy vấn), QCLASS (lọai dữ liệu truy vấn, như A record, NS, CNAME, SOA...) và QTYPE (kiểu truy vấn: như Intenet hay CHAOS...). Khi hệ thống DNS họat động ổn định như nói ở trên, sẽ xảy ra một trong 3 khà năng:

- Success (giaodich- truy vấn thành công).
Khi 3 yếu tố QNAME, QCLASS, QTYPE của nôi dung truy vấn phù hợp hòan tòan, chính xác với các yếu tố tương quan (NAME, CLASS, TYPE) trong nội dung RRs trả lời.
- No data (không có dữ liệu)
Khi QNAME, QCLASS phù hợp còn QTYPE thì không. Nghĩa lả tên miền truy vấn hiện diện trên Zone file nhưng không tìm thấy dữ liệu phù hợp với QTYPE.
- No such home (không có tên miền)
Khi QNAME và QCLASS không phù hợp, nghĩa là không tìm thấy tên miền trên Zone file.

Tuy nhiên khi DNS WILCARDS được áp dụng trên hệ thống DNS thì các điều kiện qui định để hệ thống họat động chính xác, ổn định trở nên rất phức tạp. Vì vậy hệ thống sẽ thường làm việc thiếu ổn định,.
Sự thiếu ổn định đăc biệt ở chỗ là khi có sự phù hợp chính xác yếu tố QCLASS trong quá trình truy vấn-trả lời lại không thể có một sự phù hợp như vậy đối với yếu tố QNAME. Sự phù hợp được xem là tốt nhất cho QNAME trong trừong hợp này lại là một "WILDCARD". Sau đó nếu có sự phù hợp yếu tố QTYPE thì hệ thống sẽ thông báo là quá trình truy vấn cho kết quả "Success", như nói ở trên. Còn ngựoc lại thì hệ thống thông báo là "No data". Quá trình thông báo đến recursive DNS server (resolver) sẽ diễn ra như trong trừong hợp bình thừong (không DNS WILCARD). Nhưng rõ ràng đấy lại không phải là kết quả đúng, thưc sự của quá trình WILDCARD.

Tình hình sẽ nghiêm trong hơn nếu quá trình DNS WILDCARD diễn ra liên tục với hàng lọat truy vấn từ phía nhiều ngừời truy cập, đặc biệt là khi hacker gửi dồn dập, đồng thời nhiều gói tin truy vấn WINDCARD về phía DNS server. Hệ thống DNS sẽ rơi vào tình trang phát sinh liên tục, hàng lọat RRs nhằm đáp ứng yếu tố QNAME trong truy vấn mà yếu tố này vốn luôn thay đổi, biến động (on the fly), nên rất dễ mất ổn định, ngưng trệ.
Một điểm yếu quan trọng và có thể coi là nguy hiểm của WILCARD record còn ở chỗ nó tương tác, đáp ứng rất kém trong các trường hơp mà hiệu quả họat động của hệ thống DNS tùy thuộc vào việc nó cho ra kết quả "no such home" có chính xác hay không. Những trường hợp này trong thưc tế rất nhiều.
Quá trình DNS WILCARDS vì thế đựoc khuyến cáo là nên hạn chế sử dụng. Chỉ nên sử dụng với mục đích duy nhất là: áp dụng cho MX record, trong thư điện tử.

Chính vì lý do trên mà gần đây Hội đồng quản lý tên miền của Úc đã công bố một chính sách cấm sử dụng WILDCARD DNS RECORDS trong rất nhiều trừong hợp, cụ thể như sau:

- Cấm áp dụng WILDCARD DNS RECORDS cho tất cả các tên miền cấp cao (TLD) như .com, .net....và cho các Zone đựoc kết nối với cộng đồng Internet.
- Cấm áp dụng WILDCARD DNS RECORDS cho tên miền quốc gia Úc ".au" và các tên miền cấp hai liên quan, thí dụ ".com.au" hay ".net.au".... (Ở Việt nam tên miền tương đựong là " .vn" và thí dụ ".com.vn")
- Cấm áp dụng WILDCARD DNS RECORDS với cả tên miền cấp 3 liên quan đến tên miền cha .au, thí dụ .com.com.au.
Xem chi tiết tại:
http://www.auda.org.au/policies/auda-2007-02/
Tham khảo thêm một Advisory của ICANN tại:
http://www.icann.org/en/announcements/advisory-19sep03.htm

Tuy nhiên ở đây ta chỉ chú ý đến một vấn đề khác của DNS WILDCARD. Đó là khả năng hacker tận dụng nó để tấn công đầu độc cache của DNS server theo một cách cải tiến từ cuộc tấn công "BirthDay Paradox" hay phối hợp với một cuộc tấn công "BirthDay Paradox", để làm cho DNS server rơi vào trạng thái mất ổn định, cơ cấu tạo việc mở cổng nguồn một cách ngẫu nhiên trong DNS server giảm hiệu quả và hệ thống có thể bị nhiễm độc nhanh chóng (khi đó giá trị k của sự kiện có thể giảm nhỏ đến mức thấp nhất và xác xuất thành công của hacker tăng lên rất cao), cho dù DNS server có mở cổng nguồn khi truy vấn một cách ngẫu nhiên hay không.

Như là US-CERT đã nhận định trong thông báo gần đây, tại http://www.kb.cert.org/vuls/id/457875 :

..............
As expected, the traditional brute-force case where the attacker tries to guess the transaction ID or TID/port pair based on a single open request requires the attacker to search half the search space (15 or 31 bits, respectively) to achieve a 50% probability of success. However, when the attacker is able to induce the resolver into generating multiple simultaneous requests, the total number of packets required falls off rapidly.
.....................

Có thời gian chúng ta sẽ phân tích vấn đề này sâu hơn.

Vài ý thô thiển, có gì sai sót xin các bạn chỉ giáo thêm. Thanks

TPHCM August 5, 2008_ PXMMRF

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ú ý	06/08/2008 22:20:08 (+0700) \| #90 \| 145408

crazyboy_alias
Member

Joined: 03/07/2008 01:47:32
Messages: 60
Offline

hơ,sao bài post của em hum trước lại ko thấy đâu nữa thế này,cả ở mấy topic khác cũng thế.Lạ quá

Go to:

Users currently in here
1 Anonymous