Jipdec 20131216-english

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:


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


….

From:To:Cc:Subject:Message-ID:

◯◯ 様平素よりお世話になっております…

From:To:Cc:Subject:


Message body is delivered to the recipients as a text file, but sending/receiving logcan’t be checked by all the receivers.

mailto:[email protected]

Difference between two delivery informations…


….



From:To:Cc:Subject:


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


….



From:To:Cc:Subject:


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.


….

No protection from spoofing!


“E-mail is past technology” ?

Return-Path: From:To:Cc:Subject:


The sender’s IP address can be spoofed by route hijacking…


….


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…


March,2013 DNSamp / Spamhaus

The problem of reflection attackusing IP src address spoofingis not fully covered yet…

BCP38 !uRPF !


How did e-mail engineers effort against spoofing ?

Sender Policy Framework(SPFbis)

Return-Path:Authentication-Results: … spf=passFrom:To:Cc:Subject:


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.


….

Verified by SPF


Sender Policy Framework(SPFbis)

Return-Path:Authentication-Results: … spf=passFrom:To:Cc:Subject:


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.


….

Verified by SPF


Return-Path:Authentication-Results: … dkim=passFrom:To:Cc:Subject:


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.


….

STD76: DomainKeys Identified Mail （ DKIM ）

Verified by DKIM

Protected optionally


STD76: DomainKeys Identified Mail （ DKIM ）

Return-Path:Authentication-Results: … dkim=passFrom:To:Cc:Subject:


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.


….

Verified by DKIM



Using both DKIM and SPF

Return-Path:Authentication-Results: … spf=pass, dkim=pass, …From:To:Cc:Subject:


Sender information (Return-Path/From) become very hard to spoof!


….

Sender info is verified



DMARC

Return-Path:Authentication-Results: … spf=?, dkim=?, dmarc=pass, …From:To:Cc:Subject:


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”.


….

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:


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

Jipdec 20131216-english

Education

Transcript of Jipdec 20131216-english