|=------=[ The Impact of RFC Guidelines on DNS Spoofing Attacks ]=------=| by have2Banonymous --[ Contents 1 - Executive Summary 2 - Overview of Basic DNS Spoofing Attacks 3 - Proposed Criteria for DNS Reply Acceptance 4 - Impact of RFC Guidelines on DNS Reply Acceptance Criteria 5 - Example DNS Spoofing Attack 6 - Practical Impact of RFC Guidelines on DNS Spoofing Attacks 7 - Implementation Comparison 8 - Conclusion --[ 1 - Executive Summary This article provides a brief overview of basic Domain Name System (DNS) spoofing attacks against DNS client resolvers. Technical challenges are proposed that should help to both identify attempted attacks and prevent them from being successful. Relevant Request for Comments (RFC) guidelines, used by programmers to help ensure their DNS resolver code meets specifications, are reviewed. This results in the realisation that the RFC guidelines are not adequately specific or forceful to help identify or prevent DNS spoofing attacks against DNS client resolvers. Furthermore, the RFC guidelines actually simplify such attacks to a level that has not previously been discussed in the public domain until now. To highlight the consequences of merely conforming to the RFC guidelines without considering security ramifications, an example DNS spoofing attack against the DNS resolver in Microsoft Windows XP is provided. This illustrates serious weaknesses in the Windows XP DNS resolver client implementation. For example, Windows XP will accept a DNS reply as being valid without performing a thorough check that the DNS reply actually matches the DNS request. This allows an attacker to create malicious generic DNS replies that only need to meet a couple of criteria with predictable values in order to be accepted as a valid DNS reply by the targeted user. This article discusses the practical impact of the issues raised, such as the ability to perform a successful and reasonably undetectable DNS spoofing attack against a large target base of Windows XP users, without the attacker requiring knowledge of the DNS requests issued by the targeted users. Finally, a comparison with the DNS resolver in Debian Linux is supplied. --[ 2 - Overview of Basic DNS Spoofing Attacks When a user types the web site name www.somewebsite.org into their web browser, their computer issues a DNS request to their Internet Service Provider's (ISP) DNS server to resolve the web site name to an IP address. An attacker may attempt to subvert this process by sending the user a DNS reply containing an incorrect IP address, resulting in the user's computer connecting to a computer of the attacker's choice instead of the desired web site. --[ 3 - Proposed Criteria for DNS Reply Acceptance RFC 2535 (Domain Name System Security Extensions) otherwise known as DNSSEC discusses how cryptographic digital signatures can be used to authenticate DNS transactions to help mitigate DNS spoofing attacks. However, the adoption of this technology has been extremely slow. Even without this level of security, it would initially appear that a DNS spoofing attack against a DNS client resolver would be challenging to perform. This challenge results from the following proposed criteria of the DNS reply that must be met for it to be accepted by the computer performing the DNS lookup. Proposed criteria of a DNS reply for it to be accepted: 1) The source IP address must match the IP address that the DNS request was sent to. 2) The destination IP address must match the IP address that the DNS request was sent from. 3) The source port number must match the port number that the DNS request was sent to. 4) The destination port number must match the port number that the DNS request was sent from. 5) The UDP checksum must be correctly calculated. This may require the attacker to spend more time and effort per attack, although some packet generation utilities have the ability to automatically calculate this value. 6) The transaction ID must match the transaction ID in the DNS request. 7) The domain name in the question section must match the domain name in the question section of the DNS request. 8) The domain name in the answer section must match the domain name in the question section of the DNS request. 9) The requesting computer must receive the attacker's DNS reply before it receives the legitimate DNS reply. --[ 4 - Impact of RFC Guidelines on DNS Reply Acceptance Criteria According to the RFC guidelines, it is not necessary for all of these criteria to be met in order for a DNS reply to be accepted. Specifically, criteria 1, 2, 3, 5, 7 and 8 do not have to be met, while criteria 4, 6 and 9 must be met. The following is a devil's advocate interpretation of the RFC guidelines and a detailed discussion of their effect on each criteria. Criteria 1 (source IP address) does not have to be met according to RFC 791 (Internet Protocol) which states that "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)". RFC 1035 (Domain names - implementation and specification) states that "Some name servers send their responses from different addresses than the one used to receive the query. That is, a resolver cannot rely that a response will come from the same address which it sent the corresponding query to". The source IP address can therefore be set to an arbitrary IP address. Regardless, if desired, the attacker can set the source IP address of their DNS replies to that of the targeted user's DNS server. This is especially easy if the targeted user is a dialup ISP user since the ISP may have a friendly "How to setup your Internet connection" web page that specifies the IP address of their DNS server. Criteria 2 (destination IP address) does not have to be met according to RFC 1122 (Requirements for Internet Hosts -- Communication Layers) which states that "For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if it had been addressed to one of the host's IP addresses". Using a broadcast destination address would be most useful for attacking computers on a Local Area Network. Furthermore, a DNS reply may be accepted if it is addressed to any of the IP addresses associated with a network interface. Criteria 3 (source port number) does not have to be met according to RFC 768 (User Datagram Protocol) which states that "Source Port is an optional field". The source port can therefore be set to an arbitrary value such as 0 or 12345. Since the source port number of the DNS reply affects packet dissection by utilities such as Ethereal, a value of 137 is a devious choice since it will be dissected as the NetBIOS Name Service (NBNS) protocol which is based on DNS. As a result, the malicious DNS replies can be made to appear like NetBIOS traffic which is likely to be discarded by the system administrator or investigator as typical NetBIOS background noise. Criteria 4 (destination port number) must be met according to RFC 768 (User Datagram Protocol). However, this value may be predictable depending on the requesting computer's operating system. During testing, Windows XP always used port number 1026 to perform DNS queries, though this value depends on when the DNS Client service started during the boot process. Criteria 5 (UDP checksum) does not have to be met according to RFC 1122 (Requirements for Internet Hosts -- Communication Layers) which states that "the UDP checksum is optional; the value zero is transmitted in the checksum field of a UDP header to indicate the absence of a checksum". Criteria 6 (transaction ID) must be met according to RFC 1035 (Domain names - implementation and specification) which states that the transaction ID is used "to match up replies to outstanding queries". However, this value may be predictable depending on the requesting computer's operating system. During testing, Windows XP did not randomly choose the 16 bit transaction ID value. Rather, Windows XP always used a transaction ID of 1 for the first DNS query performed after the computer was turned on, with the transaction ID simply incremented for subsequent DNS queries. Transaction ID 1 and 2 were used by the operating system to perform a DNS query of time.windows.com. Criteria 7 and 8 (domain name in question and answer section) do not have to be met according to RFC 1035 (Domain names - implementation and specification) which states that the transaction ID is used "to match up replies to outstanding queries" and recommends as a secondary step "to verify that the question section corresponds to the information currently desired". RFC recommendations do not have to be followed, and in the case of an absent question section, the principal that an implementation must accept any datagram that it can interpret appears to apply. Therefore, a DNS reply containing a single answer in the form of an IP address can be matched to the corresponding DNS request based on the transaction ID, without requiring a question section and without resorting to the overhead of processing the domain information in the answer section. Furthermore, an answer section is not even necessary if an Authority section is provided to refer the requesting computer to an authoritative name server (or a DNS server under the attacker's control). Criteria 9 (requesting computer must receive the attacker's DNS reply before it receives the legitimate DNS reply) must be met and remains as the greatest challenge to the attacker. This restriction is difficult to bypass unless the legitimate DNS server is taken out of action to prevent competition with the spoofed DNS reply, or numerous spoofed DNS replies are sent to the targeted user. However, as discussed above, criteria 1 to 8 either do not have to be met or may have predictable values. Therefore an attacker may require no knowledge of the victim's DNS request to have a reasonable chance of performing a successful attack by sending the requesting computer a small number of generic DNS replies. Furthermore, there is a viable workaround to the restrictive nature of this criteria. If the attacker is not trying to compromise a specific computer, a "spray and pray" approach can be used. This approach involves sending a very small number (twenty) of spoofed DNS replies to a maximum number of potential target computers, instead of trying to compromise a specific user and only once they have been compromised then trying to compromise another specific user. This "spray and pray" approach won't compromise every potential victim, and every packet the attacker sends won't result in a compromise, but enough of the attacker's malicious DNS replies will be accepted by enough potential victims to make the exercise worthwhile. --[ 5 - Example DNS Spoofing Attack A DNS spoofing attack using the concepts discussed in this article was performed against a Windows XP computer. The test Windows XP computer was a default install of the operating system followed by the application of Service Pack 1. The Microsoft Internet Connection Firewall shipped with Windows XP was then enabled, and configured to perform full logging of dropped packets and successful connections. The Windows XP user typed the web site URL www.somewebsite.org into Internet Explorer, resulting in a DNS request being sent from the user's computer (IP address 192.168.1.1) to the user's DNS server (IP address 192.168.1.254). A spoofed DNS reply disguised as NetBIOS data was sent to the user from the fake (spoofed) nonexistent IP address 10.10.10.1, specifying that whatever name the user was attempting to resolve had the IP address 192.168.1.77. The IP address 192.168.1.77 was actually a web server under the attacker's control. Internet Explorer connected to 192.168.1.77 and requested the web page. This revealed that the designers of the DNS resolver in Microsoft Windows XP also interpreted the RFC guidelines as described in the previous section, significantly simplifying DNS spoofing attacks. The following network packet decoded by Ethereal version 0.10.3 illustrates the malicious DNS reply and demonstrates how Ethereal can be confused into decoding the packet as NetBIOS traffic. Frame 1 (102 bytes on wire, 102 bytes captured) Ethernet II, Src: 00:50:56:c0:00:01, Dst: 00:0c:29:04:7d:25 Internet Protocol, Src Addr: 10.10.10.1 (10.10.10.1), Dst Addr: 192.168.1.1 (192.168.1.1) User Datagram Protocol, Src Port: 137 (137), Dst Port: 1026 (1026) Source port: 137 (137) Destination port: 1026 (1026) Length: 68 Checksum: 0x0000 (none) NetBIOS Name Service Transaction ID: 0x0003 Flags: 0x8580 (Name query response, No error) Questions: 0 Answer RRs: 1 Authority RRs: 0 Additional RRs: 0 Answers WORKGROUP<1b>: type unknown, class inet Name: WORKGROUP<1b> Type: unknown Class: inet Time to live: 1 day Data length: 4 Data 0000 00 0c 29 04 7d 25 00 50 56 c0 00 01 08 00 45 00 ..).}%.PV.....E. 0010 00 58 bf 58 00 00 00 11 25 89 0a 0a 0a 01 c0 a8 .X.X....%....... 0020 01 01 00 89 04 02 00 44 00 00 00 03 85 80 00 00 .......D........ 0030 00 01 00 00 00 00 20 46 48 45 50 46 43 45 4c 45 ...... FHEPFCELE 0040 48 46 43 45 50 46 46 46 41 43 41 43 41 43 41 43 HFCEPFFFACACACAC 0050 41 43 41 43 41 42 4c 00 00 01 00 01 00 01 51 80 ACACABL.......Q. 0060 00 04 c0 a8 01 4d .....M This packet was created using the following parameters passed to the freely available netwox packet creation utility: netwox 38 --ip4-src 10.10.10.1 --ip4-dst 192.168.1.1 --ip4-protocol 17 --ip4-data 008904020044000000038580000000010000000020464845504643454c45484 643455046464641434143414341434143414341424c0000010001000151800004c0a8014d Alternatively, the following parameters could be used since netwox automatically calculates the UDP checksum: netwox 39 --ip4-src 10.10.10.1 --ip4-dst 192.168.1.1 --udp-src 137 --udp-dst 1026 --udp-data 00038580000000010000000020464845504643454c45484 643455046464641434143414341434143414341424c0000010001000151800004c0a8014d The following shows that the spoofed DNS reply has been added to the user's DNS resolver cache for a period of 1 day, causing future resolutions of www.somewebsite.org to map to the web server under the attacker's control. The cache duration value can be decreased by the attacker so that the entry is either not cached or is immediately removed from the cache in order to remove evidence of the attack. C:\>ipconfig /displaydns Windows IP Configuration 1.0.0.127.in-addr.arpa ---------------------------------------- Record Name . . . . . : 1.0.0.127.in-addr.arpa. Record Type . . . . . : 12 Time To Live . . . . : 604393 Data Length . . . . . : 4 Section . . . . . . . : Answer PTR Record . . . . . : localhost www.somewebsite.org ---------------------------------------- Record Name . . . . . : FHEPFCELEHFCEPFFFACACACACACACABL Record Type . . . . . : 1 Time To Live . . . . : 86364 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 192.168.1.77 localhost ---------------------------------------- Record Name . . . . . : localhost Record Type . . . . . : 1 Time To Live . . . . : 604393 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 127.0.0.1 The following log file from Microsoft's Internet Connection Firewall reveals that it did not provide any protection against the attack, though it is not designed to inspect and correlate DNS traffic. If the firewall was not configured to log successful connections, then there would not have been any log entries. #Verson: 1.0 #Software: Microsoft Internet Connection Firewall #Time Format: Local #Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info 2004-05-10 20:34:56 OPEN UDP 192.168.1.1 192.168.1.254 1026 53 - - - - - - - - 2004-05-10 20:34:57 OPEN-INBOUND UDP 10.10.10.1 192.168.1.1 137 1026 - - - - - - - - 2004-05-10 20:34:57 OPEN TCP 192.168.1.1 192.168.1.77 3010 80 - - - - - - - - 2004-05-10 20:35:30 CLOSE TCP 192.168.1.1 192.168.1.77 3010 80 - - - - - - - - 2004-05-10 20:36:30 CLOSE UDP 192.168.1.1 192.168.1.254 1026 53 - - - - - - - - 2004-05-10 20:36:30 CLOSE UDP 10.10.10.1 192.168.1.1 137 1026 - - - - - - - - It can be seen that when the Windows XP computer sent a UDP packet from port 1026 to port 53 of the DNS server, the firewall allowed all incoming UDP traffic to port 1026, regardless of the source IP address or source port of the incoming traffic. Such incoming traffic was allowed to continue until the firewall decided to block access to port 1026, which occurred when there was no incoming traffic to port 1026 for a defined period of time. This timeframe was between 61 seconds and 120 seconds, as it appeared that the firewall checked once per minute to determine if access to ports should be revoked due to more than 60 seconds of inactivity. Assuming that users connected to the Internet would typically perform a DNS query at least every minute, incoming access to port 1026 would always be granted. An attacker on the Internet could therefore send the Windows XP computer spoofed DNS replies without worrying that they might be blocked by the firewall. Such traffic would not generate any logs if the firewall was configured to only Log Dropped Packets. If the firewall was configured to also Log Successful Connections as in this example, these log entries would disappear among the thousands of other log entries. Since the firewall logs connections and not traffic, if the source IP address was set to the Windows XP computer's DNS server, no extra firewall log entries would be created as a result of the DNS spoofing attack. The netstat command revealed that the Windows XP computer was always listening on UDP port 1026, and as a result, extra DNS replies were silently discarded and did not generate an error message in the event log or an ICMP port unreachable packet. This behaviour, and the reuse of the same source port number for DNS requests, was attributed to the DNS Client service. --[ 6 - Practical Impact of RFC Guidelines on DNS Spoofing Attacks The attacker does not require information about the targeted user's DNS requests, such as the IP address of the user's DNS server, the source port of the user's DNS request, or the name that the user was attempting to resolve to an IP address. Therefore the attacker does not require access to the communication link between the targeted user and their DNS server. Windows XP SP1 matches DNS replies to DNS requests by only the transaction ID and the UDP port number, and both of these values are very predictable. Since the name to be resolved is not matched between the DNS request and the DNS reply, the attacker does not care what domain name the user queried since this domain name does not have to be placed in the attacker's DNS reply. As a result, the attacker can create generic malicious DNS replies that will successfully subvert the targeted user's DNS lookup process regardless of the name the targeted user was attempting to resolve, and regardless of the targeted user's network configuration such as the IP address of their DNS server. An attacker desiring to compromise as many computers as possible with the least amount of effort and in the shortest timeframe could send twenty DNS replies that look similar to the generic DNS reply used in the example attack on Windows XP in this article, though with the transaction ID ranging from 3 to 22. To be more thorough, the attacker could instead send one hundred DNS replies with the destination port number ranging from 1025 to 1029. The attacker would use a "spray and pray" approach by sending these DNS replies to every IP address in the IP address range belonging to a large dialup Internet Service Provider, and when finished, repeating the process. A level of success is guaranteed in such an attack scenario considering the huge target base of potential victims awaiting a DNS reply, and considering that Windows XP accepts anything vaguely resembling a DNS reply as a valid DNS reply. A recipient of the attacker's twenty DNS replies will accept one of them as being valid, resulting in a successful attack, if the recipient: - is using Windows XP with its poorly implemented DNS client resolver (most dialup Internet users are in this category). - recently connected to the Internet within the last 10-20 minutes or so and therefore haven't performed more than twenty DNS requests (a reasonable proportion of dialup Internet users are in this category). - recently performed a DNS request and is awaiting a DNS reply (a reasonable number of the huge target base of dialup Internet users are in this category). The targeted Windows XP users would be unlikely to notice the attack, especially if they were relying on Microsoft Internet Connection Firewall to protect them. Analysis of the logs of a more sophisticated firewall and inspection of network traffic would not readily reveal a DNS spoofing attack since the source IP address would not be that of the legitimate DNS server. Furthermore, the source port number and content of the spoofed DNS replies can be crafted to make them appear to be typical NetBIOS background noise which would probably be discarded by the user as useless network traffic floating around the Internet. Finally, the targeted IP address range of a dialup ISP would consist mainly of home Internet users who are not educated in advanced network security concepts. The IP address in the spoofed DNS replies could be a computer on the Internet under the attacker's control, which is running proxy software for email (SMTP and POP3) and HTTP traffic. The attacker would be able to collect sensitive information including email sent and received as well as passwords for future email retrieval. Web based email and unencrypted login details to web sites would also be collected. The attacker could add content to HTML pages before returning them to the user. Such content could include banner ads to generate money, or a hidden frame with a link to a file on a third party web site effectively causing a distributed denial of service attack against the third party. More seriously, the attacker could increase the scope of the compromise by adding HTML content that exploited one of the publicly known vulnerabilities in Internet Explorer that allows the execution of arbitrary code, but for which there is no vendor patch. For example, vulnerabilities discussed at the web site http://www.computerworld.com.au/index.php?id=117316298&eid=-255 The "spray and pray" attack approach is useful for creating a network of semi-randomly chosen compromised computers under the attacker's control, otherwise known as a botnet. Proxying of HTTP/1.1 traffic could be performed by inspecting the HOST header to determine which web site the user wanted to visit. However, for the purpose of easily and seamlessly proxying traffic, an attacker may decide not to place an Answer section in the spoofed DNS replies. Rather, the attacker may send a non-authoritative spoofed DNS reply using the Authority and Additional sections of DNS replies to refer the requesting computer to a DNS server under the attacker's control. This would allow the attacker to know exactly what domain the victim computer was attempting to query, and furthermore such spoofed DNS replies may have a long lasting and widespread effect on the victim's computer. A detailed discussion of DNS referrals and testing whether Windows XP could handle them is outside the scope of this article. --[ 7 - Implementation Comparison Contributors to the Linux operating system appear to have taken a hardline security conscious approach to interpreting the RFC guidelines, bordering on non-conformance for the sake of security. The Mozilla web browser running on the author's Debian Linux computer was very restrictive and required DNS replies to meet all of the above nine criteria except for criteria 5, where a UDP checksum value of zero was accepted. An incorrect UDP checksum was accepted when the packet was sent over a local network but not when sent over the Internet. Reviewing the kernel source code indicated that for local networks, the UDP checksum was deliberately ignored and hardware based checking was performed instead for performance reasons. This appeared to be a feature and not a bug, even though it did not comply with RFC 1122 (Requirements for Internet Hosts -- Communication Layers) which states that "If a UDP datagram is received with a checksum that is non-zero and invalid, UDP MUST silently discard the datagram". During testing, the Linux computer used source port numbers 32768 and 32769 to perform DNS queries. The transaction ID was randomly generated, complicating DNS spoofing attacks, though the transaction ID used in the retransmission of an unanswered DNS request was not as random. The choice of transaction ID values appeared robust enough to help defend against DNS spoofing attacks on the Internet since the initial transaction ID value was unpredictable, and the first DNS request would typically be answered resulting in no need for retransmissions. The iptables firewall on the Linux computer was configured so that the only allowed UDP traffic was to/from port 53 of the legitimate DNS server. When a DNS query was performed and a DNS reply was received, iptables was unable to block extra (spoofed) incoming DNS replies since it is not designed to inspect DNS traffic and allow one incoming DNS reply per outgoing DNS request. However, since the port used to send the DNS query was closed once a valid DNS reply was received, ICMP port unreachable messages were generated for the extra (spoofed) incoming DNS replies. iptables was configured to block and log outgoing ICMP network traffic. Reviewing the logs revealed ICMP port unreachable messages that were destined to the legitimate DNS server, which were a good indication of a DNS spoofing attack. Further to this evidence of a DNS spoofing attack, since the DNS replies must come from port 53, analysis of the network traffic using a packet dissector such as Ethereal revealed traffic that looked like DNS replies apparently originating at the legitimate DNS server. --[ 8 - Conclusion The RFC guidelines simplify DNS spoofing attacks against DNS client resolvers since the attacker does not require information such as the IP address of the potential victim's DNS server or the contents of DNS queries sent by the potential victim. Microsoft Windows XP is more susceptible to DNS spoofing attacks than Linux due to its poor implementation of the RFC guidelines. Further simplifying DNS spoofing attacks are Windows XP's inadequate matching of DNS requests to DNS replies, and the predictable port number and transaction ID values - behaviour that could be changed without violating the RFC guidelines. Evidence of DNS spoofing attacks is minimised by the ability to disguise DNS replies as NetBIOS traffic, the lack of configuration granularity and traffic inspection of some firewalls, and Windows XP's failure to generate ICMP error messages for excessive DNS replies. RFC 791 (Internet Protocol) stating that a program must be "liberal in its receiving behavior" and "must accept any datagram that it can interpret" may have been acceptable in 1981 when the RFC was created and interoperability was more important than security. However, the Internet has changed from a somewhat trustworthy user base of representatives from educational institutions and the US Department of Defense to now include hackers and scammers, making security a high profile consideration. Perhaps it is time for software based on this outdated perception of the Internet to be changed as well. The Internet community continues to wait for widespread adoption of cryptographic digital signatures used to authenticate DNS transactions, as discussed in RFC 2535 (Domain Name System Security Extensions). In the meantime, the threat of DNS spoofing attacks could be minimised by Microsoft improving the DNS implementation in all of their affected operating systems. Such improvements include using random transaction ID values, checking that the name in a DNS reply matches the name to be resolved in the DNS request, and using a random source port for DNS requests. These improvements would make attacks against DNS client resolvers significantly more difficult to perform, and such improvements would not violate the RFC guidelines.