Imagine your incoming e-mail volume suddenly leaping 360 times above normal. Its not spam, not strictly speaking. Its a misdirected bounce attack.
Bounces used to be a good and useful thing. When you send an e-mail to an invalid address or make some other sort of error, you want to know that it didnt go well. But along the way, bounces got abused just like everything wholesome about e-mail to the point where you had to avoid them as a matter of course.
First, bounces became accomplices to spamming through directory harvest attacks. In this attack, a spammer picks a domain and sends out a large number of messages, guessing at the user name portion of the e-mail address and probably pulling a lot of them out of a directory of names (e.g., [email protected], [email protected], etc.). If the spammer gets a bounce on a message, then its not an address in that domain. The messages that dont bounce are real addresses, and then you spam them. Because of this threat, many domains dont send back bounces for wrong addresses anymore.
Another threat these days is what is sometimes called spam blowback. As most of you know, when an e-mail is sent on the Internet from [email protected] to [email protected], there is no mechanism with which the folks at bar.com can confirm that the message was in fact sent by [email protected], or from anyone at foo.com.
So imagine that the message is false and not sent by anyone at foo.com and that there is no user “recipient” at bar.com. If bar.com still sends bounce messages, it will send them to foo.com. [email protected] (if there is such a user), receiving the bounce message, will say to himself, “Huh? I didnt send this.”
Now imagine that a major phishing attack goes out with millions of e-mails sent from [email protected] Some percentage of these messages, amounting to a very large absolute number, will be wrong, and the bounces will “blow back” to the mail server at Faceless National.
This has the potential to massively clog the banks infrastructure. According to IronPort, one bounce attack against US Life Insurance increased its inbound mail volume from the typical 10,000 messages to 3,653,201. A jump like that will cause anyone problems. And often the bounce messages themselves will contain malware.
Next page: The answer to blowback.
The Answer to Blowback
Of course, all the general efforts at SMTP authentication, like DKIM (DomainKeys Identified Mail), would solve this problem along the way to solving even more serious ones, but theyre too revolutionary. We might all agree theyre good things and worth supporting, but they only achieve usefulness when they have been widely adopted.
Thats why BATV (Bounce Address Tag Validation) was invented. BATV allows the targets of blowback attacks to protect themselves with minimal effort and without anyone elses cooperation. Its effective as a unilateral measure. IronPort Systems is announcing this week that BATV will be included for no charge in the regular software updates to its own devices.
Heres how BATV works: The MAIL-FROM address in the messages envelope, which is the opening portion of the SMTP transaction, is digitally signed with a private key known only to the mail server. The normal format for the envelope is:
With BATV, this becomes (for example, in IronPorts implementation):
The “EA6D0F” part is the hex representation of the first three bytes of the SHA-1 HMAC—in other words, a hash—of the other parts of the address and a private key. The “415” is a portion of a time stamp.
The IronPort implementation differs slightly from the current BATV specification. The spec is continually evolving, and if administrators are careful it shouldnt matter if more than one version has to be supported at once.
If a bounce comes in to the system to the same address, the server can look up and confirm that the tag is valid and then deliver the bounce message. If it just comes in to [email protected], or to some BATV value that doesnt correspond to a valid one, the server can ditch it at the SMTP envelope conversation. This aborts the transaction at an early stage, before the large majority of the message transfer has been performed. So it doesnt really stop the attack, but it mitigates it to the degree that it is much more manageable.
Its not hard to imagine some problems caused by all the messing with addresses. For instance, I heard one report that the variability in the address from date stamp changes can cause challenge/response systems to complain, but thats hardly the first problem with challenge/response. Also its also somewhat disappointing that the perpetrator of the attack doesnt learn from the process that the attack failed.
BATV can piggyback on top of SMTP authentication efforts. One day in the hypothetical future when DMIM or some such standard is ubiquitous, BATV can be turned off. But, in the meantime, its an unusually low-impact way to eliminate some real threats.
Many thanks to John Levine for help with this and other articles Ive written. John is principal author of “The Internet for Dummies” and co-author, with the famous Dave Crocker and others, of the BATV specification.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.
More from Larry Seltzer