<![CDATA[Latest posts for the topic "(Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý"]]> /hvaonline/posts/list/13.html JForum - http://www.jforum.net (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý Tận dụng lỗ hổng này, kẻ xấu có thể tấn công để đánh cắp tất cả thông tin trên Internet của bạn, chẳng hạn như chiếm quyền điều khiển blog của bạn, chôm mật khẩu để đọc trộm email hay giả danh bạn để chat trên Yahoo! Messenger. Tôi nhắc lại, khi khai thác thành công lỗ hổng này, kẻ xấu hoàn toàn có thể chiếm quyền điều khiển cuộc sống online của bạn. Bài này được viết để cung cấp thêm cho các bạn những thông tin cần biết về lỗ hổng này, cũng như các phương pháp phòng chống tạm thời, cho đến khi có giải pháp triệt để từ phía các ISP ở VN. --- 1. Giới thiệu về DNS DNS viết tắt của Domain Name System, là hệ thống quản lý việc ánh xạ giữa địa chỉ của máy tính trên Internet với tên của chúng. Trên Internet, mỗi máy tính đều được cấp một địa chỉ riêng biệt, thường được gọi là IP address, tạm dịch là địa chỉ IP (IP viết tắt của Internet Protocol, giao thức điều khiển việc trao đổi thông tin liên lạc giữa hai máy tính trên Internet). Địa chỉ IP thường dài và khó nhớ, phù hợp với máy tính, không phù hợp với trí nhớ của con người (thường chỉ có khả năng nhớ được tối đa 7 số tại một thời điểm), do đó người ta mới đặt cho mỗi máy tính một cái tên dễ nhớ, chẳng hạn như www.vnexpress.net, www.yahoo.com, www.tuoitre.com.vn..., rồi sử dụng hệ thống DNS nói trên để ánh xạ những tên này vào các địa chỉ IP thực sự của chúng. Khi bạn gõ www.vnexpress.net vào trình duyệt và nhấn enter, máy tính của bạn sẽ hỏi máy chủ DNS của bạn (thường là máy chủ do ISP của bạn quản lý) địa chỉ của www.vnexpress.net là bao nhiêu. Máy chủ DNS của bạn sẽ đi hỏi những máy chủ DNS khác trên Internet, để rồi cuối cùng trả lời cho máy tính của bạn rằng, www.vnexpress.net chính là tên miền của máy tính có địa chỉ IP là 210.245.0.22. Máy tính của bạn sẽ căn cứ vào địa chỉ này để liên lạc với www.vnexpress.net và lấy về nội dung mà bạn muốn xem. Nếu bạn nào sống ở Mỹ hay các nước tiên tiến, thì có thể hiểu hệ thống DNS tương tự như hệ thống Postal/Zip Code, dùng để ánh xạ giữa zip code với địa chỉ nhà bạn. 2. Thông tin chi tiết về lỗi Lỗi tấn công ở đây xảy ra khi máy chủ DNS của bạn bị kẻ xấu cố tình cung cấp thông tin sai lệch, khiến nó nhầm tưởng địa chỉ IP của www.vnexpress.net không phải là 210.245.0.22 mà lại là một địa chỉ IP của một máy tính nằm trong sự điều khiển của hắn. Thuật ngữ chuyên ngành gọi đây là DNS cache poisoning attack. Khi đó, lúc bạn gõ www.vnexpress.net, thay vì nhận được nội dung từ trang VnExpress thật, bạn sẽ nhận được nội dung giả mạo từ phía kẻ xấu. Điều nay cực kỳ nguy hại, bởi lẽ áp dụng kỹ thuật này, kẻ xấu có thể mạo danh tất cả các website trên thế giới, từ Google, Yahoo, Microsoft, Paypal hay website của ngân hàng hay công ty chứng khoán của bạn. Khi đã mạo danh các website này rồi, kẻ xấu sẽ có thể đánh cắp được tất cả tài khoản cá nhân của bạn trên những website này. Nếu bạn đọc kỹ, bạn sẽ thấy kẻ xấu không trực tiếp tấn công vào máy tính của bạn, mà tấn công vào máy chủ DNS của bạn (do ISP của bạn quản lý và cung cấp lại cho bạn sử dụng). Thật tế dạng tấn công này đã được thực hiện từ khá lâu và cũng đã có nhiều cách phòng chống hiệu quả, nhưng những kết quả nghiên cứu của các chuyên gia trên thế giới gần đây cho thấy, kẻ xấu có thể thực hiện việc tấn công này một cách rất dễ dàng. Một số nguồn tin cho rằng chỉ cần dưới 10s là kẻ xấu có thể tấn công một máy chủ DNS chưa được sửa lỗi. 3. Tình trạng các máy chủ DNS ở VN Ngay khi phát hiện ra lỗ hổng này, các chuyên gia trên thế giới đã làm việc với nhau để tìm ra các phương pháp sửa lỗi. Các hãng phần mềm đều đã có cung cấp bảng vá lỗi cho phần mềm máy chủ DNS của họ. Tuy vậy, theo tìm hiểu của tôi, mặc dù các bảng vá đã được phát hành gần 2 tuần, nhưng tất cả các máy chủ DNS của các ISP VN như FPT, VDC, Vietel, SCTV...đều chưa được vá lỗi. Điều này có nghĩa là tất cả những ai sử dụng dịch vụ Internet (dial-up, ADSL hay leased line) của các ISP này đều có thể bị tấn công như mô tả ở trên. Theo thông tin từ VNCERT, Đội phản ứng nhanh về các sự cố máy tính VN, họ cũng đã có cung cấp thông tin cho các ISP từ vài tuần trước, nhưng không nhận được phản hồi. Theo tôi được biết, trong nay mai, sẽ có một thông cáo báo chí của VNCERT về vấn đề này, để yêu cầu sự hợp tác từ phía các ISP. 4. Giải pháp tạm thời Giải pháp tạm thời là không sử dụng Internet nữa, cho đến khi nào có thông tin mới. Haha tôi nói đùa đó :D. Giải pháp tạm thời là thay vì sử dụng máy chủ DNS của các ISP VN, các bạn hãy chuyển sang sử dụng máy chủ DNS của công ty OpenDNS. Các máy chủ của OpenDNS đã được vá lỗi và công ty này cũng cho biết họ đã sẵn sàng để phục vụ chúng ta. Thông tin chi tiết về việc cấu hình máy tính sử dụng máy chủ DNS của OpenDNS, các bạn có thể xem ở đây. Nếu có khó khăn gì, cứ báo cho tôi biết, nếu tôi hỗ trợ được tôi sẽ hỗ trợ. 5. Thông tin tham khảo http://www.kb.cert.org/vuls/id/800113 http://isc.sans.org/diary.html?storyid=4687 Trước khi kết thúc, tôi muốn nhấn mạnh lại lần nữa đây là một lỗ hổng cực kỳ nghiêm trọng và ảnh hưởng trực tiếp đến mỗi người trong chúng ta. --m]]> /hvaonline/posts/list/23739.html#143030 /hvaonline/posts/list/23739.html#143030 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 0. The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat. 1. Pretend for the moment that you know only the basic function of DNS — that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up. Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob’s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice — once when he is called to the counter to place his order and again when he’s called back to get his sandwich. If you’re wondering, Bob likes ham on rye with no onions. If you’ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It’s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions. 2. Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic. First, QIDs. Bob’s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0. It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I’m Mallory and I’m attacking Bob, how can he distinguish my packets from Alice’s? Because I can’t see the QID in his request, and the QID in my response won’t match. The QID is the only thing protecting the DNS from Mallory (me). QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here’s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded —- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory’s response gets to your computer before the legitimate response arrives from your ISP’s name server, you will be wwwected where Mallory tells you you’re going. Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob’s request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race. But there’s a bunch more problems here: * If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win. * If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she’ll break the RNG and be able to predict its outputs. * 16 bits just isn’t big enough to provide real security at the traffic rates we deal with in 2008. Your computer’s resolver is probably a stub. Which means it won’t really save the response. You don’t want it to. The stub asks a real DNS server, probably run by your ISP. That server doesn’t know everything. It can’t, and shouldn’t, because the whole idea of DNS is to compensate for the organic and shifting nature of internet naming and addressing. Frequently, that server has to go ask another, and so on. The cool kids call this “recursion”. Responses carry another value, too, called a time to live (TTL). This number tells your name server how long to cache the answer. Why? Because they deal with zillions of queries. Whoever wins the race between Alice and Mallory, their answer gets cached. All subsequent responses will be dropped. All future requests for that same data, within the TTL, come from that answer. This is good for whoever wins the race. If Alice wins, it means Mallory can’t poison the cache for that name. If Mallory wins, the next 10,000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0. 3. Then there’s that other set of DNS vulnerabilities. These require you to pay attention in class. They haven’t really been talked about since 1997. And they’re hard to find, because you have to understand how DNS works. In other words, you have to be completely crazy. Lazlo Hollyfeld crazy. I’m speaking of course of RRset poisoning. DNS has a complicated architecture. Not only that, but not all name servers run the same code. So not all of them implement DNS in exactly the same way. And not only that, but not all name servers are configured properly. I just described a QID attack that poisons the name server’s cache. This attack requires speed, agility and luck, because if the “real” answer happens to arrive before your spoofed one, you’re locked out. Fortunately for those of you that have a time machine, some versions of DNS provide you with another way to poison the name server’s cache anyway. To explain it, I will have to explain more about the format of a DNS packet. DNS packets are variable in length and consist of a header, some flags and resource records (RRs). RRs are where the goods ride around. There are up to three sets of RRs in a DNS packet, along with the original query. These are: * Answer RR’s, which contain the answer to whatever question you asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4) * Authority RR’s, which tell resolvers which name servers to refer to to get the complete answer for a question * Additional RR’s, sometimes called “glue”, which contain any additional information needed to make the response effective. A word about the Additional RR’s. Think about an NS record, like the one that COM’s name server uses to tell us that, to find out where WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. That’s good to know, but it’s not going to help you unless you know where to find NS1.VICTIM.COM. Names are not addresses. This is a chicken and egg problem. The answer is, you provide both the NS record pointing VICTIM.COM to NS1.VICTIM.COM, and the A record pointing NS1.VICTIM.COM to 1.2.3.1. Now, let’s party like it’s 1995. Download the source code for a DNS implementation and hack it up such that every time it sends out a response, it also sends out a little bit of evil — an extra Additional RR with bad information. Then let’s set up an evil server with it, and register it as EVIL.COM. Now get a bunch of web pages up with IMG tags pointing to names hosted at that server. Bob innocently loads up a page with the malicious tags which coerces his browser resolve that name. Bob asks Alice to resolve that name. Here comes recursion: eventually the query arrives at our evil server. Which sends back a response with an unexpected (evil) Additional RR. If Alice’s cache honors the unexpected record, it’s 1995 —- buy CSCO! —- and you just poisoned their cache. Worse, it will replace the “real” data already in the cache with the fake data. You asked where WWW.EVIL.COM was (or rather, the image tags did). But Alice also “found out” where WWW.VICTIM.COM was: 6.6.6.0. Every resolver that points to that name server will now gladly forward you to the website of the beast. 4. It’s not 1995. It’s 2008. There are fixes for the attacks I have described. Fix 1: The QID race is fixed with random IDs, and by using a strong random number generator and being careful with the state you keep for queries. 16 bit query IDs are still too short, which fills us with dread. There are hacks to get around this. For instance, DJBDNS randomizes the source port on requests as well, and thus won’t honor responses unless they come from someone who guesses the ~16 bit source port. This brings us close to 32 bits, which is much harder to guess. Fix 2: The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if they’re asking where WWW.VICTIM.COM is, they’re not interested in caching a new address for WWW.GOOGLE.COM in the same transaction. Remember how these fixes work. They’re very important. And so we arrive at the present day. 5. Let’s try again to convince Bob that WWW.VICTIM.COM is 6.6.6.0. This time though, instead of getting Bob to look up WWW.VICTIM.COM and then beating Alice in the race, or getting Bob to look up WWW.EVIL.COM and slipping strychnine into his ham sandwich, we’re going to be clever (sneaky). Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Alice’s answer is NXDOMAIN, because there’s no such name as AAAAA.VICTIM.COM. Mallory has an answer. We’ll come back to it. Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM. Alice’s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0! Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didn’t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query. Mallory has combined attack #1 with attack #2, defeating fix #1 and fix #2. Mallory can conduct this attack in less than 10 seconds on a fast Internet link.   ]]> /hvaonline/posts/list/23739.html#143032 /hvaonline/posts/list/23739.html#143032 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý gái quê cũng đã có lần /hvaonline/posts/list/0/19736.html#117400.

Chị gái quê wrote:
2. Hacker rảnh wa' đi thay đổi pass để gây phiền phức ... trong khi đó Hacker có thể setup một DNS ma của mình sau đó config cái DNS ma đó vào modem để lợi dụng phishing hoặc pharming thì ko thấy nói tới.  
]]> /hvaonline/posts/list/23739.html#143037 /hvaonline/posts/list/23739.html#143037 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch

quanta wrote:
Cái này chị gái quê cũng đã có lần /hvaonline/posts/list/0/19736.html#117400.

Chị gái quê wrote:
2. Hacker rảnh wa' đi thay đổi pass để gây phiền phức ... trong khi đó Hacker có thể setup một DNS ma của mình sau đó config cái DNS ma đó vào modem để lợi dụng phishing hoặc pharming thì ko thấy nói tới.  
 
2 vấn đề khác nhau mà quanta :D ]]> /hvaonline/posts/list/23739.html#143038 /hvaonline/posts/list/23739.html#143038 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143042 /hvaonline/posts/list/23739.html#143042 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý http://www.doxpara.com/ Đây cũng chính là blog của người phát hiện ra lỗi này (Dan).]]> /hvaonline/posts/list/23739.html#143082 /hvaonline/posts/list/23739.html#143082 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

boom_jt wrote:
Ok, đầu tiên phải xác định cho rõ vấn đề nhé Theo boom_jt hiểu sau khi đọc bài quote của mrro thì hiện tại quá trình tấn công có thể diễn ra như sau: 1. Lừa cho người sử dụng vào 1 trang web nào đó có chứa các thẻ IMG hay IFRAME hay 1 thẻ nào đó tương tự (hoặc dùng flash chẳng hạn)khiến browser này liên tục hỏi DNS của ISP địa chỉ IP của AAAAA.VICTIM.COM ... ZZZZZ.VICTIM.COM. 2. DNS của ISP tạo các request để hỏi tương ứng với các request AAAAA.VICTIM.COM ... ZZZZZ.VICTIM.COM này. Mỗi request có 1 QID được generate ngẫu nhiên 3. Lúc này kẻ tấn công liên tục tạo ra các response với 1 QID nào đó. Và trong vô số các request đó thì khả năng sẽ có 1 QID trùng với QID của kẻ tấn công. Trong trường hợp 1 response nào đó của kẻ tấn công là hợp lệ, thì CXOPQ.VICTIM.COM (như trong ví dụ) sẽ được tin rằng có IP tương ứng là 6.6.6.0. Điều này không quan trọng, mà kèm theo đó là thông tin về IP của VICTIM.COM cũng được gửi kèm --> Vấn đề ở chỗ này: trước kia kẻ tấn công chỉ cần dựng lên 1 DNS server tại evil.com và gửi kèm thông tin về victim.com trong các response của nó. Với các fix hiện nay thì thông tin gửi kèm khác domain như thế sẽ không được chấp nhận, nhưng có vẻ như nếu thông tin gửi kèm là victim.com cho request về CXOPQ.VICTIM.COM thì lại được chấp nhận. Không rõ boom_jt đã xác định đúng vấn đề chưa? Mong mọi người chỉ giáo 
đọc kĩ hộ mình đoạn này nhé
Responses carry another value, too, called a time to live (TTL). This number tells your name server how long to cache the answer. Why? Because they deal with zillions of queries. Whoever wins the race between Alice and Mallory, their answer gets cached. All subsequent responses will be dropped. All future requests for that same data, within the TTL, come from that answer. This is good for whoever wins the race. If Alice wins, it means Mallory can’t poison the cache for that name. If Mallory wins, the next 10,000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0.  
Đây mới chỉ là cách thứ nhất. Còn cách thứ 2 nữa :|, đoạn này hơi khó đọc. Chắc phải chờ Black Hat conf để xem bác này trình diễn thôi :D ]]> /hvaonline/posts/list/23739.html#143086 /hvaonline/posts/list/23739.html#143086 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143094 /hvaonline/posts/list/23739.html#143094 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

K4i wrote:
Kiểm tra DNS server của mình qua site này: http://www.doxpara.com/ Đây cũng chính là blog của người phát hiện ra lỗi này (Dan). 
Đã thử nhưng đâu có ra my DNS server, bác thử thế nào có chính xác ko ? Mà hình như ko thể check đc DNS server thì phải!!]]> /hvaonline/posts/list/23739.html#143096 /hvaonline/posts/list/23739.html#143096 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

(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ứ :-?]]> /hvaonline/posts/list/23739.html#143101 /hvaonline/posts/list/23739.html#143101 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch

catdog wrote:

K4i wrote:
Kiểm tra DNS server của mình qua site này: http://www.doxpara.com/ Đây cũng chính là blog của người phát hiện ra lỗi này (Dan). 
Đã thử nhưng đâu có ra my DNS server, bác thử thế nào có chính xác ko ? Mà hình như ko thể check đc DNS server thì phải!! 
Bạn vào trang trên click vào dòng chữ "Check My DNS" ở bên phải ấy Của tớ thì nó báo thế này
Your name server, at 203.162.4.199, appears to be safe, but make sure the ports listed below aren't following an obvious pattern. 
]]> /hvaonline/posts/list/23739.html#143104 /hvaonline/posts/list/23739.html#143104 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý Your name server, at 203.119.8.106, may be safe, but the NAT/Firewall in front of it appears to be interfering with its port selection policy. The difference between largest port and smallest port was only 52. Please talk to your firewall or gateway vendor -- all are working on patches, mitigations, and workarounds. Requests seen for e94df9bfbe90.toorrr.com: 203.119.8.106:32973 TXID=768 203.119.8.106:32984 TXID=33182 203.119.8.106:33003 TXID=37883 203.119.8.106:32964 TXID=57615 203.119.8.106:32951 TXID=40178   Có thể thấy là trang này kiểm tra source port của các request: Giống nhau -> vulnerable]]> /hvaonline/posts/list/23739.html#143106 /hvaonline/posts/list/23739.html#143106 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý http://www.robtex.com/dns]]> /hvaonline/posts/list/23739.html#143107 /hvaonline/posts/list/23739.html#143107 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143110 /hvaonline/posts/list/23739.html#143110 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html. Chỗ nào không chính xác nhờ mọi người chỉnh giúp Có hai vấn đề cần thảo luận: 1. Sự không cẩn trọng trong thiết kế hoạt động DNS Server, dẫn tới bộ tạo ngẫu nhiên của một số trường trong DNS record không thực sự "ngẫu nhiên". Do đó xác suất xảy ra giả mạo gói tin DNS response có thể cao. Đây là vấn đề được cảnh báo từ trước, từ đó dẫn tới vấn đề thứ 2. 2. Attack vector để poisoning một DNS server như thế nào? Vấn đề thứ nhất: lỗi thiết kế của DNS Server Mỗi gói tin DNS request có chứa query id (QID) hay còn gọi là Transaction ID (TxID), được gửi tới DNS server thông qua một source-port (S-PORT). DNS Server trả lời bằng một gói tin DNS Response, chỉ được bên gửi chấp nhận khi: - Có chứa cùng QID hay TxID - Dest Port chính là S-PORT trong DNS Request. Như vậy để giả mạo được DNS Response, Malory phải biết được 2 thông tin này, hoặc cách khác là gửi hàng loạt gói tin khi biết xác suất QID và S-PORT nằm trong khoảng nào. S-PORT theo lý thuyết là khá lớn (2^16 - 1024 port), tuy nhiên theo một số thông tin, S-PORT thường cố định trên một DNS server và thay đổi sau mỗi lần khởi động lại!!? Vấn đề thứ 2: Attack vector để poisoning một DNS server Kịch bản: Malory muốn "thuyết phục" Bob, một DNS Server (ns.bob.com), laf tên miền victim.com trỏ tới địa chỉ giả mạo là 6.6.6.6. 1. Malory gửi hàng loạt DNS request rác cho Bob (ns.bob.com): aaaa1.victim.com, aaa2.victim.com .... zzz9.victim.com Điều này làm Bob không tìm thấy trong DNS cache của mình các tên miền trên. Bob phải hỏi DNS Server cấp cao hơn (Alice) về DNS server của các tên miền *.victim.com này. 2. Malory giả mạo các DNS Response từ Alice cho Bob, dùng cách thức đề cập ở vấn đề 1. DNS Response này chứa: - *.victim.com trỏ tới 6.6.6.6 - Additional RRs có thông tin: victim.com trỏ tới 6.6.6.6 Cơ hội để Malory "thuyết phục" được Bob rằng victim.com trỏ tới 6.6.6.6 sẽ tăng lên khi số lượng gói tin giả mạo DNS Response lớn để thử các khả năng của QID và S-PORT (có thể xác định được trước S-PORT nếu giá trị này khá ổn định) theo kiểu tấn công birthday paradox attack. Theo những gì quote của mrro phân tích ở trên, attack vector này có khả năng vô hiệu hóa các fix #1 (tăng cường tính ngẫu nhiên của QID) và #2 (bailiwick checking các trường RR). Cụ thể như thế nào mọi người hãy thảo luận.]]> /hvaonline/posts/list/23739.html#143129 /hvaonline/posts/list/23739.html#143129 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143133 /hvaonline/posts/list/23739.html#143133 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143150 /hvaonline/posts/list/23739.html#143150 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143155 /hvaonline/posts/list/23739.html#143155 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý HDMoore (tác giả của Metasploit) và |)ruid . Xem ở http://blogs.zdnet.com/security/?p=1545. Còn code exploit thì ở http://www.caughq.org/exploits/CAU-EX-2008-0002.txt. (Bác nào cho em hỏi là cái code này viết bằng ngôn ngữ gì thế Perl hay Ruby :D) Theo tác giả thì hiện tại mất khoảng từ 1 -> 2 phút để cho hạ gục mục tiêu
In an IM exchange, Moore told me his exploit takes about a minute or two to poison a DNS cache but said he is working to improve it in version 2.0. 
VNCert cũng đã ra thông báo về vấn đề này. Nhưng điều ngạc nhiên là thông báo này mới chỉ đề cập đến cách tấn công đầu tiên của lỗi này. Xem ở http://vncert.gov.vn/canhbao/cbnd/CBND08-003.htm PS: post xong mới phát hiện ra mrro đã post từ đêm qua. ]]> /hvaonline/posts/list/23739.html#143172 /hvaonline/posts/list/23739.html#143172 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143177 /hvaonline/posts/list/23739.html#143177 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý Code:
P = 1 - (1 - X/2^16)^N, trong đó:

- X: số fake response ứng với một cặp (một query + một authorative DNS server)

- N: số query
Một vài con số tính toán: * Với X = 10, N = 5000 là đã có thể có xác suất hơn 53% đoán đúng. * Với X = 20, N = 5000 là đã có gần 96% đoán đúng Tui cũng đã kiểm tra trong thực tế luôn, thấy với X = 10, và 5000 < N < 8000 là có thể thành công rồi với xác suất khá cao:
msf auxiliary(bailiwicked_host) > run [*] Targeting nameserver 10.10.11.63 for injection of www.vnexpress.net. as 3.3.3.3 [*] Querying recon nameserver for vnexpress.net.'s nameservers... [*] Got an NS record: vnexpress.net. 75809 IN NS dns010.d.register.com. [*] Querying recon nameserver for address of dns010.d.register.com.... [*] Got an A record: dns010.d.register.com. 163883 IN A 216.21.236.10 [*] Checking Authoritativeness: Querying 216.21.236.10 for vnexpress.net.... [*] dns010.d.register.com. is authoritative for vnexpress.net., adding to list of nameservers to spoof as [*] Got an NS record: vnexpress.net. 75809 IN NS dns026.c.register.com. [*] Querying recon nameserver for address of dns026.c.register.com.... [*] Got an A record: dns026.c.register.com. 163880 IN A 216.21.235.26 [*] Checking Authoritativeness: Querying 216.21.235.26 for vnexpress.net.... [*] dns026.c.register.com. is authoritative for vnexpress.net., adding to list of nameservers to spoof as [*] Got an NS record: vnexpress.net. 75809 IN NS dns131.a.register.com. [*] Querying recon nameserver for address of dns131.a.register.com.... [*] Got an A record: dns131.a.register.com. 163879 IN A 216.21.231.131 [*] Checking Authoritativeness: Querying 216.21.231.131 for vnexpress.net.... [*] dns131.a.register.com. is authoritative for vnexpress.net., adding to list of nameservers to spoof as [*] Got an NS record: vnexpress.net. 75809 IN NS dns238.b.register.com. [*] Querying recon nameserver for address of dns238.b.register.com.... [*] Got an A record: dns238.b.register.com. 163878 IN A 216.21.232.238 [*] Checking Authoritativeness: Querying 216.21.232.238 for vnexpress.net.... [*] dns238.b.register.com. is authoritative for vnexpress.net., adding to list of nameservers to spoof as [*] Attempting to inject a poison record for www.vnexpress.net. into 10.10.11.63:53... [*] Sent 1000 queries and 40000 spoofed responses... [*] Sent 2000 queries and 80000 spoofed responses... [*] Sent 3000 queries and 120000 spoofed responses... [*] Sent 4000 queries and 160000 spoofed responses... [*] Sent 5000 queries and 200000 spoofed responses... [*] Sent 6000 queries and 240000 spoofed responses... [*] Sent 7000 queries and 280000 spoofed responses... [*] Poisoning successful after 7250 attempts: www.vnexpress.net == 3.3.3.3 [*] Auxiliary module execution completed  
--m ]]> /hvaonline/posts/list/23739.html#143244 /hvaonline/posts/list/23739.html#143244 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143257 /hvaonline/posts/list/23739.html#143257 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

lamer wrote:
Nếu không phải dùng birthday paradox thì trong cái exploit em đang dùng đó nó sẽ không gửi hàng loạt trả lời giả với QID trong một miền giá trị mà nó sẽ chỉ gửi một trả lời giả với một QID nhất định . Mục tiêu cuối cùng cũng chỉ là tăng khả năng trúng QID.  
Đúng là mục tiêu cuối cùng là tăng khả năng đoán trúng QID, nhưng cái này không phải là birthday paradox. Birthday paradox chỉ xảy ra khi một câu query của thằng attacker khiến thằng resolver gửi ra ngoài q > 1 câu query giống nhau, chỉ khác QID. Lúc này nhóm các câu trả lời giả của exploit sẽ có cơ hội *collision* với nhóm q câu trả lời, làm cho xác suất đoán trúng tăng đột biến. Trong trường hợp này, q=1, nên không thể xảy ra birthday paradox ở đây. Xem thêm http://www.kb.cert.org/vuls/id/457875. Việc exploit gửi ra một loạt trả lời giả với QID trong một miền giá trị chỉ nhằm mục đích tăng xác suất đoán trúng QID đối với câu query duy nhất mà resolver đã gửi ra ngoài trước đó. Xác suất đoán trúng lúc này sẽ là x/2^16, trong đó x là số lượng trả lời giả mà exploit gửi đối với mỗi câu query. Anh lưu ý là danh sách các QID giả này nó không thay đổi trong suốt thời gian exploit được chạy. Mỗi lần gửi một query, xác suất đoán sai là 1-x/2^16. Các lần gửi query đều độc lập với nhau, cho nên xác suất đoán sai cho đến lần gửi query thứ n sẽ là (1-x/2^16)^n. Suy ra xác suất đoán đúng sẽ là 1 - (1-x/2^16)^n. Đó là công thức hồi nãy em có nói. --m]]> /hvaonline/posts/list/23739.html#143280 /hvaonline/posts/list/23739.html#143280 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143299 /hvaonline/posts/list/23739.html#143299 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143452 /hvaonline/posts/list/23739.html#143452 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143463 /hvaonline/posts/list/23739.html#143463 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý chuẩn trên bkav nè: http://bkav.com.vn/tin_tuc_noi_bat/25/07/2008/2/1725/ --> "Bkis phát hành phần mềm kiểm tra lỗ hổng máy chủ DNS" http://www.bkav.com.vn/home/default.aspx?Noidung=BkavDNSCheckGuide --> "HƯỚNG DẪN KIỂM TRA DNS SERVER SỬ DỤNG PHẦN MỀM BkavDNSCheck KIỂM TRA LỖ HỔNG DNS CACHE POISONING" boom thấy có vẻ được đó chớ :"> mà họ viết đó thôi :D Lưu ý các bạn người dùng bình thường như mình thì dùng cái này ko có ích nha, vì phần mềm test dùng cho quản trị mạng thôi à ^^]]> /hvaonline/posts/list/23739.html#143467 /hvaonline/posts/list/23739.html#143467 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

mrro wrote:
hôm nay đọc báo thấy mắc cười quá, các bác bkis lại làm trò khỉ nữa rồi. gì mà có cả phần mềm kiểm tra, vá lỗi đe dọa toàn cầu nữa? (cái title dễ gây nhầm lẫn, kiểu như bkis viết được phần mềm vá cái lỗi đe dọa toàn cầu, nghe hoành tráng quá). haha đọc cái hướng dẫn của cái chương trình, tôi tự hỏi là kiểm tra cái này có phức tạp đến vậy không? gì mà vừa phải download chương trình, vừa phải cấu hình lung tung cả lên, rồi mới kiểm tra được? điên àh? muốn kiểm tra ư? một lệnh là xong: dig +short @your-dns-server porttest.dns-oarc.net txt hoặc trên windows thì dùng lệnh này (vào start->run->cmd rồi gõ vào lệnh này) nslookup -type=txt -timeout=30 porttest.dns-oarc.net your-dns-server nếu kết quả trả về là GOOD thì an toàn, còn kết quả trả về là POOR thì nghĩa là máy chủ DNS vẫn chưa được vá. bạn nào không biết địa chỉ máy chủ DNS của mình, thì cứ việc gõ lại hai lệnh trên nhưng bỏ phần your-dns-server đi, ví dụ như: $ dig +short 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.6 seconds from 26 ports with std dev 20398.88" thấy nó báo không? "203.162.4.198 is GOOD". nghĩa là DNS mà bạn đang sử dụng đã được vá lỗi. còn nếu báo là POOR thì bạn nên viết email thông báo cho ISP, yêu cầu họ vá lỗi.  
Tui cũng là quản trị mạng nên tui cũng hiểu về DNS. Theo tui hiểu thì Mrro chưa hiểu rõ về DNS rồi. Cái cách thử của Mrro trình bày ở trên chỉ check được DNS Server cuối cùng trong chuối recursion đi hỏi 1 tên miền thôi. Để giải thích đơn giản, tui copy đoạn output tui vừa test: ở đây tui test con DNS Server của tui: 203.162.X.X , vậy mà kết quả test lại trả lời về con 203.119.8.X. Con 203.119.8.X chính là con cuối cùng trong chuỗi DNS, và chính là con trực tiếp đi hỏi con porttest.dns-oarc.net, kết quả là chỉ check được xem con 203.119.8.X có lỗ hổng hay không, còn con DNS Server mà tui muốn test là con 203.162.X.X thì lại không test được ! Tóm lại, là cách test như Mrro chỉ là không xài được ! ============== C:\>nslookup -type=txt -timeout=30 porttest.dns-oarc.net 203.162.X.X Server: XXX Address: 203.162.X.X Non-authoritative answer: porttest.dns-oarc.net canonical name = 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 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 text = "203.119.8.X is POOR: 26 queries in 6.3 seconds from 22 ports with std dev 17.97" c.b.a.pt.dns-oarc.net nameserver = ns.c.b.a.pt.dns-oarc.net ============== Tương tự như vậy, cái tool của Dan trên blog của anh ta cũng không xài được vì tool đấy cũng chỉ check được DNS Server cuối cùng trong chuỗi đi hỏi tên miền ZZZ.toorrr.com

mrro wrote:
tiện đây tôi cũng thông báo là máy chủ DNS của VDC, FPT đều đã được vá, các bạn có thể chuyển sang sử dụng nó thay cho OpenDNS. trở lại chuyện của các bác bkis. tôi thấy các bác này luôn thích phải làm cho mọi chuyện trở nên bí hiểm, phức tạp hay hình sự hóa hay trinh thám hóa thì các bác mới chịu. chẳng hạn như vụ lộ đề thi vừa rồi. haha các bác bkis đã viết hẳn một bài "bkis đã tìm ra vụ tìm đề toán trên mạng như thế nào?", cứ như thể đây là một phát hiện ghê gớm lắm vậy, trong khi toàn bộ chỉ là những trò mèo. thử nhìn lại xem, một trung tâm như bkis, được Nhà nước đầu tư vài chục tỉ đồng, đã có những đóng góp gì về học thuật và kĩ thuật, ngoài những báo cáo theo kiểu trinh thám ba xu này? buồn cười là, nhiều lần tôi gặp những người ngoại đạo, họ luôn nghĩ về các bác bkis như những chàng hiệp sĩ đại tài, kiểu như làm được những phần mềm vá những lỗi đe dọa toàn cầu, vẫn ngày đêm miệt mài chiến đấu bảo vệ toàn thể dân VN chống lại bọn tin tặc lộng hành. ngay cả bác Nhân còn tặng bằng khen cho bkis nữa là. lại nhớ đến hiệp sĩ mù. chắc phải đổi lại thành hiệp sĩ chột, lừa cả xứ mù. --m  
Về đoạn này thì tui thấy rõ là Mrro cay cú với BKIS quá rồi. Tui theo mấy cái link boom_jt post, BKIS họ nói như vậy là chuẩn mực rồi chứ, đâu thể chỉ trích? chỉ do một vài báo giật tít lại hơi quá thôi. Còn về cái tool BKIS cung cấp, tui cũng dùng thử và thực hữu dụng, lúc đầu báo DNS Server của tui là không ok, tui lên Microsoft để update patch, check lại thì đúng là đã ok. Tool của BKIS phải cấu hình trên DNS Server cần test, nhưng đảm bảo là test được đúng DNS Server muốn test, chứ không như cách chỉ của Mrro hay tool của Dan trên blog. ]]> /hvaonline/posts/list/23739.html#143474 /hvaonline/posts/list/23739.html#143474 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

mrro wrote:
muốn kiểm tra ư? một lệnh là xong: dig +short @your-dns-server porttest.dns-oarc.net txt hoặc trên windows thì dùng lệnh này (vào start->run->cmd rồi gõ vào lệnh này) nslookup -type=txt -timeout=30 porttest.dns-oarc.net your-dns-server nếu kết quả trả về là GOOD thì an toàn, còn kết quả trả về là POOR thì nghĩa là máy chủ DNS vẫn chưa được vá. bạn nào không biết địa chỉ máy chủ DNS của mình, thì cứ việc gõ lại hai lệnh trên nhưng bỏ phần your-dns-server đi, ví dụ như: $ dig +short 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.6 seconds from 26 ports with std dev 20398.88" thấy nó báo không? "203.162.4.198 is GOOD". nghĩa là DNS mà bạn đang sử dụng đã được vá lỗi. còn nếu báo là POOR thì bạn nên viết email thông báo cho ISP, yêu cầu họ vá lỗi.  
Cách của mrro không dùng được. Bồ chỉ thấy được mấy DNS Server trên cùng mà không thấy được DNS của mình có lỗi hay không.]]> /hvaonline/posts/list/23739.html#143475 /hvaonline/posts/list/23739.html#143475 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch http://www.bkav.com.vn/home/default.aspx?Noidung=BkavDNSCheckGuide
nếu giữa đường thằng DNS server cần check đến thằng BKAV DNS check bị NAT port thì sao nhể :D ? Lúc đó liệu thằng BKAV DNS check có kiểm tra được coi cái source port của thằng DNS vul có bị random (fixed) hay cố định (chưa fixed) hay ko nhể?]]> /hvaonline/posts/list/23739.html#143478 /hvaonline/posts/list/23739.html#143478 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143484 /hvaonline/posts/list/23739.html#143484 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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á. ]]> /hvaonline/posts/list/23739.html#143492 /hvaonline/posts/list/23739.html#143492 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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]]> /hvaonline/posts/list/23739.html#143496 /hvaonline/posts/list/23739.html#143496 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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.]]> /hvaonline/posts/list/23739.html#143506 /hvaonline/posts/list/23739.html#143506 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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.]]> /hvaonline/posts/list/23739.html#143509 /hvaonline/posts/list/23739.html#143509 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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 ]]> /hvaonline/posts/list/23739.html#143512 /hvaonline/posts/list/23739.html#143512 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143519 /hvaonline/posts/list/23739.html#143519 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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è :P 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! B-) 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 ?" :P 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 :D]]> /hvaonline/posts/list/23739.html#143527 /hvaonline/posts/list/23739.html#143527 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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. ]]> /hvaonline/posts/list/23739.html#143530 /hvaonline/posts/list/23739.html#143530 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143538 /hvaonline/posts/list/23739.html#143538 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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]]> /hvaonline/posts/list/23739.html#143542 /hvaonline/posts/list/23739.html#143542 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143549 /hvaonline/posts/list/23739.html#143549 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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]]> /hvaonline/posts/list/23739.html#143553 /hvaonline/posts/list/23739.html#143553 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143557 /hvaonline/posts/list/23739.html#143557 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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ả).]]> /hvaonline/posts/list/23739.html#143560 /hvaonline/posts/list/23739.html#143560 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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.]]> /hvaonline/posts/list/23739.html#143562 /hvaonline/posts/list/23739.html#143562 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143567 /hvaonline/posts/list/23739.html#143567 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143572 /hvaonline/posts/list/23739.html#143572 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143577 /hvaonline/posts/list/23739.html#143577 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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]]]> /hvaonline/posts/list/23739.html#143598 /hvaonline/posts/list/23739.html#143598 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý mrro: Tất cả những chỗ đáng lẽ là authoritative, mrro viết nhầm thành authorative.]]> /hvaonline/posts/list/23739.html#143599 /hvaonline/posts/list/23739.html#143599 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch Đú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 :D (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) :D. Thôi, mọi việc đã rõ ràng rồi nhé. ]]> /hvaonline/posts/list/23739.html#143603 /hvaonline/posts/list/23739.html#143603 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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.]]> /hvaonline/posts/list/23739.html#143604 /hvaonline/posts/list/23739.html#143604 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch

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 :D, 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 ??? :D @facialz: rất chính xác :D @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.]]> /hvaonline/posts/list/23739.html#143605 /hvaonline/posts/list/23739.html#143605 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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ì đó :^) ]]> /hvaonline/posts/list/23739.html#143609 /hvaonline/posts/list/23739.html#143609 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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.]]> /hvaonline/posts/list/23739.html#143610 /hvaonline/posts/list/23739.html#143610 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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]]> /hvaonline/posts/list/23739.html#143612 /hvaonline/posts/list/23739.html#143612 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143623 /hvaonline/posts/list/23739.html#143623 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch # 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/ ]]> /hvaonline/posts/list/23739.html#143636 /hvaonline/posts/list/23739.html#143636 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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
]]> /hvaonline/posts/list/23739.html#143642 /hvaonline/posts/list/23739.html#143642 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#143650 /hvaonline/posts/list/23739.html#143650 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch /hvaonline/posts/list/23739.html#143674 /hvaonline/posts/list/23739.html#143674 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch

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?]]> /hvaonline/posts/list/23739.html#143690 /hvaonline/posts/list/23739.html#143690 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người 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)]]> /hvaonline/posts/list/23739.html#143710 /hvaonline/posts/list/23739.html#143710 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch

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 :) ]]> /hvaonline/posts/list/23739.html#143773 /hvaonline/posts/list/23739.html#143773 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch

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 -:|- ]]> /hvaonline/posts/list/23739.html#143837 /hvaonline/posts/list/23739.html#143837 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch

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 :*- 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 :P 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 ]]> /hvaonline/posts/list/23739.html#143871 /hvaonline/posts/list/23739.html#143871 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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.]]> /hvaonline/posts/list/23739.html#144124 /hvaonline/posts/list/23739.html#144124 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#144147 /hvaonline/posts/list/23739.html#144147 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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? :) 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.]]> /hvaonline/posts/list/23739.html#144171 /hvaonline/posts/list/23739.html#144171 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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]]> /hvaonline/posts/list/23739.html#144179 /hvaonline/posts/list/23739.html#144179 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#144182 /hvaonline/posts/list/23739.html#144182 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#144210 /hvaonline/posts/list/23739.html#144210 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người ch /hvaonline/posts/list/23739.html#144212 /hvaonline/posts/list/23739.html#144212 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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 ]]> /hvaonline/posts/list/23739.html#144389 /hvaonline/posts/list/23739.html#144389 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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.]]> /hvaonline/posts/list/23739.html#144393 /hvaonline/posts/list/23739.html#144393 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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ì! ]]> /hvaonline/posts/list/23739.html#144395 /hvaonline/posts/list/23739.html#144395 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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:
]]> /hvaonline/posts/list/23739.html#144397 /hvaonline/posts/list/23739.html#144397 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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è:
]]> /hvaonline/posts/list/23739.html#144402 /hvaonline/posts/list/23739.html#144402 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#144405 /hvaonline/posts/list/23739.html#144405 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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ì ]]> /hvaonline/posts/list/23739.html#144406 /hvaonline/posts/list/23739.html#144406 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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 ]]> /hvaonline/posts/list/23739.html#144418 /hvaonline/posts/list/23739.html#144418 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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ì)]]> /hvaonline/posts/list/23739.html#144427 /hvaonline/posts/list/23739.html#144427 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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]]> /hvaonline/posts/list/23739.html#144430 /hvaonline/posts/list/23739.html#144430 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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]]> /hvaonline/posts/list/23739.html#144433 /hvaonline/posts/list/23739.html#144433 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#144657 /hvaonline/posts/list/23739.html#144657 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

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.]]> /hvaonline/posts/list/23739.html#144697 /hvaonline/posts/list/23739.html#144697 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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).]]> /hvaonline/posts/list/23739.html#144700 /hvaonline/posts/list/23739.html#144700 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 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 ]]> /hvaonline/posts/list/23739.html#145378 /hvaonline/posts/list/23739.html#145378 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#145408 /hvaonline/posts/list/23739.html#145408 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

crazyboy_alias wrote:
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á 
Tiếp tục gởi bài với loại ngôn ngữ chít chat (hum, jì, ko, gj`.....) tôi không những xóa mà còn lock nick luôn đấy. Nên xem lại cách dùng từ cho rõ ràng và chính xác.]]> /hvaonline/posts/list/23739.html#145412 /hvaonline/posts/list/23739.html#145412 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý KAMINSKY ĐÃ THÔNG BÁO CHI TIẾT LỖ HỔNG DNS TẠI BLACK HAT 2008 SEMINAR, TỔ CHỨC Ở LAS VEGAS, HÔM QUA 06.8.2008
Download báo cáo (slide) của Dan Kaminsky đã trình bầy tại seminar nói trên: http://pxm.no-ip.org/DMK_BO2K8.ppt ]]> /hvaonline/posts/list/23739.html#145559 /hvaonline/posts/list/23739.html#145559 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý 1- Nghe online: Truy cập đến link dưới đây: http://bigcontact.com/feed-player/9193_9961/r:1;t:1001 Chú ý: - Adobe Flash Player 9 cài trên hệ thống phải enabled - Windows Media Player 8, 9, 10, 11 cài trong hệ thống - Highlight dòng (pane) "SWW: Dan Kaminsky at Black Hat" - Sau đó Highlight dòng "Security Wire Weekly: Dan Kaminsky on the DNS flaw" nếu muốn nghe tiếp (nội dung: thảo luận với Kaminsky về DNS flaw- ngày 16-7-08) 2. Nghe offline Download file MP3: SecurityWireWeekly08062008.mp3 ở đây: (nhưng có thể phải chờ tôi upload một chút. File 7.2 MB) http://pxm.dyndns.org/SecurityWireWeekly08062008.zip Be noted: Website này sử dụng tên miền yourname.dyndns.org, loại free ( tôi thử nghiệm), nên truy cập, download có thể có lúc không "ngon". ]]> /hvaonline/posts/list/23739.html#145759 /hvaonline/posts/list/23739.html#145759 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#145765 /hvaonline/posts/list/23739.html#145765 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý http://www.vusta.vn/news_detail.asp?id=28682]]> /hvaonline/posts/list/23739.html#146524 /hvaonline/posts/list/23739.html#146524 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý Ngày 30/7, trả lời báo KH&ĐS, ông Nguyễn Tử Quảng, giám đốc trung tâm an ninh mạng BKIS khẳng định: "Về vấn đề trên, chúng tôi cho rằng người viết chưa hiểu rõ kiểu lỗ hổng lần này một cách cụ thể. Chúng tôi đã mất nhiều thời gian để nghiên cứu và cho ra đời tool này. Tính đến thời điểm hiện tại, có thể nói tool kiểm tra DNS của BKAV hoạt động tốt nhất. Tính đến ngày 29/7, sau 4 ngày BKAV phát hành tool kiểm tra DNS đã có trên 300 DNS được kiểm tra và vá lỗi. Trong đó có thể kể đến một số DNS lớn như VDC... Trong thời gian vừa qua, đã có hàng loạt các website bị tấn công bởi hacker, đây cũng là hệ quả của việc các doanh nghiệp chưa coi trọng vấn đề bảo mật. Ngay từ đầu, các doanh nghiệp đã không đặt ra các chỉ tiêu về bảo mật và hầu hết tự làm, tự kiểm tra. Hiện tại, các đơn vị này có thể thuê riêng một đơn vị tư vấn, các cơ quan an ninh mạng để kiểm tra, nghiệm thu và đưa ra cho họ những kết luận đầy đủ nhất về mức độ bảo mật cho hệ thống của công ty họ".   :-O ]]> /hvaonline/posts/list/23739.html#146533 /hvaonline/posts/list/23739.html#146533 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý Bài của Kaminsky do trình bầy dưới dạng slides, dùng Power Point, nôi dung chỉ tóm tắt, theo kiểu "gạch đầu dòng", nên cũng hơi khó hiểu. Vả lại tính cách của Kaminsky có vẻ nghiêng về thực hành-thưc tiễn, không đi sâu vào lý luận và giải thích tỉ mỉ cơ chế hoạt động) - Các bác cũng đã nghe ghi âm một phần quan trọng trong bài trình bầy nói trên của Kaminsky. - Tôi cũng đã mạo muội trình bầy sơ đồ mạng và cơ chế hoạt động của Tool check lỗ hổng bảo mật DNS mà Kaminsky đã thiết lập trên website www.doxpara.com của chính anh ta, theo sự hiểu biết của tôi. Vậy thì: 1- Xin bác nào giúp trình bầy lại kỹ, rõ ràng nôi dung, bản chất của các lỗ hổng bảo mật trên hệ thống DNS toàn cầu mà Dan Kaminsky đã đề cập chi tiết (tại Las vegas ngày 6.8.08 nói trên). 2- Đề ra cách thức khắc phục các lỗ hổng này, đặc biệt là áp dụng phủ hợp trong điều kiện Việt nam. 3- Bình luận về Tool check bảo mật DNS của BKIS xem nó có phù hợp với nôi dung bảo mật mà Dan Kaminsky đã báo cáo hay không? Xin bác nào giúp cho, như boom_it chẳng hạn. Go ahead please! Thanks. ]]> /hvaonline/posts/list/23739.html#146771 /hvaonline/posts/list/23739.html#146771 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý /hvaonline/posts/list/23739.html#165512 /hvaonline/posts/list/23739.html#165512 GMT Re: (Báo Động Đỏ) Lỗi bảo mật DNS đặc biệt nghiêm trọng , mọi người chú ý

meomeo_bebong wrote:
Cháu muốn hỏi ở đây lắm nhưng ngại mình trình độ kém cỏi. 1/ Chú PXMMRF và bà con cho cháu hỏi nếu dùng Open DNS thì sẽ hạn chế được lỗi DNS được bao nhiêu và hạn chế như thế nào ? 2/ Còn những cách khắc phục nào với lỗi DNS này k0 ạ ? Cám ơn chú và bà con nhiều.  
1 - Còn tùy thuộc vào độ độ tin cậy của các DNS server của OpenDNS 2 - Tìm một DNS server có độ tin cậy cao Mình dùng DNS server của OpenDNS (208.67.222.222, 208.67.220.220), vừa tin cậy vừa vượt được cả firewall phía ISP :P ]]> /hvaonline/posts/list/23739.html#165884 /hvaonline/posts/list/23739.html#165884 GMT