Network Working Group Francisco J. Gomez Internet-Draft Nova Notio.Inc BCP: XXX Carlos Juan Diaz Category: Best Current Practice Telefonica R&D Expires: January 6, 2012 July 5, 2011 Preventing use Nameservers as malware distribution platform draft-cmd-prevent-malware-dns-distribute-00 Abstract This document describes ways to prevent the use of unsafe configured recursive nameservers as platform in malware distribution process. It provides recommended configuration as measures to mitigate the misuse. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 6, 2012. Table of Contents Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 2 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 4. Recommended Configuration . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Gomez & Diaz Best Current Practice [Page 1] RFC XXXX Prevent use NS as malware distrib. platform July 5, 2011 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Recently, DNS [RFC1034] has been named as one of the best alternative on distribution process in botnets life cycle. These situation are not due to any particular flaw in the design of the DNS or its implementations, except that DNS can be considered an expensive protocol to monitor, the easy abuse of which is at the source of the problem. The attack is possible due to configurations aimed at saving resources. DNS Cache nameservers provide recursion to clients can also be used as storage platform; Hence, this potential storage capacity can convert these nameservers a fundamental part of in the distribution of information on botnets. This document's recommendations are concerned with all kind of nameservers. In this document we describe the characteristics that permit take advantage on DNS service an DNS servers and recommend DNS server configurations that specifically alleviate the problem described. 2. Document Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. "NAME SERVERS" - are server programs which hold information about the domain tree's structure and set information. When sending a DNS query to an IP address, a DNS response of any type (including SERVFAIL) indicates the presence of a DNS server. "DNS ROUTE" - a particular name server which has complete information about a subset of the domain space, and pointers to other name servers that can be used to lead to information from any part of the domain tree. Used to implement the DNS hierarchy. "AUTHORITY NAMESERVERS" - name servers that know the parts of the domain tree for which they have complete information. Authoritative information is organized into units called ZONEs, and these zones can be automatically distributed to the name servers which provide redundant service for the data in a zone. Gomez & Diaz Best Current Practice [Page 2] RFC XXXX Prevent use NS as malware distrib. platform July 5, 2011 "RECURSIVE NAMESERVERS" - resolve any query they receive, even if they are not authoritative for the question being asked, by consulting each authoritative name server in turn, starting from the DNS root zone. It continues until it reaches the authoritative server for the zone that contains the queried domain name. Recursive name queries are generally made by a DNS client to a DNS server. "OPEN RESOLVER" - provides recursive name resolution for clients outside of its administrative domain. "OPEN EMITTER" - open resolver that use the same IP address to attend clients and to query authoritative name servers. "CACHING NAME SERVERS" - store DNS query results for a period of time (time-to-live), are often also open resolvers, are sometimes also open emitters. "Command and Control (C&C)" - server that control a certain number of machines called bots. Is responsible for maintaining the botnet. Send orders and receives information. 3. Problem Description Because usually DNS traffic is not inspected as it should, a compromised host, common named 'bot', could use DNS protocol and DNS architecture to get update payloads . The generic process may follow the next steps: 1. Encoding. The attacker, botmaster, starts configuring a name server with all payload parts. These process consider this posible steps: a. Compress the piece of malware, payload, using any known compression algorithms. b. Encode the compressed payload using any compression algorithm. c. Split encoded payload based on protocol restrictions [RFC 1035]. Also can be used extension mechanisms for DNS defined on EDNS0 STD [RFC2671]. d. Transform created parts into a RRs (Resource Records) that compose the DNS responds. Always based on DNS protocol standard [RFC 1035]. 2. Publish. Publish process is the next step, and a critical time to attacker. Consists of registering of the domain used in the Gomez & Diaz Best Current Practice [Page 3] RFC XXXX Prevent use NS as malware distrib. platform July 5, 2011 distribution process. This domain will support the subdomains that compose the serialized payload.For this domain selection can use Fast-Flux techniques. 3. Loading. Once the domain or subdomain has been included in the DNS tree hierarchy (Publish process) attacker can force caching by DNS server (Open Emitter) using the server side IP address and query for each RR. 4. Hiding. This step is the method/attack master key. Malware source must disappear before first download. Being an asynchronous communication one of the main goals, once the cache server (Open Emitter) has loaded each of the records, that make up the payload, becomes authoritative server for domain used in the distribution process. 5. Downloading. While on TTL allows 'bots' can request for each RR and reassemble them into a payload file. Because during the process of hiding the server Open emitter used is published in the hierarchical tree used as domain nameserver. An infected DNS client, which is located on a network with limited Internet access (like a corporate environment) and can only query to default network DNS. Could get each RR and build the original payload using the information stored in the RRs. Use malware distribution across DNS method provides best degree concealment for malware origin, the C&C. Becomes the communication between the C&C and bot to asynchronous process. And the source of the malware payload, is a legitimate server. Using DNS protocol allows go unnoticed to pass through firewall and IDS. DNS is present in almost all networks and interconnected devices to the Internet. The main use refers for follow-on data for sending updates and even send orders to bots. The amount of data that can be transported over each is limited by DNS protocol. As increase number of encapsulated data, increase the chances of being detected by inspection methods and traffic monitoring. Based on DNS protocol described in [RFC1035] limitations of encapsulated data amount using type A and CNAME records are four hundred bytes average on each response. The ability of sending a greater number of data per request involves exposure of the communication. May be easier to detect. To increase capacity can use the extensions described in [RFC2671]. Gomez & Diaz Best Current Practice [Page 4] RFC XXXX Prevent use NS as malware distrib. platform July 5, 2011 4. Recommended Configuration In this section we describe the Best Current Practice for operating recursive nameservers and authoritative nameservers. Following these recommendations would reduce the chances of any given recursive nameserver being used as a malware distribution platform. By default, authorative nameservers SHOULD NOT offer recursive service to external networks. Following recommendations are focused on servers that operate as cache and imply a dynamic process using statistical models. o Establish a lower TTL considering to the server, service and performance. o Set thresholds for domain depth. Considering known exceptions, such as query formats IPv6 address defined in [RFC5782] section 2.4. o Making an assessment of the amount of the subdomains in the same level. o Implement rate-limits policy. Set a limit to the number of requests allowed to a particular customer. Following recommendations illustrate possible situations must be taken into account when processing requests or responds flags. o "RECURSIVE NAMESERVERS" SHOULD accept only queries where the RD flag (recursion desired) is set. o "AUTHORITY NAMESERVERS" SHOULD NOT respond to client queries advertising that it allows recursion, using RA flag (recursion allowed). o "AUTHORITY NAMESERVERS" that are also "OPEN RESOLVERS": - SHOULDdf accept only queries where the RD flag (recursion desired) is NOT set, if server is authoritative for QNAME. AA flag (authoritative answer) MUST be used in response. - SHOULD accept only queries where the RD flag (recursion desired) is set, if server is not authoritative for QNAME. AA flag (authoritative answer) MUST NOT be used in response. o "CACHING NAME SERVERS" SHOULD NOT store the ANSWER SECTION on response, if AA flag (authoritative answer) is NOT set. Gomez & Diaz Best Current Practice [Page 5] RFC XXXX Prevent use NS as malware distrib. platform July 5, 2011 5. Security Considerations This document does not create any new security issues for the DNS protocol, it deals with a weakness in implementations and configurations. Below are some safety measures to be implemented in order to detect and to mitigate. Using some kind of intrusion detection or traffic inspection systems may perform the following checks on DNS traffic. o Make frequency distribution analysis of Lowest Level Domains (LLDs). o Monitoring non usual RR types like SRV or TXT. o Analyze DNS responses that include loopback or RFC1918 address space [Brom2011]. o Track DNS queries to Dynamic DNS service providers [Brom2011]. o Check DNS queries that are not followed by a proxied request for connection (such as HTTP,FTP, or other expected data trans [Brom2011]. Involves an overload. In order to maintain proper safety level it is recommend including the following log events: o Log suspicious long TTL authoritative responds. o Log incorrect flags in authoritative responds. o Log anormal subdomain depth for a domain. Example over a period of time. o Log anormal number of different subdomains for a domain. o Log any exception flag processed. 6. Acknowledgments The authors would like to acknowledge the helpful input and comments of Telefonica R&D Hacking Team. 7. References 7.1. Normative References Gomez & Diaz Best Current Practice [Page 6] RFC XXXX Prevent use NS as malware distrib. platform July 5, 2011 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010. 7.2. Informative References [Brom2011] Bromberger, S., "WP2011-01-01: DNS as a Covert Channel Within Protected Networks", NESCO, January 2011. [Siss2010] Sisson, G., "DNS Survey: October 2010", 2010 The Measurement Factory, November 2010. [Kami2004] Kaminsky, D., "Attacking Distributed Systems: The DNS Case Study", Black Hat Japan, October 2004. Authors' Addresses Francisco J. Gomez Nova Notio, Inc. Ramirez de Arellano, 17, 4th Floor Madrid, 28043 ES Phone: +34 914 134 696 EMail: ffranz@iniqua.com Carlos J. Diaz Telefonica I+D Distrito C, Oeste 1, Ronda de la Comunicacion, s/n Madrid, 28050 ES Phone: +34 913 128 776 EMail: charlie@tid.es Gomez & Diaz Best Current Practice [Page 7] RFC XXXX Prevent use NS as malware distrib. platform July 5, 2011 Full Copyright Statement Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, THE INTERNET ENGINEERING TASK FORCE AND ANY APPLICABLE MANAGERS OF ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Gomez & Diaz Best Current Practice [Page 8] RFC XXXX Prevent use NS as malware distrib. platform July 5, 2011 This Internet-Draft will expire on January 6, 2012. Gomez & Diaz Best Current Practice [Page 9]