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.
 

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.  

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.  

 

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 

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.  

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). 

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!! 

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. 

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
 

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. 

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

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

 

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.
 

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.
 

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
 

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.