Against Mail SpoofingPast, Current, and the Future
Broadband Security, Inc.
Kazunori ANDO
These slides are made for “An-Shin-Kan café” seminar at JIPDEC (Dec,16 2013)Original version is in Japanese and translated by author.
Internet Magazine July,2005…special feature article “Threats on the net and defence technology”
Internet Week 2003 Tutorial “Current status of Mail systems”
Internet Week 99 Tutorial “DNS&Mail”
I’ve traced and mentioned about “Spoofing” problem continuously!
“Anti-Spoofing = How to verify the sender”
Beginning of e-mail…
From:To:Cc:Subject:
Hi, JohnThese characters are lune for me.…
In ancient days, e-mails(text files) were delivered to receiving servers by FTP or UUCP.
Message Format
From:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here……
It must have information about recipients. Later the message format of e-mailis standardized in RFC822 (by Dave Crocker)
Sending Protocol
From:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here……
On the other hand, the sending protocol become original one, andstandardized in RFC821 (by Jon Postel)
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
Double existence of Sender/Rcpts info
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
From:To:Cc:Subject:Message-ID:
◯◯ 様平素よりお世話になっております…
From:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here……
Message body is delivered to the recipients as a text file, but sending/receiving logcan’t be checked by all the receivers.
Difference between two delivery informations…
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
From:To:Cc:Subject:Message-ID:
◯◯ 様平素よりお世話になっております…
From:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here……
Within the situation “Users describe the deliver information in the text,and MUA read and use them for actual delivery”, no difference occurs between these two.
maillist server
Difference occurs in usual usage
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
From:To:Cc:Subject:Message-ID:
◯◯ 様平素よりお世話になっております…
From:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here……
If the author of the message is different to the sender which deliver the message,these two deliver information may be different. (for example: mail lists).
In order to deliver the message to target recipients the recipients information in thesending protocol can’t be spoofed. However, the other information can be spoofed.
HELO ml.aams.jpMail From:[email protected] To:[email protected]
….
From the receiver side…
Return-Path:From:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here…
The reliable information to confirm the sender is only sender’s IP address.The other information can be spoofed except receivers’ address on the protocol.
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
No protection from spoofing!
“E-mail is past technology” ?
Return-Path: From:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here…
The sender’s IP address can be spoofed by route hijacking…
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
Spoofing on the origin of the routing information?
JANOG30 Meeting (July, 2012)
I also pointed out the needs of anti-spoofing on the routing in 2005, andRPKI go covering to verify the origin ofrouting information…
Internet Magazine July,2005…special feature article “Threats on the net and defence technology”
March,2013 DNSamp / Spamhaus
The problem of reflection attackusing IP src address spoofingis not fully covered yet…
BCP38 !uRPF !
Internet Magazine July,2005…special feature article “Threats on the net and defence technology”
How did e-mail engineers effort against spoofing ?
Sender Policy Framework(SPFbis)
Return-Path:Authentication-Results: … spf=passFrom:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here…
SPF check the consistency between the sender’s domain (or sender’s FQDNfollowing HELO command) and the IP address of sending server using SPF RRon DNS. The sender’s domain appears in Return-Path header in the message.
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
Verified by SPF
Sender Policy Framework(SPFbis)
Return-Path:Authentication-Results: … spf=passFrom:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here…
In Japan, over 90% of e-mail traffic can be checked by SPF (June,2013).Remaining problem: How to appeal the results of verifying to end users.
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
Verified by SPF
Return-Path:Authentication-Results: … dkim=passFrom:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here…
Sign by secret key on sending server, verifying the signature by public key via DNSon receiving server. The coverage of signing can be included headers and messagebody. However only “From:” header must be included in it.
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
STD76: DomainKeys Identified Mail ( DKIM )
Verified by DKIM
Protected optionally
STD76: DomainKeys Identified Mail ( DKIM )
Return-Path:Authentication-Results: … dkim=passFrom:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here…
About 40% of e-mail traffic can be verified by DKIM (June,2013 by MIC)Remaining problem: How to appeal the results of verifying to end users.
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
Verified by DKIM
Protected optionally
Using both DKIM and SPF
Return-Path:Authentication-Results: … spf=pass, dkim=pass, …From:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here…
Sender information (Return-Path/From) become very hard to spoof!
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
Sender info is verified
Protected optionally
DMARC
Return-Path:Authentication-Results: … spf=?, dkim=?, dmarc=pass, …From:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here…
Using the results of DKIM or SPF. If SPF is pass and DKIM is fail, DMARC checksthe consistency between “From:” and “Return-Path:” headers.Senders can declare the e-mail processing policy when DMARC results is “fail”.
HELO sender.example.jpMail From:[email protected] To:[email protected]
….
Checked by consistency
Remaining problems around Sender Authentication
Visualization of the resultsDomain reputation
JIPDEC is trying to visualize the DKIM result with domain reputation (white list).
S/MIME signingFrom:To:Cc:Subject:
Hi, BobWe can’t read them even if theywere displayed on here…
From:To:Cc:Subject:Content-Type: multipart/signed
-- separaterHi, BobWe can’t read them even if theywere displayed on here…
-- separater(signature encrypted by sender's secret key)-- separater --
Attach the signature encrypted by sender’s secret key…
S/MIME signing
From:To:Cc:Subject:Content-Type: multipart/signed
-- separaterHi, BobWe can’t read them even if theywere displayed on here…
-- separater(signature encrypted by sender's secret key)-- separater --
Decrypt the encrypted signature by the public key from CA/PKI, and verify whole message.End to End anti-alteration and anti-spoof.
Remaining problems around S/MIME
Secret key managementDeployment to web-mail environment
Oops! Only against sender spoofing?We also hate server spoofing and sniffing!
In current status of e-mail standardization,
We are ready to performserver authentication and path encryptionon all sending path
at least in RFCs.
Really?
MUA
Browser
Mbox
WebMailServer
MBOX type
WebMailGateway
with IMAP
MTAMDA MTA
RFC5321RFC5321RFC2023
RFC5321RFC2023
RFC3501
RFC3501RFC1939
Protocols using for Inbound with Path-Encryption
RFC3207RFC3207
RFC3207
RFC4616
RFC4616
MUA
Browser
WebMailServer
MBOX type
WebMailGateway
with IMAP
MTAMSA MTA
RFC5321
Protocols using for Outbound with Path-Encryption
Mbox
RFC6409
RFC6409
RFC5321
RFC5321RFC3501
RFC5321
RFC5321
RFC5321
RFC3207
RFC3207
RFC3207
RFC3207
RFC3207
RFC3207
RFC4616
Sure.The key person is Paul Hoffman.
RFCs using TLS around e-mail protocols are already in Proposed Standard.
However, we often encounter some people in a dilemma as below.
http://xkcd.com/927
These are past tale.
Current status is…
Yahoo! Japan’s personal databreach (May, 2013)
Adobe’s user data breach(Oct,2013)
“Weaken Password Authentication and Mail Services”(Oct, 2012 / Email Security Conference)
Attack using List of Compromised Accounts
• “Listed type of account cracking”• “Listed type of illegal access”• “Attack by listed passwords”
Attack using breached accounts/passwords in somewhere else.
Illegal access to system accountsIncrease breached accounts/passwords, Alteration of web-content,Distribution of malware, progress to APT…
Illegal access to mail accountsDelivering massive spam, Data breach from imap servers…
In other words, these are Spoofing by Account.
On message text, or on messaging protocol, It is harder to spoof.They change the target to User Authentication.
Impacts to usual anti-spoofing technologyby listed compromised accounts
• Illegal use of mail accounts– Both SPF and DKIM are also used illegal
• Sender Authentication is vulnerable against compromised accounts
– Bad reputation• Your server is sending spam!
• Illegal use of system accounts– Who protects your secret key?
• S/MIME is also vulnerable against compromised accounts
Side effects ofmassive spamsending is here.
What is the problem if your server is listed on SenderBase or RBL?
Damages on sending servers
• “Red-marked” sending servers– The other servers reject its sending…
• Connection refused or User unknown is returned by reference of RBL
– Many claims occurs from users “I can’t send e-mail”• man-hour to response to claims• man-hour to remove from RBLs
– Like whack-a-mole…• Exhausted operators
– “Too many to manage them!”(voice at BOF)– “We are rushed off our feet”(voice at mail-list)
Damages on mailbox servers
• Breach of stored e-mail ( especially from IMAP )– Secondary damages
• Breach of another service• Breach of stored passwords• Breach of massive e-mail address• E-mail is possible to be reused for targeted attack
Against down spiral…
• If you leave the compromised accounts…– Sending massive spam day by day– All your sending servers are marked “Red”– The account is also listed to blacklist on other services– Your service is almost terminated
• Mail service which users can’t send e-mail…– Your users will say “Thus, E-mail is finished!”
• So, administrators will– force to operate to off all the compromised accounts (△)
• A phase of crisis management
– search the technical solution (◎)• Because you are an engineer!
BBSec Anti-Abuse Mail Service detects compromised accounts,and care the customers silently by human support.
In the case of BBSec
• At the start of service, we act against DHA– Less breach of mail addresses from mail servers
• In July, 2012, we start to detect compromised accounts– We could move before the attack become active in Japan.
• With our customer ISPs, we made fixed flow of customer care– We support end users to change their password safer.
• "End user – Customer ISP – BBSec" are co-working.
The preparation against threat
Discussion in M3AAWG( Feb.2012 〜 June,2012 )
M3AAWG
• Messaging,Malware&Mobile Anti-Abuse WG– Industrial group with 220 organizations
• All major messaging companies participate– Google,Facebook,Twitter,Apple,Microsoft…
• Act to standardize of technology, and make BCP– For example, DMARC– Similar to W3C in Web technology
• 3 times general meetings in one year– They have Round Table sessions in the morning to discuss…
» Compromised accounts» Outbound Filteringand so on.
Preparation is important!
If you believe digital certificates protect you from spoofing…
CAs can issue certificatesfor any domains.
Problem of “Digital Certificates for
Spoofing”New!
http://thehackernews.com/2013/12/fake-google-ssl-certificates-made-in.html
In the future, Can we see some seeds ?
Anti-SpoofingImproved user authenticationMore deployment of Sender AuthenticationFor Pervasive monitoring?
S/MIME? Path Encryption(TLS)?
Certificates verifying by DANE
ETSi Registered Electronic Mail( e-mail with strong authentication ex. DE mail )
BCP38/84 against UDP src address spoofingRPKI for verifying the origin of routing information
Anti-SpoofingAnti-Spoofing
Q & A time