Jipdec 20131216-english

Against Mail Spoofing
Past, 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, John
These 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, Bob
We can’t read them even if they
were displayed on here…
…
It must have information about recipients. Later the message format of e-mail
is standardized in RFC822 (by Dave Crocker)

Sending Protocol
Hi, Bob
…
On the other hand, the sending protocol become original one, and
standardized in RFC821 (by Jon Postel)
HELO sender.example.jp
Mail From:sender@example.jp
Rcpt To:rcpt@aams.jp
DATA
…
.

Double existence of Sender/Rcpts info
DATA
…
.
From:
To:
Cc:
Subject:
Message-ID:
◯◯様
平素よりお世話になっております
…
From:
To:
Cc:
Subject:
Hi, Bob
…
Message body is delivered to the recipients as a text file, but sending/receiving log
can’t be checked by all the receivers.

Difference between two delivery
informations…
DATA
…
.
From:
To:
Cc:
Subject:
Message-ID:
◯◯様
…
From:
To:
Cc:
Subject:
Hi, Bob
…
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
Rcpt To:ml@aams.jp
DATA
…
.
From:
To:
Cc:
Subject:
Message-ID:
◯◯様
…
From:
To:
Cc:
Subject:
Hi, Bob
…
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 the
sending protocol can’t be spoofed. However, the other information can be spoofed.
HELO ml.aams.jp
Mail From:ml-owner@aams.jp
Rcpt To:ml-rcpt@example.net
DATA
…
.

From the receiver side…
Return-Path:
From:
To:
Cc:
Subject:
Hi, Bob
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.
DATA
…
.
No protection from
spoofing!

“E-mail is past technology” ?
Return-Path:
From:
To:
Cc:
Subject:
Hi, Bob
The sender’s IP address can be spoofed by route hijacking…
DATA
…
.

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, and
RPKI go covering to verify the origin of
routing information…

March,2013 DNSamp / Spamhaus
The problem of reflection attack
using IP src address spoofing
is not fully covered yet…
BCP38 !
uRPF !

How did e-mail engineers effort against spoofing ?

Sender Policy Framework(SPFbis)
Return-Path:
Authentication-Results: … spf=pass
From:
To:
Cc:
Subject:
Hi, Bob
SPF check the consistency between the sender’s domain (or sender’s FQDN
following HELO command) and the IP address of sending server using SPF RR
on DNS. The sender’s domain appears in Return-Path header in the message.
DATA
…
.
Verified by SPF

Sender Policy Framework(SPFbis)
Return-Path:
Authentication-Results: … spf=pass
From:
To:
Cc:
Subject:
Hi, Bob
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.
DATA
…
.
Verified by SPF

Return-Path:
Authentication-Results: … dkim=pass
From:
To:
Cc:
Subject:
Hi, Bob
Sign by secret key on sending server, verifying the signature by public key via DNS
on receiving server. The coverage of signing can be included headers and message
body. However only “From:” header must be included in it.
DATA
…
.
STD76: DomainKeys Identified Mail（DKIM）
Verified by
DKIM
Protected optionally

STD76: DomainKeys Identified Mail（DKIM）
Return-Path:
Authentication-Results: … dkim=pass
From:
To:
Cc:
Subject:
Hi, Bob
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.
DATA
…
.
Verified by
DKIM

Using both DKIM and SPF
Return-Path:
Authentication-Results: … spf=pass,
dkim=pass, …
From:
To:
Cc:
Subject:
Hi, Bob
Sender information (Return-Path/From) become very hard to spoof!
DATA
…
.
Sender info is verified

DMARC
Return-Path:
Authentication-Results: … spf=?,
dkim=?, dmarc=pass, …
From:
To:
Cc:
Subject:
Hi, Bob
Using the results of DKIM or SPF. If SPF is pass and DKIM is fail, DMARC checks
the consistency between “From:” and “Return-Path:” headers.
Senders can declare the e-mail processing policy when DMARC results is “fail”.
DATA
…
.
Checked by consistency

Remaining problems around Sender Authentication
Visualization of the results
Domain reputation

JIPDEC is trying to visualize the DKIM result with domain reputation (white list).

S/MIME signing
From:
To:
Cc:
Subject:
Hi, Bob
From:
To:
Cc:
Subject:
Content-Type: multipart/signed
-- separater
Hi, Bob
-- 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
-- separater
Hi, Bob
-- 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 management
Deployment 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 perform
server authentication
and path encryption
on all sending path
at least in RFCs.

MUA
Browser
Mbox
WebMail
Server
MBOX type
WebMail
Gateway
with IMAP
MTAMDA MTA
RFC5321RFC5321
RFC2023
RFC5321
RFC2023
RFC3501
RFC3501
RFC1939
Protocols using for Inbound with Path-Encryption
RFC3207RFC3207
RFC3207
RFC4616
RFC4616

MUA
Browser
WebMail
Server
MBOX type
WebMail
Gateway
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

Yahoo! Japan’s personal data
breach (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 accounts
Increase breached accounts/passwords, Alteration of web-content,
Distribution of malware, progress to APT…
Illegal access to mail accounts
Delivering 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 technology
by 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 of
massive spam
sending 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 Filtering
and so on.

If you believe digital certificates protect you from spoofing…

CAs can issue certificates
for 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 ?

Improved user authentication
More deployment of Sender Authentication
For 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 spoofing
RPKI for verifying the origin of routing information

Jipdec 20131216-english

Recommended

Recommended

More Related Content

Similar to Jipdec 20131216-english

Similar to Jipdec 20131216-english (20)

Recently uploaded

Recently uploaded (20)

Jipdec 20131216-english