Softpanorama
May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

DNS Spoofing

News See also Recommended Books Recommended Links Cache poisoning Chrooting bind Etc

In the summer of 1997, Eugene Kashpureff demonstrated DNS spoofing quite convincingly by performing the mother of all DNS hacks -- the redirection of all of the traffic destined to the Internic to his own Alternic.net service.

Generally DNS Spoofing is the trick of making a DNS entry to point to some  IP other than it would be supposed to point to -- hijacking the identity of the server. With modern bind daemons this is a difficult thing to do without breaking into the server or some parts of network infrastructure (routers, switches, etc).  It also can be useful and is used by Cisco routers (See DNS Spoofing - Cisco Systems). Here is the summary of the attack

DNS spoofing

Resolving Names

Spoofing DNS example

Access to a router and DNS

It is important to understand that such widely used protocol as HTTP is vulnerable to this attack. As RFC 2068 states:

15.8 DNS Spoofing

Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. Clients need to be cautious in assuming the continuing validity of an IP number/DNS name association.

In particular, HTTP clients SHOULD rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous host name lookups. Many platforms already can cache host name lookups locally when appropriate, and they SHOULD be configured to do so. These lookups should be cached, however, only when the TTL (Time To Live) information reported by the name server makes it likely that the cached information will remain useful.

If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS.

If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes. As network renumbering is expected to become increasingly common, the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability.

This requirement also improves the load-balancing behavior of clients for replicated servers using the same DNS name and reduces the likelihood of a user's experiencing failure in accessing sites which use that strategy.

15.9 Location Headers and Spoofing

If a single server supports multiple organizations that do not trust one another, then it must check the values of Location and Content- Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority.


Top updates

Shop Amazon Cyber Monday Deals Week
Google Search


NEWS CONTENTS

News

DNS Spoofing - Cisco Systems

DNS Spoofing

Contents

Restrictions

How to Configure DNS Spoofing

Configuring DNS Spoofing

Configuration Examples for DNS Spoofing

DNS Spoofing: Example

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Command Reference

ip dns spoofing

Glossary


The DNS Spoofing feature is designed to allow a router to act as a proxy Domain Name System (DNS) server and "spoof" replies to any DNS queries using either the configured IP address in the ip dns spoofing ip-address command or the IP address of the incoming interface for the query. This feature is useful for devices where the interface toward the Internet service provider (ISP) is not up. Once the interface to the ISP is up, the router forwards DNS queries to the real DNS servers.

DNS forgery

An attacker with access to your network can easily forge responses to your computer's DNS requests. He can steal your outgoing mail, for example, and intercept your ``secure'' web transactions.

If you're running a DNS server, an attacker with access to your network can easily forge responses from that DNS server to other people. He can steal your incoming mail, for example, and replace your web pages.

An attacker from anywhere on the Internet, without access to the client network and without access to the server network, can also forge responses, although not so easily. In particular, he has to guess the query time, the DNS ID (16 bits), and the DNS query port (15-16 bits). The dnscache program uses a cryptographic generator for the ID and query port to make them extremely difficult to predict; however, an attacker who makes a few billion random guesses is likely to succeed at least once.

(The same attack is much easier with BIND, because BIND uses the same port for every query.)

DNS Spoofing by The Man In The Middle

This paper is based on a vulnerability in the Windows XP DNS resolver. While other parties have recently published this vulnerability, the vulnerability was independently discovered during research for this paper. Using this vulnerability as an example, this paper demonstrates tools and techniques for discovering and investigating security vulnerabilities. The security vulnerability is then escalated to achieve Man In The Middle (MITM) status. A number of tools and techniques for performing MITM attacks are discussed. ...

 

Recommended Links

Softpanorama Top Visited

Softpanorama Recommended

Using BIND: Don't get spoofed again by Matt Larson and Cricket Liu
Good advice on how to secure DNS servers against spoofing attacks.

Men & Mice - What is DNS spoofing

DNS Spoofing techniques By Spacefox, spacefox@securesphere.net
Secure Sphere Crew - January 23rd, 2002

A report about national DNS spoofing in China on Sept. 28, 2002

DNS Spoofing

DNS spoofing - SecureSphere

DNS Spoofing (Malicious Cache Poisoning) - GIAC Certified Student ...

 

Cache Poisoning

SecurityFocus HOME Guest Feature DNS Cache Poisoning - The Next Generation by Joe Stewart, GCIH (jstewart@lurhq.com)


Jan 27 2003 11:30PM GMT

Introduction

The old problem of DNS cache poisoning has again reared its ugly head. While some would argue that the domain name system protocol is inherently vulnerable to this style of attack due to the weakness of 16-bit transaction IDs, we cannot ignore the immediate threat while waiting for something better to come along. There are new attacks, which make DNS cache poisoning trivial to execute against a large number of nameservers running today. The purpose of this article is to shed light on these new attacks and recommend ways to defend against them.

A Brief History of Cache Poisoning

In 1993, Christoph Schuba released a paper entitled "Addressing Weaknesses in the Domain Name System Protocol". In it, he outlined several vulnerabilities, including the technique of DNS cache poisoning. In the earliest incarnation, it was possible to provide extra information in a DNS reply packet that would be cached by the daemon. This allowed an attacker to inject false information into the DNS cache for a network, allowing them to perform man-in-the-middle attacks or other mayhem.

In 1997, CERT released advisory CA-1997-22, describing a vulnerability in BIND, the Berkeley Internet Name Domain software which is used by nearly all of the nameservers on the Internet. This time a very basic principle was finally realized: BIND did not randomize its transaction IDs - they were purely sequential. Aside from layer 3 and 4 protocol checking (source and destination IP addresses and ports must match), the transaction ID is the sole form of authentication for a DNS reply. Because an attacker could easily predict the next transaction ID after making their own request, a cache poisoning attack could be carried out using a spoofed query followed by a spoofed answer. To solve this, all new versions of BIND were updated to use randomized transaction IDs.

In 2002, Vagner Sacramento released an advisory showing another problem with BIND's implementation of the DNS protocol. He found that BIND would send multiple simultaneous recursive queries for the same IP address. Because of this a mathematical phenomenon comes into play known as the "Birthday Paradox". This causes the probability of a successful attack to rise to near 100% with only a few hundred packets instead of the tens of thousands previously believed to be needed.

While researching Sacramento's findings, the CERT team also realized there might be another attack possible, based on the work of Michal Zalewski in the area of TCP sequence numbers and phase space analysis of the psuedo-random number generators used by different operating systems to generate them. Zalewski found that using a certain type of analysis it was often trivial to guess the next sequence number in certain implementations. The CERT team felt that this might also apply to the random number generators in BIND. This article will attempt to show that their assumption was correct.

Attack #1 - The Birthday Attack

To perform this attack, one needs to send a sufficient number of queries to a vulnerable nameserver, while sending an equal number of phony replies at the same time. Because the flaw in the BIND software generates multiple queries for the same domain name at the same time, one encounters statistically improved odds of hitting the exact transaction ID. This is the classic "Birthday Attack", which is derived from the "Birthday Paradox", described below:

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.
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. (unknown author, http://www.x5.net/faqs/crypto/q95.html)

We can apply the same methodology to psuedo-random number sequences, such as the one that generates transaction IDs in BIND.

With conventional spoofing, we would send n spoofed replies for one query. Our probability of success is n / 65535. With the BIND birthday attack, we send n number of spoofed replies for n queries. For this, we can predict the probability of success using the formula below where t is the total number of possible values in the master set, and n is the number of values in the spoofing subset.

The power of this method of spoofing versus conventional DNS spoofing is shown in illustration 2. The birthday attack nears 100% success around 700 packets. At this point the conventional spoofing attack would only have a success probability of 700 divided by 65535 (1.07%) The steepness of the curve is such that one needs only 300 packets to achieve a 50% success ratio. This is well within the realm of a trivial attack to anyone with a broadband Internet connection.

This shows that even a perfect random-number generator is vulnerable to attack when it generates multiple numbers for the same transaction. This is something that should be taken into account by any software designer who is working with random numbers. It has long been used in brute-force attacks on one-way hash systems, as described by Bruce Schneier in his book Applied Cryptography.

The BIND birthday attack would follow the sequence shown in illustration 3. The attacker merely needs to send a few hundred queries to the ISP nameserver asking for the IP address of the domain name to be hijacked. At the same time, he will send the same number of replies formulated to look as if they were sent from the authoritative nameserver. In each packet he will assign a random transaction ID. In order to be successful, one of his spoofed packets transaction IDs, source and destination IP addresses and ports must match a legitimate recursive query packet from the victim nameserver.

Finding the correct IP addresses is easy; we know our target, and we know the addresses of the legitimate nameservers for the domain to be hijacked. Finding the port is slightly harder. We know that the destination port of the recursive query is UDP port 53, but the source port is a moving target. Fortunately for our attacker, BIND will more often than not reuse the same source port for queries on behalf of the same client. So, if the attacker is working from an authoritative nameserver, he can first issue a request for a DNS lookup of a hostname on his server. When the recursive query packet arrives, he can look at the source port. Chances are this will be the same source port used when the victim sends the queries for the domain to be hijacked. Look at the tcpdump output of four subsequent queries for different domain names:

10:54:12.423228 192.168.1.2.33748 > 66.218.71.63.53:  21345 [1au] A? www.yahoo.com. (42) (DF)
10:54:21.313293 192.168.1.2.33748 > 216.239.38.10.53:  53735 [1au] A? www.google.com. (43) (DF)
10:54:27.182852 192.168.1.2.33748 > 149.174.213.7.53:  19315 [1au] A? www.netscape.com. (45) (DF)
10:54:43.252461 192.168.1.2.33748 > 66.35.250.11.53:  43129 [1au] A? www.linux.com. (42) (DF)

All four queries used source port 33748 while querying four different nameservers. If BIND used randomized source ports, it could improve its chances of warding off spoofing attacks.

At this point, all the attacker needs to do is win the race between the first successful collision of his spoofed transactions and the legitimate answer from the true authoritative nameserver. This race is already slanted in favor of the attacker; however, he could utilize other methods to gain an even bigger edge, such as flooding the authoritative nameserver with bogus packets in order to slow down its response time.

After a collision between a legitimate recursive query and a falsified reply packet, the targeted nameserver at the ISP will cache the spoofed record for the time indicated in the TTL section of the reply. At this point the attacker is finished, but the effect lives on for the time the ISP holds the phony record in its nameserver cache. The victim user at the ISP is exposed to the attack any time it makes a query for the domain name in question.

Attack #2: Phase Space Analysis Spoofing

The CERT vulnerability note at http://www.kb.cert.org/vuls/id/457875 made the following observation:

Additionally, Michal Zalewski's paper "Strange Attractors and TCP/IP Sequence Number Analysis" [ZALEWSKI] describes a method for analyzing the predictability of transaction IDs which we believe could be extended to analyze Transaction ID / UDP port pairs as well.

From my observations, it appears they are correct. I downloaded Michal Zalewski's tools for phase space analysis and ran them on a set of 100,000 16-bit numbers generated by BIND 8, BIND 9, and djbdns.

Zalewski's description of phase space analysis of PRNG functions follows:

Phase space is an n-dimensional space that fully describes the state of an n-variable system. An attractor is a shape that is specific to the given PRNG function, and reveals the complex nature of dependencies between subsequent results generated by the implementation. (Zalewski, http://razor.bindview.com/publish/papers/tcpseq.html)

Essentially this means we can tell a lot about how random a PRNG really is by looking at its results in 3-D space. We can also make predictions about the next number in the sequence based on the math involved here.

The tools provided by Zalewski that are used in this article are vseq, a linux svgalib program that visualizes the dataset in 3-D space, and calprob, which tries to predict the probability of guessing the correct next sequence number of a PRNG when given 3 preceding sequence numbers. These tools are contained in this archive: http://razor.bindview.com/publish/papers/tcpseq/vseq.tgz.

BIND 8 PRNG Analysis

Below is the output of the vseq program, showing the dispersion of pseudo-random transaction IDs in 3-D space:

An ideal random number generator would appear as an evenly dispersed cloud. When there are geometric patterns, or "attractors" in the output, this indicates imperfections in the randomness of the data. BIND 8.4.3 clearly shows the randomness following distinct lines with space in between; indicating that there are some numbers that are more likely to be chosen in a sequence than others. If we limit our spoofing set to those numbers, we greatly increase our odds of a collision between a query and a spoofed reply.

Zalewski includes a tool to analyze the probability of successfully guessing the next number from a sequence using attractor analysis. That program accepts 4 arguments; a datafile with 100000 randomly generated numbers, a radius R1, a spoofing set size, and number of tries. Here is the output of that program run against the BIND transaction ID sequence:

./calprob ../bind.nsid.gz 10 1 1
1: Trying 13085 32386 21499 (-> 36312) - r=10
  + guess3d gave 51 answers, rsort suggests R2 of 0...
  -> SUCCESSFUL (difference 0).

Data file:         ../bind.nsid.gz
Failed attempts:   0/1 (0%)
Average R2:        0
Average N:         51
Average error:     0
Average correct N: 3
Probability:       100.0000%

With this algorithm Zalewski's tool predicts a probability of success of 100% with a spoofing set size of 1. In other words, you can mathematically predict the next transaction number with only 3 previous transaction IDs 100% of the time. This is completely independent of the flaw in BIND that allows the Birthday Attack. This pretty much ensures that even if the Birthday Attack is patched against, BIND 8.x will still be vulnerable to cache poisoning as long as it continues to use the same pseudo-random number generator.

BIND 9 PRNG Analysis

BIND 9.x uses a completely new random number generation sequence which uses the /dev/random device available in most modern Unix-type operating systems. When properly seeded with adequate entropy, this device gives us a stream of very random data. Of course, operating systems may implement the random device differently, so that should be taken into account. In this case, the output relied on the random device implementation of the Linux 2.4.19 kernel.

Looking at the vseq program output for BIND 9, we see an interesting snowflake-like pattern. The calprob output gives better results than BIND 8, however:

./calprob ../bind9.nsid.gz 200 5000 10
...
Data file:         ../bind9.nsid.gz
Failed attempts:   0/10 (0%)
Average R2:        75
Average N:         522
Average error:     12
Average correct N: 24
Probability:       20.0000%

According to this, BIND 9's random number sequence is predictable 20% of the time with a spoofing set size of 5000. This is far better than BIND 8, but still leaves opportunity for a dedicated attacker. It would take a fair amount of bandwidth in order to be able to send 5,000 spoofed packets to a target nameserver and beat the authoritative nameserver. However, if the authoritative nameserver was vulnerable to any of the BIND denial-of-service attacks, one could merely kill the authoritative server with a malicious packet and have a one-man race to win. If the denial-of-service attack was combined with the phase-space analysis attack on BIND 8, it would be impossible to detect a spoof with any intrusion detection system, as it would there would be only one query and one answer received.

djbdns PRNG analysis

Looking at djbdns, we see fewer attractors, just a geometric cloud of points (see illustration 6). The calprob output shows the randomness is still not perfect (in fact, it is slightly worse than BIND 9; 30% probability of a successful guess with a spoofing set size of 5000):

./calprob ../djbdns.nsid.gz 200 5000 10
...
Data file:         ../djbdns.nsid.gz
Failed attempts:   0/10 (0%)
Average R2:        33
Average N:         623
Average error:     22
Average correct N: 31
Probability:       30.0000%

This is however offset by the fact that djbdns also generates random numbers for the source port of each query, as evidenced by the tcpdump traffic below:

22:42:41.790753 192.168.1.2.16075 > 64.58.77.85.53:  36904 A? www.yahoo.com. (31) (DF)
22:42:53.876719 192.168.1.2.53928 > 216.239.38.10.53:  1776 A? www.google.com. (32) (DF)
22:43:07.996666 192.168.1.2.59368 > 207.200.73.80.53:  16261 A? www.netscape.com. (34) (DF)
22:43:18.290976 192.168.1.2.9183 > 66.35.250.10.53:  5110 A? www.linux.com. (31) (DF)

In this instance, a unique random source port was used for each query. This forces the attacker to guess transaction ID and source port simultaneously. It is immensely difficult to succeed at such an attack, but as D. J. Bernstein warns on his site:

Note, however, that there are only about a billion possible ID-port pairs, so a prolonged blind attack will succeed eventually. (Bernstein, http://cr.yp.to/djbdns/dns_random.html)

Sub-Attacks

Once an attacker has managed to poison a DNS cache, there are a number of ways she can subvert protocols that rely on DNS. Some of the potential methods are listed below.

Redirecting Web Traffic

An attack of this nature might range from a simple annoyance to a financial nightmare for a great number of people. The goal here is to set up a website that looks enough like the original so as to not raise any suspicion. Then the domain is hijacked via cache poisoning for as many ISPs/companies as possible, causing their traffic to hit the phony site instead. Some of the sub-attacks here are:

Man-in-the-Middle

In this scenario, an attacker tries to intercept secure communication between two parties. For example, Xavier wants to make an online purchase at Yuri's website. The attacker poisons the cache at Xavier's ISP, pointing traffic to Yuri's site to Zamfir's system. Zamfir accepts the incoming SSL connection, decrypts it, reads all the traffic, and makes the same request via SSL to Yuri's site. Replies from Yuri are read by Zamfir then sent back to Xavier over the same encrypted session. Zamfir now has Xavier's credit card number and all other details needed to make illicit use of it.

Recommended Defenses Against DNS Cache Poisoning

Users of BIND

When attempting to protect yourself against a DNS spoofing attack, you have to consider the different aspects of the attack and where you fit in. For instance, do you want to prevent against your users being returned bogus data? Or are you trying to prevent your domain name from being hijacked? In any DNS spoofing attack there are two victims - the hijacked domain owner, who is losing traffic to his site, and the end user who gets redirected to a phony IP address.

Domain Owner

For a domain owner, there is little you can do to protect against someone spoofing your domain name to a vulnerable nameserver. If you are running a webserver, consider using SSL to authenticate yourself to browsers. Eventually DNSSec will allow all domain servers to have cryptographically signed records, but it is not widely implemented at this time. Even detecting such an attack would be difficult, since the hijack would be largely independent of your servers. Be on the lookout for short denial-of-service attacks; they may indicate someone trying to slow your server down temporarily or crash it in order to complete a spoofing attempt.

ISP Nameserver Admin

You can upgrade BIND to the latest version in the 9.x series, which is not vulnerable to this attack. Alternatively you may try using djbdns, an alternative to BIND written by D. J. Bernstein, author of the MTA program qmail. The djbdns software comes with a security guarantee, basically offering a monetary reward to anyone who publicly discloses legitimate buffer-overflow vulnerabilities in djbdns. Although the guarantee doesn't cover cache-poisoning attacks, I will show later in this article that djbdns offers much greater protection against such attacks when deployed properly.

Disable recursive queries from the outside world, using split-split DNS if possible (see illustration 7). Split-split DNS means you have 2 nameservers; one to serve your public domain information to the outside world, and one to do recursive queries for your users. The public server should not allow recursive queries, and the recursive (caching) server should be protected from the Internet by a firewall.

This is sometimes confused with split DNS, where the internal server forwards requests to the outside server which makes recursive queries on its behalf. This arrangement offers no protection against cache poisoning, and should be avoided.

If you cannot use split-split DNS, you should at least try to restrict who can do recursive queries from your nameserver. Using the "allow-recursion" option doesn't give you very much protection - remember, the attacker is already spoofing the source IP address, so it is just a matter of them knowing which addresses are allowed to do recursive queries. If possible, use the "listen-on" option to bind the nameserver daemon to an interface that is protected from the outside world.

End User

Urge your ISP/company to upgrade BIND. If they are not open to this, you can always run your own recursive resolver and bypass the ISP's nameservers. Practice safe computing; keep antivirus software updated and signatures current. Always confirm SSL certificates when making secure online transactions. If you suspect a site is being spoofed, you can make use of the ARIN whois records to determine whether an IP address actually belongs to the organization that owns the domain name.

Vendor

This vulnerability could be remedied by changing the behavior of BIND 8 and 4 to only send one request for any number of queries for the same name. BIND 9 already does this, so it is more likely the vendor will just urge people to upgrade instead. However, BIND 9 also demonstrates the same behavior of reusing source ports. This should be corrected, as it would make any new attacks on the PRNG harder to execute.

Proof-of-Concept Code: spooftest.pl

I have written the following program to demonstrate the feasibility of the BIND Birthday attack. It is a passive demonstration only; it cannot be used to execute an actual attack. It will send n number of queries to a recursive server, while generating a ?spoofing set? which is just an array of psuedo-random numbers. If any of the transaction IDs of the recursive queries coming back from the targeted nameserver match a number in the spoofing set, an attack would have succeeded.

#!/usr/bin/perl

#################################################################
# spooftest.pl                                                  #
# By Joe Stewart                                                #
# Tests to see if a BIND server is vulnerable to the Birthday   #
# Attack spoofing technique described by Vagner Sacramento in   #
# http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.htm    #
#                                                               #
# This script MUST be run from an authoritative nameserver's IP #
# address and must be running in place of the real nameserver   #
# daemon. It sends a number of queries and sees if it can guess #
# a correct transaction ID from the target IP address. If it    #
# guesses correctly, the remote host is considered vulnerable   #
# to the BIND Birthday Attack.  It does not send any replies,   #
# so it is not capable of carrying out an actual attack         #
# (sorry script kiddies)                                        #
#################################################################

use IO::Socket;
use strict;

$| = 1;
my $usage = "Usage: $0 [ip address] [number of packets]\n";

my $target = $ARGV[0];
my $m = $ARGV[1];

die "$usage" unless $ARGV[0] && $ARGV[1];
die "$usage" if $m !~ /^\d+$/ || $m == 0;

my $domain = "mydomain.com"; # domain name with NS RR pointing to us
my $r = 0xdead;              # initial transaction ID for our queries
my @spoofingset;             # list of our guesses
my $total = 65536;           # total possible packets
my $maxlen = 1500;
my $collisions = 0;
my $datagram;

printf "Probability of success using $m packets: %.2f%%\n",
        100 - (((1 - (1 / $total)) ** (($m * ($m - 1)) / 2)) * 100);

for (0..($m - 1)) {
        $spoofingset[$_] = sprintf("%x", int(rand($total - 1)));
}

#print "Spoofing set: ", join(" ", @spoofingset), "\n";

my $server = IO::Socket::INET->new(LocalPort => 53,
                                Proto     => "udp")
    or die "Couldn't be a udp server on port 53 : $@\n";

my $client = IO::Socket::INET->new(PeerAddr => $target,
                                            PeerPort => 53,
                                Proto   => "udp")
    or die "Couldn't be a udp client on port 53 : $@\n";

my ($second, $top) = split(/\./, $domain);
my $findlabel = chr(length($second)) . $second;

my $request = "\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x03" .
              "www$findlabel\x03$top\x00\x00\x01\x00\x01";

for (0..($m - 1)) {
  ## send query with incrementing transaction ID
  $client->send(pack("H*", sprintf("%x",$r++)) . $request);
}
print "Sent $m DNS initial queries to target...\n";

$SIG{'ALRM'} = sub { die "timeout"};
my $count = 0;
eval {
  alarm(30);
  while ($count < $m) {
    $server->recv($datagram, $maxlen);
    my $tid = sprintf("%x", hex(unpack("H*", substr($datagram,0,2))));
    printf "Received recursive query with transaction ID: $tid\r";
    for (@spoofingset) {
        if ($tid eq $_) {
                print "\nMatched TID $tid in spoofing set. Success.\n";
                $collisions++;
        }
    }
    $count++;
  }
  alarm(0);
};

if ($@) { if ($@ !~ /timeout/) { alarm(0); die $!; } }

print "\nReceived $count recursive queries for $m initial queries\n";

if ($count == 0) {
  print "Target not listening or does not answer recursive queries\n";
}
if ($count == 1) {
  print "Target does not appear to be vulnerable\n";
}
if ($collisions > 0) {
  print "Spoofing attack would have been successful with " ,
         "these parameters.\n";
} else {
  print "Spoofing attack unsuccessful in this run.\n";
}

About the Author

Joe Stewart, GCIH, is a Senior Intrusion Analyst with LURHQ Corporation, a managed security services provider located in Myrtle Beach, South Carolina.

References

Albitz, Paul, and Cricket Liu. DNS and Bind. 3rd ed. Sebastopol, CA: O'Reilly & Associates, Inc,1998.

Mockapetris, Paul. RFC 882 - DOMAIN NAMES - CONCEPTS and FACILITIES. Nov. 1983 <http://www.faqs.org/rfcs/rfc882.html >

Mockapetris, Paul. RFC 883 - DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION. Nov. 1983 <http://www.faqs.org/rfcs/rfc883.html >

Schuba, Christoph. Addressing Weaknesses in the Domain Name System Protocol. Aug. 1993 <http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf >.

Sax, Doug. DNS Spoofing (Malicious Cache Poisoning). 12 Nov. 2000. 15 Dec 2002 <http://rr.sans.org/firewall/DNS_spoof.php >.

Internet Software Consortium.15 Dec. 2002 <http://www.isc.org/products/BIND/ >.

Sacramento, Vagner. Vulnerability in the sending requests control of BIND versions 4 and 8 allows DNS spoofing. 19 Nov. 2002. 15 Dec. 2002 <http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html >

CERT/CC Vulnerability Note VU#457875. 5 Dec. 2002. 15 Dec. 2002 <http://www.kb.cert.org/vuls/id/457875 >.

CERT Advisory CA-1997-22 BIND - the Berkeley Internet Name Daemon. 26 May 1998. 15 Dec. 2002 <http://www.cert.org/advisories/CA-1997-22.html >.

How does the "birthday paradox" work? 15 Dec. 2002
<http://www.howstuffworks.com/question261.htm >.

What is a Birthday attack? 15 Dec. 2002 <http://www.x5.net/faqs/crypto/q95.html >.

Schneier, Bruce. Applied Cryptography. 2nd ed. New York: John Wiley & Sons, Inc, 1996.

DNSSEC - Securing the Domain Name System. 15 Dec 2002 <http://www.dnssec.net/ >

Zalewski, Michal. Strange Attractors and TCP/IP Sequence Number Analysis. 21 Apr. 2001. 15 Dec. 2002 <http://razor.bindview.com/publish/papers/tcpseq.html >.

D.J. Bernstein. djbdns: Domain Name System tools. 15 Dec. 2002 <http://cr.yp.to/djbdns.html >




Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2014 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: February 19, 2014