draft-otis-spf-dos-exploit-01.txt | draft-otis-spf-dos-exploit-01-english-noplugs.txt | |||
---|---|---|---|---|
individual D. Otis | individual D. Otis | |||
Internet-Draft Trend Micro, NSSG | Internet-Draft Trend Micro, NSSG | |||
Expires: December 26, 2006 June 24, 2006 | Expires: December 26, 2006 June 24, 2006 | |||
SPF DoS Exploitation | SPF DoS Exploitation | |||
draft-otis-spf-dos-exploit-01 | draft-otis-spf-dos-exploit-01-english-noplugs | |||
(translated by Julian Mehnle <julian@mehnle.net>) | ||||
(Hey, Doug, substance is everything!) | ||||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 41 | skipping to change at line 43 | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on December 26, 2006. | This Internet-Draft will expire on December 26, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
This document describes an email induced Denial of Service threat | This document describes an email-induced Denial of Service threat from | |||
from SPF script used to evaluate the association of a source domain- | SPF, which is used to evaluate the association of a source identity | |||
name with the sending-system. The SPF script attempts to establish | domain-name with the sending-system IP address. SPF aims to establish | |||
the domain-name association through the construction of an extensive | the domain-name association through the enumeration of the IP | |||
IP address list of all sending-systems. Expectations of an | addresses of all sending-systems for the domain-name. | |||
association have become problematic, as message handling might be | ||||
negatively affected without an apparent domain-name relationship | ||||
discovered between the sending-system and either the message envelope | ||||
or the message itself. | ||||
There is a safe name-based alternative to the SPF method that | There are multiplicative effects when a large number of common DNS | |||
associates a source domain-name with the sending-system by | resources are relied upon by a sequence of Mail Handling Systems (MHS) | |||
conditionally comparing a list of domain-names against a verified | forwarding a message. The two indirect SPF mechanisms, "ptr" and | |||
EHLO. This alternative name-based association follows the | "mx", makes SPF a highly dangerous method to verify an anonymous SMTP | |||
verification of the sending-system's EHLO. Each of the two steps in | client's authorization. | |||
this alternative approach involves only a single DNS transaction. | ||||
Initially verifying the EHLO of the sending-system avoids the | ||||
multiplicative effects created when a large number of common DNS | ||||
resources are relied upon by a sequence of Mail Handling Systems | ||||
(MHS) forwarding a message. A verified EHLO also provides a name- | ||||
based identifier for establishing requisite DoS protections. The two | ||||
SPF indirect references found in the text script, PTR, and MX records | ||||
makes this scheme a highly dangerous method to verify an anonymous | ||||
SMTP client's authorization. Dramatic reductions in the scale of the | ||||
potential impact is accomplished by limiting common resources used | ||||
for evaluating a domain-name to that of a single conditional DNS | ||||
transaction. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Defense against Denial of Service Attacks . . . . . . . . . . 5 | 3. Defense against Denial of Service Attacks . . . . . . . . . . 5 | |||
4. The Exploit Example . . . . . . . . . . . . . . . . . . . . . 8 | 4. The Exploit Example . . . . . . . . . . . . . . . . . . . . . 8 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
7. Informative References . . . . . . . . . . . . . . . . . . . . 11 | 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 | |||
skipping to change at page 4, line 10 | skipping to change at line 75 | |||
Appendix B. Example Traffic Qualifying | Appendix B. Example Traffic Qualifying | |||
jo@cert-test.mail-abuse.org . . . . . . . . . . . . . 15 | jo@cert-test.mail-abuse.org . . . . . . . . . . . . . 15 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 63 | Intellectual Property and Copyright Statements . . . . . . . . . . 63 | |||
1. Introduction | 1. Introduction | |||
Two experimental RFCs "Sender Policy Framework (SPF) for Authorizing | Two experimental RFCs "Sender Policy Framework (SPF) for Authorizing | |||
Use of Domains in E-Mail, Version 1" [RFC4408] and "Sender ID: | Use of Domains in E-Mail, Version 1" [RFC4408] and "Sender ID: | |||
Authenticating E-Mail" [RFC4406] relate various email source domains | Authenticating E-Mail" [RFC4406] relate various email source domains | |||
with the IP address of the SMTP client by assembling an extensive | with the IP address of the SMTP client by assembling an extensive list | |||
list of IP addresses. Both drafts utilize the SPF script syntax to | of IP addresses. Both drafts use TXT RRs to describe those lists of | |||
manipulate names and content of Resource Records (RRs) obtained | IP addresses using the SPF syntax defined in [RFC4408]. An additional | |||
through DNS transactions. The SPF script is stored in one or more | lookup may be required to ascertain whether SPF specific RR types are | |||
TXT RRs that are intended to hold generic character-strings. An | being used instead of TXT RRs. | |||
additional lookup may be required to ascertain whether SPF specific | ||||
RR types are being used instead of TXT RRs. | ||||
SPF script employs string related macros, Address RRsets containing | SPF employs string related macros, Address RRsets ("ip4" and "ip6" | |||
IP address information, MX RRsets containing the name and preference | mechanisms) containing IP address information, MX RRsets containing | |||
numbers of Mail Transfer Agents (MTAs), and the PTR RRsets located in | the names of Mail Transfer Agents (MTAs), and the PTR RRsets located | |||
the reverse reference IP address domains. Although this SPF script | in the reverse reference IP address domains. Although SPF can be | |||
can be utilized in a number of ways, normally the intent is to return | utilized in a number of ways, normally the intent is to return IP | |||
IP addresses of all systems directly involved with sending messages | addresses of all systems directly involved with sending messages for a | |||
for a particular domain. In doing so, SPF drastically alters the | particular domain. In doing so, SPF drastically alters the scale of a | |||
scale of a DNS answer. The SPF script may define these addresses | DNS answer. An SPF record may define these addresses with CIDR | |||
with CIDR notation and/or lookups of various RRsets. | notation and/or lookups of various RRsets. | |||
The SPF script places limits on the number of DNS transactions | SPF limits the number of DNS lookups permitted at each Mail Handling | |||
permitted at each Mail Handling Service (MHS) in the path of the | System (MHS) in the path of the message when evaluating each source | |||
message when evaluating each source domain-name. SPF script may | domain-name. An SPF record may invoke 10 DNS lookups for various | |||
invoke 10 DNS transactions for various RRsets, where up to 10 | RRsets, where up to 10 follow-on DNS lookups may then occur. When the | |||
follow-on DNS transactions may then occur. When the script does not | record does not provide a PASS result, an additional lookup might be | |||
provide a PASS result, an additional lookup might be made to obtain a | made to obtain a macro expanded explanation TXT RR. As an example, | |||
macro expanded explanation TXT RR. As an example, evaluating just | evaluating just one domain-name per MHS may involve lookups for 1 TXT | |||
one domain-name per MHS may involve lookups for 1 TXT RR, 10 MX | RR, 10 MX RRsets, and 100 A RRsets for a total of 111 DNS lookups. | |||
RRsets, and 100 A RRsets for a total of 111 DNS transactions. While | While there can be 11 SPF TXT RRs in different domains, each of the 10 | |||
there can be 11 SPF TXT RRs containing script in different domains, | MX mechanism RRsets can contain 10 unique domain-names that span 100 | |||
each of the 10 MX mechanism RRsets can contain 10 unique domain-names | victim domains. | |||
that span 100 victim domains. | ||||
Currently, there are two different domain-names in a message that are | Currently, there are two different domain-names in a message that are | |||
evaluated using SPF records. There is the [RFC2821].MailFrom, and | evaluated using SPF records. There is the [RFC2821].MailFrom, and | |||
the experimental and proprietary "Purported Responsible Address in | the experimental and proprietary "Purported Responsible Address in | |||
E-Mail Messages" [RFC4407], where verifying each domain-name | E-Mail Messages" [RFC4407], where verifying each domain-name | |||
separately invokes the SPF evaluation process. There have been | separately invokes the SPF evaluation process. | |||
suggestions that the [I-D.ietf-dkim-base] Signing-Domain might also | ||||
be evaluated using SPF, where multiple signatures from different | ||||
domains can also exist. | ||||
SPF script is not predicated upon verifying the domain controlling | ||||
the MTA. Obfuscation of the controlling domain may even erroneously | ||||
shift accountability onto the often hapless email-address domain | ||||
owners who typically rely upon third-party services and may publish | ||||
open-ended address lists. The address-list approach prevents fair | ||||
name-based accrual of MTA behaviors as a means to establish effective | ||||
DoS protections. To be effective, a DoS protection scheme must | ||||
indicate specifically what domain is in control. SPF scripts might | ||||
reference only victim domains unrelated to the control of the MTA, | ||||
and provide inconclusive results subsequent to the evaluation. | ||||
2. Definitions | 2. Definitions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
Terminology: Terminology conforms to [I-D.crocker-email-arch]. | Terminology: Terminology conforms to [I-D.crocker-email-arch]. | |||
RR: A DNS Resource Record. | RR: A DNS Resource Record. | |||
RRset: Resource Records of the same type and name location. | RRset: Resource Records of the same type and name location. | |||
Victim Domain: A domain not causing the transaction. | Victim Domain: A domain not causing the transaction. | |||
Open-ended: Not all valid elements are included in the set. | Open-ended: Not all valid elements are included in the set. | |||
3. Defense against Denial of Service Attacks | 3. Defense against Denial of Service Attacks | |||
The DoS concern specific to SPF scripts is manifold. SMTP is a store | The DoS concern specific to SPF records is manifold. SMTP is a store | |||
and forward protocol that distributes the SPF script threat to | and forward protocol that distributes the SPF-related threat to | |||
otherwise reputable MHS. This distribution multiplies the impact of | otherwise reputable MHSs. This distribution multiplies the impact of | |||
the script when many common DNS resources from multiple domains are | an SPF record when many common DNS records from multiple domains are | |||
utilized by subsequent MHS. By encompassing multiple domains, the | utilized by subsequent MHSs. By encompassing multiple domains, the | |||
SPF script may not establish an accountable domain-name subsequent to | SPF record may not establish an accountable domain-name subsequent to | |||
evaluation when inconclusive results are obtained. Owing to these | evaluation when inconclusive results are obtained. Owing to these | |||
conditions, there is no reasonable strategy that can be used to | conditions, there is no reasonable strategy that can be used to | |||
mitigate the potential harm created by a distributed SPF script | mitigate the potential harm created by a distributed SPF generated DoS | |||
generated DoS attack. To estimate the potential for the SPF script | attack. To estimate the potential for the SPF generated threat, the | |||
generated threat, the level of network amplification is considered | level of network amplification is considered. | |||
for this SPF DNS scripting scheme. | ||||
A typical stance taken when discussing DoS concerns is that there are | A typical stance taken when discussing DoS concerns is that there are | |||
other network amplification techniques to facilitate DoS exploits. | other network amplification techniques to facilitate DoS exploits. | |||
One such exploit utilizes DNS servers. This exploit depends upon a | One such exploit utilizes DNS servers. This exploit depends upon a | |||
lookup to be amplified by the difference between the query size and | lookup to be amplified by the difference between the query size and | |||
that of the answer, in addition to the number of queries made in a | that of the answer, in addition to the number of queries made in a | |||
recursion process. To roughly estimate the network impact created by | recursion process. To roughly estimate the network impact created by | |||
DNS UDP traffic, 1.3 queries will be assumed to occur on average from | DNS UDP traffic, 1.3 queries will be assumed to occur on average from | |||
every DNS lookup, with an average query size of 100 bytes and an | every DNS lookup, with an average query size of 100 bytes and an | |||
average answer of 500 bytes. Based upon these coarse assumptions, | average answer of 500 bytes. Based upon these coarse assumptions, the | |||
the resulting DNS amplification is about 13 to 1 when the source IP | resulting DNS amplification is about 13 to 1 when the source IP | |||
address of the lookup is also spoofed to be that of the targeted | address of the lookup is also spoofed to be that of the targeted | |||
domain. Some techniques have increased the level of this exploit by | domain. Some techniques have increased the impact of this exploit by | |||
employing the [RFC2671] EDNS0 extension to query large RRsets that | employing the [RFC2671] EDNS0 extension to query large RRsets that | |||
exceed the network MTU, and cause packet fragmentation. This | exceed the network MTU, and cause packet fragmentation. This | |||
technique can achieve an impact with about a 60 times amplification, | technique can achieve an impact with about a 60 times amplification, | |||
however the source of the large RRset can be identified. | however the source of the large RRset can be identified. | |||
About 1 K bytes of outbound TCP traffic may be needed to send a small | About 1 K bytes of outbound TCP traffic may be needed to send a small | |||
SMTP message. SPF scripts can target 100 DNS transactions when | SMTP message. SPF records can invoke 100 DNS lookups when evaluating | |||
evaluating a single domain-name. In estimating the targeted | a single domain-name. In estimating the targeted amplification, the | |||
amplification, the number of common DNS transactions is multiplied by | number of common DNS lookups is multiplied by the number of recipients | |||
the number of recipients in different domains, the different domain- | in different domains, the different domain- names evaluated within the | |||
names evaluated within the same message, and each sequential MHS that | same message, and each sequential MHS that does not share a common DNS | |||
does not share a common DNS cache. A message sent to only 1 | cache. A message sent to only 1 recipient who also utilize SPF | |||
recipient who also utilize SPF evaluation in their MUA could then | evaluation in their MUA could then create about 312 to 1 network | |||
create about 312 to 1 network amplification directed toward a | amplification directed toward a targeted domain. As a comparison, | |||
targeted domain. As a comparison, evaluating domain-names using SPF | evaluating domain-names using SPF represents about 24 times the threat | |||
represents about 24 times the threat caused by an exploit using | caused by an exploit using recursive DNS, and about 5 times the threat | |||
recursive DNS, and about 5 times the threat caused by the use of | caused by the use of EDNS0. Unlike the EDNS0 technique however, the | |||
EDNS0. Unlike the EDNS0 technique however, the source of the problem | source of the problem remains hidden. | |||
remains hidden. | ||||
The network amplification exploit using SPF may also leverage a | The network amplification exploit using SPF may also leverage a | |||
provider's SMTP servers that are available from systems an attacker | provider's SMTP servers that are available from systems an attacker | |||
may have compromised. It is common for tens of thousands of | may have compromised. It is common for tens of thousands of | |||
compromised systems to act in concert to disseminate spam, while each | compromised systems to act in concert to disseminate spam, while each | |||
system may conform to normal use profiles. These spam messages could | system may conform to normal use profiles. These spam messages could | |||
have a small list of recipients that further amplify the level of the | have a small list of recipients that further amplify the level of the | |||
attack. Perhaps these messages contain an average of 10 recipients. | attack. Perhaps these messages contain an average of 10 recipients. | |||
These messages may purport to be from email-addresses with random | These messages may purport to be from email-addresses with random | |||
local names and sub-domains, beneath a list of top level domains. | local names and sub-domains, beneath a list of top level domains. All | |||
All of these different domains can nevertheless reference similarly | of these different domains can nevertheless reference similarly | |||
targeted SPF records. The messages in the attack could be a stock | targeted SPF records. The messages in the attack could be a stock tip | |||
tip ending up in a spam folder. No single message may convey the | ending up in a spam folder. No single message may convey the same | |||
same information, and yet still target the same victim regardless who | information, and yet still target the same victim regardless who | |||
appears to be the author, or which folder is ultimately selected to | appears to be the author, or which folder is ultimately selected to | |||
receive the message. | receive the message. | |||
(1.3 x (100+500))/1000 = .78 DNS/SMTP Gain Factor | (1.3 x (100+500))/1000 = .78 DNS/SMTP Gain Factor | |||
SPF Script Network Amplification at victim domain: | SPF Network Amplification at victim domain: | |||
RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain | RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain | |||
100 x 2 x 2 x 1 x .78 = 312 | 100 x 2 x 2 x 1 x .78 = 312 | |||
100 x 2 x 1 x 10 x .78 = 1560 | 100 x 2 x 1 x 10 x .78 = 1560 | |||
SMTP Name Path Network Amplification at victim domain: | SMTP Name Path Network Amplification at victim domain: | |||
RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain | RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain | |||
1 x 2 x 2 x 1 x .78 = 3 | 1 x 2 x 2 x 1 x .78 = 3 | |||
The SPF script facilitates canvassing by a covert DNS server for | SPF facilitates canvassing by a covert DNS server for domains that | |||
domains that utilize SPF evaluations and also facilitates a sustained | utilize SPF evaluations and also facilitates a sustained DoS attack | |||
DoS attack based upon this knowledge. Without altering the SPF | based upon this knowledge. Without altering the SPF record, | |||
script, local-part label macros provided by SPF can instantiate | local-part label macros provided by SPF can instantiate different | |||
different queries for a series of messages from the same set of | queries for a series of messages from the same set of domains. Using | |||
domains. Using this technique, in addition to ensuring the DNS | this technique, in addition to ensuring the DNS information has not | |||
information has not been locally cached to inundate the targeted | been locally cached to inundate the targeted domain with DNS queries, | |||
domain with DNS transactions, this will also flood the local DNS | this will also flood the local DNS cache which may expel previously | |||
cache which may expel previously obtained information prior to its | obtained information prior to its normal expiration. | |||
normal expiration. | ||||
Just using the SPF script to evaluate a domain-name risks the | ||||
integrity of DNS itself. A poisoning exploit often attempts to both | ||||
flood the DNS answering for the RR being poisoned, and to gain access | ||||
to the DNS whose cache is to be poisoned. Both of these efforts are | ||||
facilitated by SPF script. The SPF script also provides the ability | ||||
to query a covert DNS server that tracks the source IP address, | ||||
ports, and Transaction IDs of DNS transactions to improve upon | ||||
subsequent construction and the timing of poison answers. | ||||
The name-based path registration approach provides a 100 to 1 | ||||
reduction in the amount of network amplification with a maximum of | ||||
only one conditional DNS transaction of a common resource. This | ||||
name-based approach also always provides an accountable domain-name | ||||
for effective DoS protections; see [I-D.otis-smtp-name-path]. The | ||||
name-based path registration alternative to SPF starts by verifying | ||||
the EHLO; see [I-D.crocker-csv-csa]. This allows a name-based | ||||
defense to be established that fairly holds the domain controlling | ||||
each sending system accountable for any abuse. This approach also | ||||
ensures that prior to acceptance, there is no amplification of DNS | ||||
transactions made with a victim domain, as each subsequent MTA | ||||
forwarding a message offers their own EHLO that exists within their | ||||
own domain or EHLO verification fails. A failure to verify the EHLO | ||||
allows the recipient to delay subsequent acceptance of messages from | ||||
both the EHLO and the associated client IP address as an effective | ||||
DoS defensive tactic. Once EHLO verification is established as a | ||||
requisite, message refusals could then be handled in a permanent | ||||
fashion. | ||||
The safe name-based alternative to the SPF script method requires | Just using SPF to evaluate a domain-name risks the integrity of DNS | |||
just one or two steps. The first steps ensures the EHLO of the MTA | itself. A poisoning exploit often attempts to both flood the DNS | |||
is directly verified with a single DNS transaction. Once the EHLO is | answering for the RR being poisoned, and to gain access to the DNS | |||
verified, and when the EHLO is within the domain-name in question, no | whose cache is to be poisoned. Both of these efforts are facilitated | |||
second step is needed. Otherwise, the second step attempts to | by SPF. SPF also provides the ability to query a covert DNS server | |||
establish a domain association by making a single forward reference | that tracks the source IP address, ports, and Transaction IDs of DNS | |||
PTR RRset lookup from the domain in question. These PTR RRsets would | queries to improve upon subsequent construction and the timing of | |||
simply list the provider's root domains used by the owner of the | poison answers. | |||
email-address domain. A failure to verify the EHLO or to find an | ||||
association with the message domain-names can delay acceptance of the | ||||
message. EHLO verification is comparatively easier to administer | ||||
than SPF scripts. | ||||
4. The Exploit Example | 4. The Exploit Example | |||
This section and the accompanying appendix information is in response | This section and the accompanying appendix information is in response | |||
to requests made by a few large providers. Explaining the threat in | to requests made by a few large providers. Explaining the threat in | |||
general terms proved difficult for many to understand. This example | general terms proved difficult for many to understand. This example | |||
represents one of many possible techniques that are enabled by the | represents one of many possible techniques that are enabled by the | |||
various SPF script parsing applications. Other techniques can | various SPF implementations. Other techniques can further increase | |||
further increase the severity of such an attack, but are not | the severity of such an attack, but are not reviewed. The | |||
reviewed. As with any script, the permutations of possible actions | permutations of possible actions are incredibly vast. | |||
are incredibly vast. | ||||
This Exploit Example makes use of script parser capabilities in many | This Exploit Example works with many SPF libraries, although libspf2 | |||
SPF libraries, although libspf2 by Wayne Schlitt et al, by default, | by Wayne Schlitt et al, by default, is at half the recommended number | |||
is at half the recommended number of RRs to be processed within an MX | of RRs to be processed within an MX RRset. It is not uncommon for an | |||
RRset. It is not uncommon for an RRset to exceed this lowered limit. | RRset to exceed this lowered limit. For example, more than this | |||
For example, more than this number of MX RRs are found within | number of MX RRs are found within t-online.de or nokia.com. These | |||
t-online.de or nokia.com. These domains also do not publish SPF TXT | domains also do not publish SPF TXT records, which means even when a | |||
records, which means even when a default SPF script containing the MX | default ("best guess") SPF record containing the MX lookup mechanism | |||
lookup mechanism is used instead, the lowered RRset cut-off randomly | is used instead, the lowered RRset cut-off randomly prevents some MX | |||
prevents some MX RRs from being examined. | RRs from being examined. | |||
Although several libraries impose the recommended limit, the original | Although several libraries impose the recommended limit, the original | |||
SPF script's limiting mechanism was recursion depth, that contained | SPF specification draft's limiting mechanism was recursion depth, that | |||
the DNS transactions by the number of mechanisms that could be | contained the DNS transactions by the number of mechanisms that could | |||
defined within 20 and changed to 10 additional SPF scripts. This | be defined within 20 and changed to 10 additional SPF records. This | |||
recursive method allows for exceedingly high numbers of DNS | recursive method allows for exceedingly high numbers of DNS | |||
transactions. There are several other recent libraries where no | transactions. There are several other recent libraries where no | |||
limits are imposed upon the number of MX RRsets, other than the | limits are imposed upon the number of MX RRsets, other than the number | |||
number returned within the MX lookup. SPF requires the acquisition | returned within the MX lookup. SPF requires the acquisition of the | |||
of the TXT SPF record, which may then direct queries to 10 or 11 | TXT SPF record, which may then direct queries to 10 or 11 other | |||
other domains. Most would consider that approach as mandating 10 | domains. Most would consider that approach as mandating 10 times the | |||
times the number of DNS transactions, but SPF also adds highly risky | number of DNS transactions, but SPF also adds highly risky indirection | |||
indirection enabled through SPF script and macro expansion. | enabled through macro expansion. | |||
Taking advantage of just one level of indirection made possible by | Taking advantage of just one level of indirection made possible by SPF | |||
SPF macros, the Exploit Example closely matches the initial estimates | macros, the Exploit Example closely matches the initial estimates made | |||
made in Section 3, but where the request increases, the response is | in Section 3, but where the request increases, the response is reduced | |||
reduced by about the same amount. The Example Exploit therefore | by about the same amount. The Example Exploit therefore represents a | |||
represents a fairly symmetrical attack, and requires little knowledge | fairly symmetrical attack, and requires little knowledge of the | |||
of the victim's DNS information. The traffic required to establish | victim's DNS layout. The traffic required to establish both the TXT | |||
both the TXT and MX resource record sets should be excluded from the | and MX resource record sets should be excluded from the gain | |||
gain estimates, as the attack is able to take advantage of a | estimates, as the attack is able to take advantage of a difference | |||
difference between negative cache retention, and the TTL of these | between negative cache retention, and the TTL of these RRsets. | |||
RRsets. | ||||
Often negative caching is for a few minutes, but the RRset could be | Often negative caching is for a few minutes, but the RRset could be | |||
retained many hours. After the requesting DNS servers have been | retained many hours. After the requesting DNS servers have been | |||
seeded, the level of the attack could maintain a steady barrage while | seeded, the level of the attack could maintain a steady barrage while | |||
requiring far less effort. The Time-To-Live for negative DNS caching | requiring far less effort. The Time-To-Live for negative DNS caching | |||
may be determined by the recipient, or represent the lesser of the | may be determined by the recipient, or represent the lesser of the | |||
SOA TTL or the SOA MINIMUM field, depending upon the recipient's | SOA TTL or the SOA MINIMUM field, depending upon the recipient's | |||
implementation, see [RFC2308]. | implementation, see [RFC2308]. | |||
The attacker would initially populate TXT and MX RRsets that point | The attacker would initially populate TXT and MX RRsets that point | |||
toward the victim's domain. Referencing different MX RRsets does not | toward the victim's domain. Referencing different MX RRsets does not | |||
require an additional SPF TXT script. Instead, the macro expansion | require an additional SPF TXT record. Instead, the macro expansion | |||
capability can be used to reference a vast array of MX records, as | capability can be used to reference a vast array of MX records, as | |||
illustrated by the Example Exploit which uses the local-part as a | illustrated by the Example Exploit which uses the local-part as a | |||
selector. Optimally, this reference would cycle at a period longer | selector. Optimally, this reference would cycle at a period longer | |||
than the resolver's negative cache retention period. A reference to | than the resolver's negative cache retention period. A reference to | |||
a covert DNS server that replicates the SOA record parameters of the | a covert DNS server that replicates the SOA record parameters of the | |||
victim could signal the optimal cycle period. | victim could signal the optimal cycle period. | |||
The level of attack described in the presentation made for The DNS | The level of attack described in the presentation made for The DNS | |||
Operations, Analysis, and Research Center (DNS-OARC) called "Recent | Operations, Analysis, and Research Center (DNS-OARC) called "Recent | |||
DNS Reflector Attacks From the Victim and the Reflector POV" by Frank | DNS Reflector Attacks From the Victim and the Reflector POV" by Frank | |||
Scalzo of Verisign, see [r-VS-Reflect] indicated the 35,000 | Scalzo of Verisign, see [r-VS-Reflect] indicated the 35,000 | |||
amplifying reflectors caused on average 144kbps (18KBps) to be | amplifying reflectors caused on average 144kbps (18KBps) to be | |||
exchanged with the victim. A similar level of attack could be | exchanged with the victim. A similar level of attack could be | |||
achieved by the Example Exploit occurring 0.28 times a second or 17 | achieved by the Example Exploit occurring 0.28 times a second or 17 | |||
times per minute. When 2 domains are being examined, as may occur | times per minute. When 2 identities are being examined, as may occur | |||
with Sender-ID, this level of attack would require just 8.5 messages | with Sender-ID, this level of attack would require just 8.5 messages | |||
per minute. | per minute. | |||
Processing 8.5 messages per minute would represent a very small | Processing 8.5 messages per minute would represent a very small | |||
percentage of the emails already being handled by many providers. | percentage of the emails already being handled by many providers. | |||
Already a majority of these emails are considered abusive. A large | Already a majority of these emails are considered abusive. A large | |||
provider may issue as many as 25,000 messages per minute and receive | provider may issue as many as 25,000 messages per minute and receive | |||
emails at twice that rate. A strategy that sends messages through | emails at twice that rate. A strategy that sends messages through | |||
network providers addressed to 10 individuals on average from 35,000 | network providers addressed to 10 individuals on average from 35,000 | |||
compromised systems at 50 per hour represents a scale of concerted | compromised systems at 50 per hour represents a scale of concerted | |||
attack commonly seen. If these messages also get processed by spam | attack commonly seen. If these messages also get processed by spam | |||
filtering applications that also uses SPF/Sender-ID, the attack rate | filtering applications that also uses SPF/Sender-ID, the attack rate | |||
could then drop to 25 per hour and still sustain the same barrage. | could then drop to 25 per hour and still sustain the same barrage. | |||
This type of activity could be considered a good way to leverage | This type of activity could be considered a good way to leverage | |||
skipping to change at page 10, line 18 | skipping to change at line 306 | |||
network providers addressed to 10 individuals on average from 35,000 | network providers addressed to 10 individuals on average from 35,000 | |||
compromised systems at 50 per hour represents a scale of concerted | compromised systems at 50 per hour represents a scale of concerted | |||
attack commonly seen. If these messages also get processed by spam | attack commonly seen. If these messages also get processed by spam | |||
filtering applications that also uses SPF/Sender-ID, the attack rate | filtering applications that also uses SPF/Sender-ID, the attack rate | |||
could then drop to 25 per hour and still sustain the same barrage. | could then drop to 25 per hour and still sustain the same barrage. | |||
This type of activity could be considered a good way to leverage | This type of activity could be considered a good way to leverage | |||
efforts. While sending spam, perhaps containing malware, | efforts. While sending spam, perhaps containing malware, | |||
authoritative DNS servers are taken out by knowing which domains | authoritative DNS servers are taken out by knowing which domains | |||
incorporate poorly considered, and ultimately fatally flawed, SPF | incorporate poorly considered, and ultimately fatally flawed, SPF | |||
parsers. Once the authoritative DNS servers are disabled, the same | implementations. Once the authoritative DNS servers are disabled, the | |||
SPF script can illicit queries through thousands of provider's DNS | same SPF record can illicit queries through thousands of provider's | |||
servers, and also trigger a barrage of poison answers. These attacks | DNS servers, and also trigger a barrage of poison answers. These | |||
can be done through two levels of indirection where it would be | attacks can be done through two levels of indirection where it would | |||
difficult to correlate what domain is inducing the problem, or how it | be difficult to correlate what domain is inducing the problem, or how | |||
can be stopped. The SPF RRsets causing trouble will not appear on a | it can be stopped. The SPF RRsets causing trouble will not appear on | |||
log. In the Example Exploit, the message is accepted with a neutral | a log. In the Example Exploit, the message is accepted with a neutral | |||
status without any evidence it was related to the victim's domain. | status without any evidence it was related to the victim's domain. | |||
SPF/Sender-ID reduces security. Although there was already "A DNS RR | SPF/Sender-ID reduces security. Although there was already "A DNS RR | |||
Type for Lists of Address Prefixes (APL RR)" [RFC3123] that could | Type for Lists of Address Prefixes (APL RR)" [RFC3123] that could | |||
serve extremely well for white-listing, SPF was developed as a method | serve extremely well for white-listing, SPF was developed as a method | |||
that avoids declaring who are the sending system's administrators and | that avoids declaring who are the sending system's administrators and | |||
offers the feature-rich/security-poor scripting found with HTTP/TCP. | offers the feature-rich/security-poor scripting found with HTTP/TCP. | |||
Sender-ID was even originally specified using XML contained within | With the highly distributive anonymous nature of email, reducing | |||
2KB DNS resource records, expecting DNS/TCP would not become a | security while crime is rampant, is foolhardy at best. SPF/ Sender-ID | |||
problem. With the highly distributive anonymous nature of email, | continues to place the DNS infrastructure at risk. | |||
reducing security while crime is rampant, is foolhardy at best. SPF/ | ||||
Sender-ID continues to place the DNS infrastructure at risk. Adopt | ||||
EHLO verification, Name-Path registration, and the use of APL RRs. | ||||
Drop the use of SPF. Such a change would offer additional security, | ||||
without actually reducing it instead. Don't be afraid to use binary | ||||
with DNS. | ||||
5. IANA Considerations | 5. IANA Considerations | |||
There are no registrations required by IANA. | There are no registrations required by IANA. | |||
6. Security Considerations | 6. Security Considerations | |||
This document describes a threat to SMTP created by the evaluation of | This document describes a threat to SMTP created by the evaluation of | |||
message related domain-names using SPF scripts. This document | message related domain-names using SPF records. | |||
recommends a safer alternative that first verifies the EHLO of the | ||||
MTA and then conditionally finds associations using a domain-name | ||||
list. It is expected that the verified EHLO name will be checked | ||||
against block-lists of abusers. When either the EHLO can not be | ||||
verified, or an association with a message domain-name can not be | ||||
established, delayed message acceptance provides another defensive | ||||
strategy which allows time for abuse to be reported. Delay in | ||||
acceptance can be accomplished with a Transient Negative Completion, | ||||
in conjunction with "Requested action aborted: error in processing" | ||||
SMTP response; see [RFC2821]. | ||||
7. Informative References | 7. Informative References | |||
[I-D.crocker-csv-csa] | ||||
Crocker, D., "Client SMTP Authorization (CSA)", | ||||
draft-crocker-csv-csa-00 (work in progress), October 2005. | ||||
[I-D.crocker-email-arch] | [I-D.crocker-email-arch] | |||
Crocker, D., "Internet Mail Architecture", | Crocker, D., "Internet Mail Architecture", | |||
draft-crocker-email-arch-04 (work in progress), | draft-crocker-email-arch-04 (work in progress), | |||
March 2005. | March 2005. | |||
[I-D.ietf-dkim-base] | ||||
Allman, E., "DomainKeys Identified Mail Signatures | ||||
(DKIM)", draft-ietf-dkim-base-02 (work in progress), | ||||
May 2006. | ||||
[I-D.otis-smtp-name-path] | ||||
Otis, D., "SMTP Name Path Registration", | ||||
draft-otis-smtp-name-path-00 (work in progress), | ||||
April 2006. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS | [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS | |||
NCACHE)", RFC 2308, March 1998. | NCACHE)", RFC 2308, March 1998. | |||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", | [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", | |||
RFC 2671, August 1999. | RFC 2671, August 1999. | |||
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | |||
April 2001. | April 2001. | |||
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | ||||
April 2001. | ||||
[RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes | [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes | |||
(APL RR)", RFC 3123, June 2001. | (APL RR)", RFC 3123, June 2001. | |||
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", | [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", | |||
RFC 4406, April 2006. | RFC 4406, April 2006. | |||
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail | [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail | |||
Messages", RFC 4407, April 2006. | Messages", RFC 4407, April 2006. | |||
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) | [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) | |||
skipping to change at line 2890 | skipping to change at line 2775 | |||
Copyright Statement | Copyright Statement | |||
Copyright (C) The Internet Society (2006). This document is subject | Copyright (C) The Internet Society (2006). This document is subject | |||
to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
vim:tw=73 sw=3 sts=3 | ||||
End of changes. 31 change blocks. | ||||
231 lines changed or deleted | 130 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |