ietf
[Top] [All Lists]

Re: TMDA backscatter

2007-10-11 12:33:30

On Oct 11, 2007, at 2:23 AM, Frank Ellermann wrote:

Douglas Otis wrote:

Macro expansion and text strings can be combined with any SPF record mechanism and CIDR mask. Any email-address differing in just the local-part must then be iteratively processed across the SPF record set (up to 10 follow-on SPF records or mechanisms).

Yes, an attacker can use 10 mx mechanisms in his malicious policy for domains under his control with names containing 10 different parts of the LHS (local part) in his envelope sender address.

Each of 10 MX records may necessitate resolving 10 target addresses for a total of 100 targeted DNS transactions per SPF name evaluation. By using the local-part in a spam campaign, one cached SPF record is able to reference an unlimited sequence of MX records. Targets within MX records can also utilize a small variable label together with large static labels to leverage DNS name compression. Without MX records being cached with dependence upon negative cache expiring, the network amplification of an SPF related attack using MX targeting would be about 10. After a recipient's negative caching expires, repeating a sequence of local-parts in a spam campaign could thereafter use cached MX records. Negative caching is not always under the control of the victim. Once a set of MX records becomes cached and their target's negative response expire, the entire attack becomes entirely _free_ for spammers. Spammers often send messages continuously. A spam campaign can come from any source, purport to be from any domain, and yet attack the same innocent victim which can not be identified by examining the message. : (

The SPF record is able to conclude with "+all" and still obtain a PASS

Sure, a PASS for "mail from" unknown strangers only guarantees that bounces and other auto-replies won't hit innocent bystanders. A PASS can be still spam or an attack, but it won't create backscatter, that is more or less the idea of SPF.

Compared to an SPF related attack, most auto-replies will consume a greater amount of an attackers resources, identify the source of the attack, and not achieve the same level of amplification. In the case of SPF, the attack can become entirely free and completely hidden while spamming! Rate limiting auto-replies would be a much safer solution for the recipient to perform.

A single message can be sent to 100 different recipients. 100 x 100 = 10,000 DNS transactions!

The number of RCPT TO for a given MAIL FROM at the border MTA where SPF is checked is irrelevant, it's evaluated once. Actually the same MAIL FROM at a given border MTA has no further effect while the SPF and MX records of the attacker are still cached. But of course an attacker can send more mails to more domains with different envelope sender addresses, and he can tune the TTL of his SPF and MX records.

Each recipient can be within a different domain where a MAIL FROM and the PRA may be both evaluated. By expanding upon the local-part of the email-address, caching SPF records actually aids the attack. The only tuning required would be that of the local-part sequence. Duration of the sequence only needs to be a bit longer than the negative caching of the recipient.

Whatever he does, your attack scenario depends on the mx mechanism, and you get an amplification factor of about 10 DNS queries to the victim per DNS query to the attacker.

Do you really think a spammer is unable to attack at a gain of 10, and then continue the attack at no cost once the duration of the attack exceeds the negative caching (determined by the recipients). SPF enables a long duration DDoS attack. Good luck at attempting to prevent this type of attack or at identifying the source. Block all SPF records?

The attacker could also try to abuse "call back verification" with his bogus MX records for a better amplification factor without SPF.

The SPF can also attack those using wildcard MX, TXT or A records. This attack would be instantly free and much simpler as it would not require waiting for negative caching to expire. : (

AFAIK SPF is so far the only protocol specifying "processing limits" for DNS based attacks. RFC 2821 certainly doesn't talk about it, and I'm not aware of any processing limits wrt SRV or NS records.

SPF introduces a long list of macros locating a sequence of records, that then often involve additional DNS transactions. Even the time limit applied by SPF disables DNS congestion avoidance!

Maybe you should propose some "MX processing limits" for 2821bis.

Most systems are fairly careful about where they send messages to avoid being blocked, nor would the normal use of MX records require all targets be resolved. Timeouts recommended by RFC2821 ensure this operation remains fairly safe, unlike that for SPF. Even the packet limitation of DNS provides a fairly reasonable limit.

DKIM could be extended to avoid backscatter and replay abuse.

Hardly. DKIM is intentionally independent of SMTP, it doesn't look at the envelope sender address. The envelope sender address (aka return path, mail from, or bounce address) and the MX concept are the essence of SMTP, anything else is syntactical sugar.

A policy record at the MAIL FROM domain could reference an authorized DKIM signature within a single DNS transaction. The same type of policy record could be applied against the SMTP client to curtail replay abuse. The MAIL FROM policy could thereby ensure a DSN is issued when there is a problem, and the SMTP client could avoid possible grey-listing should the recipient find replay abuse to be problematic.

The PRA is the best approximation of the envelope sender address, but DKIM also doesn't look at the PRA, it's not designed to fight backscatter.

DKIM can be processed prior to acceptance, and could safely help prevent backscatter with a few minor by-name extensions.

Unfortunately, Sender-ID is being heavily promoted as the anti- phishing solution. A problem not addressed by RFC4408.

RFC 4408 doesn't discuss PRA or phishing or 2822, it's about SMTP and backscatter. For discussions why the best approximation PRA isn't good enough see the <http://www.openspf.org> pages.

Agreed, but that does not mean that two names PRA and MAIL FROM will not be checked.

Using PRA as anti-phishing solution might make sense, with several caveats addressed in the IESG note. Unlike PRA pure DKIM offers no FAIL, it can help to identify various kinds of "non-phishing". That's not the same as "anti-phishing".

From my point of view, anti-phishing requires examination of message content more than just email headers. When the message appears to be misleading, and is not signed as expected, it should be marked as suspicious or rejected.

Had the recipient known who sent the message, SPF would not be needed.

Indeed, SPF is used to figure out when "originator as indicated in the reverse path" in RFC 2821 is acceptable (PASS) or should be rejected (FAIL) at a border MTA. Other uses of SPF are at best nice to have, and in the worst case dangerous.

When desired, path registration should be by-name and not by-address to avoid the unscalability, complexity, and risk. Something as simple as CSV and a MAIL FROM policy record is far more scalable, easier to manage, and much safer.

Oops, bell.ca still has this ridiculous policy, that certainly won't help them to reduce backscatter.

Obviously that is not why the SPF record is published.

If all they want is a PASS they could use a short "v=spf1 +all" without the other PASSing gibberish they're publishing now.

I suspect they felt pressured by ISPs like AOL who use SPF records to white-list other large providers. This indicates being part of the club.

At least the "+all" discourages use of dangerous SPF libraries

No, "v=spf1 +all" and more verbose policies with the same effect are perfectly valid and supported by SPF libraries, dangerous or otherwise.

It also removes any possible advantage for running these libraries and avoids problems where the path of the message and the path expressed by SPF legitimately differ.

the example attack scenario is not prevented by any RFC4408 SHOULD or MUSTs

 <http://tools.ietf.org/html/rfc4408#section-10.1>
| SPF implementations SHOULD limit the total amount of data obtained
| from the DNS queries.  For example, when DNS over TCP or EDNS0 are
| available, there may need to be an explicit limit to how much data
| will be accepted to prevent excessive bandwidth usage or memory usage
| and DoS attacks.

The example attack scenario never exceeded typical DNS transaction sizes. It did not use TCP or EDNS0. It did not exceed the SHOULD limits on the number of mechanisms or subsequent address resolutions. SPF, as current defined, remains very dangerous. The use of libraries implementing SPF per this specification are dangerous as they permit a totally free attack, where the source is hidden, and there is not a means to defend against it.

-Doug

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>