SPF Not Poisonous to Phish
by Brian McWilliams, author of Spam Kings
With email-forgery scams on the rise, why aren't banks rushing to support Sender Policy Framework?
The statistics on "phishing" are grim. Banks are losing over a billion dollars annually to such email scams, which trick victims into divulging account numbers and other sensitive information. Each month, Citibank alone is targeted by over 400 phishing attacks.
According to the Anti-Phishing Working Group, 92 percent of phishing attacks spoof the domain name of a famous company in the email "From" line. Five percent of recipients fall for the fraudulent messages, a much higher response rate than that generated by commercial spam.
So why aren't any major U.S. financial institutions embracing Sender Policy Framework (SPF), the technology widely heralded as a tool for fighting email-address forgery?
To date, none of the biggest banks has even published an SPF record--the simple line of text that, once added to a domain's DNS record, tells the world which Internet protocol addresses are associated with the domain's email servers. Citibank, Barclays, Chase, Bank of America, Wells Fargo, Royal Bank, Fleet--the list goes on--none has taken this basic step so that others can test the authenticity of emails bearing the banks' return address.
A cagey Citibank spokesman said the company is evaluating a number of proposed solutions for email address authentication, but has made no decision yet about adoption.
Perhaps big banks' chilly response to SPF is just characteristic technological caution. Or maybe they're waiting to see whether alternative email authentication systems, such as Microsoft's patented Sender ID or Yahoo's nascent DomainKeys technology, emerge as the industry standard.
Then again, maybe banks have concluded that SPF is worthless against phishing.
Even America Online, one of SPF's biggest proponents, admits that the technology won't protect its more gullible members from crooks.
"SPF does nothing for phishing," says Carl Hutzler, director of AOL's anti-spam operations.
That is an astonishing statement, coming from one of the first major dot-coms to publish an SPF record. (Other big names on the SPF bandwagon include Amazon, Apple, DoubleClick, EarthLink, Google, O'Reilly, Symantec, and Verizon.) In coming weeks, AOL will go a step further and begin screening inbound email for SPF records. (Later this year, EarthLink will also begin doing SPF checks on incoming messages to its members, company officials said.)
If you listen to the buzz on the net, SPF will put AOL and EarthLink in a position to block scams fraudulently claiming to be from Citibank.com, PayPal.com, or eBay.com. (That is, if those three firms ever publish SPF records.) As everyone knows, SPF ensures that the domain in the From line of an email isn't forged.
Wrong, says AOL's Hutzler. SPF only checks the hidden part of an email message known as the "Return-Path" (or "821 header"). According to Hutzler, SPF completely ignores the From address (or "822 header,") which is used by phishers to "social engineer" or dupe naïve recipients.
In other words, the wily phisher can forge the From line and still get past SPF checks--as long as his mail comes from an SPF-compliant domain listed in the Return-Path.
The chinks in SPF's armor are well known to the technology's developers. According to a list of frequently asked questions at the SPF site, "the technical issues associated with protecting the From header are much more numerous and challenging. The best way to protect the header From is by using a cryptographic signature such as S/MIME, PGP, or (when it is released) Yahoo DomainKeys."
In recent weeks, many in the email industry have pointed to spammers' early adoption of SPF as proof that the technology is no silver bullet against spam. Yet, almost as a consolation, some experts continue to characterize SPF as a defense against phishing attacks.
"SPF is an excellent tool for preventing phishing and fraud," said the CEO of email-filtering firm MX Logic in a recent press release. In an interview earlier this month, the CTO of another firm, CipherTrust, proclaimed that "SPF will be very good at identifying these phishing attacks."
In actuality, SPF's ability to protect the authenticity of the Return-Path header has a much more narrow benefit. The header is primarily used for "mailer-daemon bounces"--those error messages created by email servers when, for example, you try to send email to a nonexistent user account. As a result, SPF can help block the torrent of needless bounce messages created by email worms that put the addresses of innocent third parties in their Return-Path headers.
That's a worthy accomplishment. But it won't poison the sixty-plus phishing attacks launched every day.
The good news is that online scam artists are apparently just as confused about SPF as other email users. Most phishing spams still forge the same domain in the From and Return-Path headers.
A recent phish targeting customers of Citibank.com, for example, listed "emailmessage.Citibank.com" in the both the From and Return-Path headers. Had Citibank published an SPF record, the scam could have been flagged, since the IP address of the mail server in the headers (184.108.40.206 ) belonged to an apparently hacked PC connected to the Internet via Charter Communications.
But it's foolishly optimistic to assume phishers won't catch on. Even if use of Microsoft's Sender ID, which is based on SPF but also examines message From headers, became widespread, phishers would adapt, says John Levine, co-chair of the Internet Research Task Force's Anti-Spam Research Group. Levine predicts scammers will merely register throwaway, look-alike domains to use in their From lines, such as "amazon-accounts.com," and publish SPF records for the domains.
Phishing scam artists have certainly proven to be both creative and persistent. After falling victim to a clever phishing attack earlier this year, the Federal Deposit Insurance Corporation published an SPF record for its domain. In recent days, a new phishing scam emerged that similarly forged an FDIC.gov return address.
Meanwhile, most government agencies have not published SPF records. Among the high-profile domains without SPF records are WhiteHouse.gov, FBI.gov, and DHS.gov. Even the domains of many security-oriented organizations do not have SPF records, including CERT.org, SANS.org, and ISS.net. (The curious can check other domains for SPF records using the nslookup utility or web services such as DNSReport.com.)
Nevertheless, many organizations are moving ahead with SPF. According to one tally, more than 120,000 domains currently have published SPF records. Leading anti-spam products, including SpamAssassin and Declude, have implemented SPF support. Most major mail transfer agents (MTAs), among them Postfix, Sendmail, and Qmail, also support SPF through plugins or patches.
At AOL, inbound email to members that passes an SPF check "will be treated better" in the big ISP's spam scoring system, says Hutzler. The technology will also ease the maintenance of AOL's whitelist of bulk emailers who are permitted to send their opt-in messages to the big ISP's subscribers.
But many seem to be desperately clutching SPF like a life ring in a sea of fraudulent emails. Adelphia, the Colorado-based cable company, first published its SPF record six months ago as part of a brand-protection strategy. But the ISP, which has over one million Internet customers, hasn't decided whether to use SPF to filter incoming email to its members, according to Mark Herrick, director of data and network security.
"People just don't trust email anymore. That really needs to come back. We need to develop measures to give our customers a greater sense of trust in the Internet at large," says Herrick.
Brian McWilliams is the author of Spam Kings and is an investigative journalist who has covered business and technology for web magazines including Wired News and Salon, as well as the Washington Post and PC World, Computerworld, and Inc. magazines.
Return to the O'Reilly Network
Showing messages 1 through 1 of 1.
2004-09-29 08:06:21 elanthis [View]