Since release of details about the DNS flaw uncovered by Dan Kaminsty , I`ve seen some notes , tools or PoCs with a note somethin like "Ability to attack _patched_ dns servers..." .
While there`s no doubt about theorical possibility of that , they are actually kind of fake capabilities in real-world scenarios . Last case I came across is available here . As the write r commented :
BIND used fully randomized source port range, i.e. around 64000 ports. Two attacking servers, connected to the attacked one via GigE link, were used, each one attacked 1-2 ports with full ID range. Usually attacking server is able to send about 40-50 thousands fake replies before remote server returns the correct one, so if port was matched probability of the successful poisoning is more than 60%. Attack took about half of the day, i.e. a bit less than 10 hours. So, if you have a GigE lan, any trojaned machine can poison your DNS during one night...
What made Kaminsky`s attack so critical (and interesting) was it`s ability to poison
a remote server,
over internet,
in few minutes,
with acceptable amount of packets,
with very-high (>90%) success rate.
The key of success was lack of source-port randomization , which is addressed now . Without that , attempting to poison the server is no more the Kaminsky attack vector . it`s just soooooo old known weakness in DNS protocol that is really hard to exploit in real-world scenarios. Guessing corred ID for DNS response is really hard and resource intensive in normal environments, and some times totally impossible .
Attacking patched DNS servers requires HIGH bandwith and it takes SO LONG over remote systems . As high as a direct Gigabit ethernet link , and as long as 10 hours over mentioned link , with only 60% success rate . Have you ever compared the lab scenario mentioned above ,with one of your cases ?
If we`re already in same network segment of DNS server, thare are much better tricks to use. Why keep sending fake responses at Gigabit speed for at least 10 hours to guess the correct ID , while we can discover it with few fake ARP packets to implement an ARP poisoning attack to hijack DNS traffic and capture the right ID we`re looking for ? :)
Sure both of these can be easily detected . But compare a 10h long pick in MRTG graph with a few seconds long pick . Also the DNS related pick shows full bandwith useage while ARP one is minor , compared to DNS . So are we crazy to use the hardcore dns poisoning way ? :)
Extend above notes for a case were you`re attacking a remote DNS server over internet. I doubt if many of attackers out there are able to gain access to a host with 1Gbit internet bandwidth , and even if they have such host , their victim have same network bandwidth . And administrators of targetted server keep watching you flooding them for hours and hours...
Let`s forget it at all . You`ve not visited my blog at all , ok ? ;)
Btw , Since my past blog post about DNS , two of major DNS servers I was worry about tried to address their vulnerabilities . NIC and DCI dns servers looks safe to this attack vector now . About NIC I can`t be sure yet, as they`ve just blocked recursive queries . I hadn`t chance to check randomness of source-ports . If you`re using any of their DNS servers , check it and let me know about results here as a comment .
While there`s no doubt about theorical possibility of that , they are actually kind of fake capabilities in real-world scenarios . Last case I came across is available here . As the write r commented :
# named -v
BIND 9.5.0-P2
What made Kaminsky`s attack so critical (and interesting) was it`s ability to poison
a remote server,
over internet,
in few minutes,
with acceptable amount of packets,
with very-high (>90%) success rate.
The key of success was lack of source-port randomization , which is addressed now . Without that , attempting to poison the server is no more the Kaminsky attack vector . it`s just soooooo old known weakness in DNS protocol that is really hard to exploit in real-world scenarios. Guessing corred ID for DNS response is really hard and resource intensive in normal environments, and some times totally impossible .
Attacking patched DNS servers requires HIGH bandwith and it takes SO LONG over remote systems . As high as a direct Gigabit ethernet link , and as long as 10 hours over mentioned link , with only 60% success rate . Have you ever compared the lab scenario mentioned above ,with one of your cases ?
If we`re already in same network segment of DNS server, thare are much better tricks to use. Why keep sending fake responses at Gigabit speed for at least 10 hours to guess the correct ID , while we can discover it with few fake ARP packets to implement an ARP poisoning attack to hijack DNS traffic and capture the right ID we`re looking for ? :)
Sure both of these can be easily detected . But compare a 10h long pick in MRTG graph with a few seconds long pick . Also the DNS related pick shows full bandwith useage while ARP one is minor , compared to DNS . So are we crazy to use the hardcore dns poisoning way ? :)
Extend above notes for a case were you`re attacking a remote DNS server over internet. I doubt if many of attackers out there are able to gain access to a host with 1Gbit internet bandwidth , and even if they have such host , their victim have same network bandwidth . And administrators of targetted server keep watching you flooding them for hours and hours...
Let`s forget it at all . You`ve not visited my blog at all , ok ? ;)
Btw , Since my past blog post about DNS , two of major DNS servers I was worry about tried to address their vulnerabilities . NIC and DCI dns servers looks safe to this attack vector now . About NIC I can`t be sure yet, as they`ve just blocked recursive queries . I hadn`t chance to check randomness of source-ports . If you`re using any of their DNS servers , check it and let me know about results here as a comment .
It was extremely interesting for me to read that blog. Thank you for it. I like such topics and everything connected to this matter. I definitely want to read more soon.
ReplyDelete