Detecting and Reacting to a DNS Cache Poisoning Attack

In February 2005, it was discovered that the default configuration of Windows NT 4 and 2000 DNS servers and some Symantec Gateway products left them open to a DNS cache-poisoning attack.4 This vulnerability was exploited on the Internet by an attack in which a set of rogue DNS servers was used to advertise false DNS records to vulnerable downstream DNS servers so that legitimate user requests for some domains could be directed to IP addresses of the attacker's choosing.

To make an arbitrary DNS server "downstream" from one of the rogue DNS servers, the attacker just needed to get the targeted server to issue a DNS request to the rogue server. This could be accomplished in a variety of ways, such as sending an email to a bogus user, thus eliciting a non-delivery report (NDR) to the source domain—this requires a mail server to be running on the targeted network, or by issuing a request to the malicious server from a previously installed piece of spyware.

In the bleeding-all.rules file provided by http://www.bleedingsnort.com, Snort ID 2001842 detects when a system that is part of the internal network issues a DNS request for one of the malicious domains that took part in the DNS cache-poisoning attack, 7sir7.com. We can have fwsnort alert us to this fact by translating the rule into an iptables policy and executing the resulting fwsnort.sh script:

[iptablesfw]# fwsnort --snort-sids 2001842

[+] Found sid: 2001842 in bleeding-all.rules

Successful translation. [iptablesfw]# /etc/fwsnort/fwsnort.sh [+] Adding bleeding-all rules. Rules added: 2

4 See http://isc.sans.org/presentations/dnspoisoning.php for a comprehensive write-up of the DNS cache-poisoning attack and the strategy used by the attackers.

The original Snort rule identified by SID 2001842 and its iptables equivalent appear in the FWSNORT_FORWARD chain to which packets are jumped from the built-in FORWARD chain:

alert udp $HOME_NET any -> any 53 (msg: "BLEEDING-EDGE Possible DNS Lookup for DNS Poisoning Domain 7sir7.com"; content:"|05|7sir7|03|com"; nocase; reference:url,isc.sans.org/diary.php?date=2005-04-07; classtype: misc-activity; sid:2001842; rev:3;)

$IPTABLES -A FWSNORT_FORWARD -p udp --dport 53 -m string --hex-string " 05| 7sir7|03|com" --algo bm -m comment --comment "sid:2001842; msg:BLEEDING-EDGE Possible DNS Lookup for DNS Poisoning Domain 7sir7.com; classtype:misc-activity; reference:url,isc.sans.org/diary.php?date=2005-04-07; rev:3; FWS:1.0;" -j LOG --log-ip-options --log-prefix "[1] SID2001842 "

In order to show that the fwsnort rule actually works, we simulate the traffic needed to cause a signature match from an internal host. Again, we use the network diagram in Figure 1-2 to help illustrate this example.

The dnsserver host simulates a request as if it does not yet have an "A" record mapping www.7sir7.com to an IP address, and so it must issue a request that will eventually query the authoritative (malicious) DNS server for the 7sir7.com domain. We don't need (or want!) an internal system that is actually vulnerable to the cache-poisoning attack in order to test whether our fwsnort ruleset works; it is sufficient to manufacture a UDP packet that contains the consecutive bytes |05|7sir7|03|com from any system on the internal network to any external IP address with a destination port of 53.

We can easily craft this packet by using the single Perl command shown below on the dnsserver system and piping the output to Netcat to send it over the network to an IP address that represents a malicious DNS server:

[dnsserver]$ perl -e 'print "\x057sir7\x03com"' | nc -u 234.50.X.X 53

On the iptablesfw firewall system, we see that, indeed, iptables has detected the suspicious packet and has created the following log message in /var/log/messages (note the [1] SID2001842 logging prefix):

[iptablesfw]# grep SID2001842 /var/log/messages | tail -n 1

Jul 7 22:31:43 iptablesfw kernel: [1] SID2001842 IN=eth1 OUT=eth0 SRC=192.168.10.4 DST=234.50.X.X LEN=38 TOS=0x00 PREC=0x00 TTL=62 ID=36070 DF PROTO=UDP SPT=16408 DPT=53 LEN=18

Because we did not supply either the --ipt-drop or --ipt-reject command-line arguments to fwsnort when we translated the cache-poisoning signature, iptables made no effort to prevent the suspicious packet from exiting the network. We can confirm this by running a packet trace on the external interface of the firewall and executing the same Perl command above:

[iptablesfw]# tcpdump -i eth0 -l -nn port 53 and host 234.50.X.X -s 0 -X tcpdump: verbose output suppressed, use -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 22:41:22.683862 IP 71.157.X.X.16414 > 234.50.X.X.53: [|domain]

0X0000: 4500 0026 64fc 4000 3e11 fce1 0000 0000 E..&[email protected]>

0x0010: 0000 0000 401e 0035 0012 86e50537 7369 [email protected] 7si

0x0020: 7237 0363 6f6d r7.com \

In the tcpdump output shown in bold above are the hex codes that show the exact application layer data associated with the cache-poisoning signature. This proves the packet is forwarded through the iptables firewall.

But fwsnort does not need to remain complacent and just log the DNS cache-poisoning attack above. In this example, we instruct it to drop the DNS request to the cache-poisoning domain, redeploy the resulting iptables policy, simulate the request from the dnsserver system once again, and examine the iptables log:

[iptablesfw]# fwsnort --snort-sids 2001842 --ipt-drop

[+] Found sid: 2001842 in bleeding-all.rules

Successful translation. [iptablesfw]# /etc/fwsnort/fwsnort.sh [+] Adding bleeding-all rules. Rules added: 2

[dnsserver]$ perl -e 'print "\x057sir7\x03com"' | nc -u 234.50.X.X 53 [iptablesfw]# grep SID2001842 /var/log/messages |tail -n 1 Jul 7 22:33:42 fw kernel: [1] DRP SID2001842 IN=eth1 OUT=eth0 SRC=192.168.10.4 DST=234.50.X.X LEN=38 TOS=0x00 PREC=0x00 TTL=62 ID=36070 DF PROTO=UDP SPT=16408 DPT=53 LEN=18

This time, the logging prefix has changed. Instead of just

[1] SID2001842

we now have

[1] DRP SID2001842

The DRP string indicates that iptables has dropped the DNS request in addition to logging it. This is confirmed by once again running a packet trace on the external firewall interface and seeing that the request never makes it through.

NOTE Instead of DROP and REJECT, fwsnort uses DRP and REJ because there is a 29-character limit imposed by the iptables LOG match for logging prefixes. You'll find additional information about what is going on behind the scenes with the --ipt-drop and --ipt-reject options in Chapter 11.

Was this article helpful?

0 0

Post a comment