How can hostile element execute spoof e mail attack and bypass existing spf implementation introduct

Page 1 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF

implementation? | introduction | 1#2

Written by Eyal Doron | o365info.com | Copyright © 2012-2016

How can hostile element execute Spoof E-mail

attack and bypass existing SPF implementation? |

introduction | 1#2

In the current article series, we will learn about a structured vulnerability of the SPF mail

standard, which can be easily exploited by a hostile element that can bypass the existing “SPF

wall” that was built for protecting our organization recipients from Spoofing or Phishing attacks.

Besides of the part in which we point out the structured vulnerability of the SPF mail standard, I

would like to go into the “next level”, and demonstrate how to execute a Spoof E-mail attack

that bypass existing SPF implementation.

The current article series include two articles.

The next article is – How to simulate Spoof E-mail attack and bypass SPF sender verification? |

2#2

http://o365info.com/how-can-hostile-element-execute-spoof-e-mail-attack-and-bypass-existing-spf-implementation-introduction-part-1-of-2/


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/

http://o365info.com/how-to-simulate-spoof-e-mail-attack-and-bypass-spf-sender-verification-part2-of-2/





The Well Know Dilemma – Should I Reveal In Public The SPF Vulnerability? |

Blackhat Versus White Hat

Before we continue, I would like to relate to the most basic resistance that can appear in the

mind of the reader: How do you dare to publish such information that can be used by a hostile

entity to hurt and damage my organization?

The simple truth is that the most of the time, this “hostile entity” is a professional person that

has a wide knowledge and a defined path for the why he should use for executing Spoofing or

Phishing attacks, and how to deal with existing sender identity verification standard such as SPF.

In other words, the “hostile entity” doesn’t need my help and my support in revealing the

structured vulnerability of the SPF mail standard. I can assure you that he already knows about

this “SPF blind spot”, and the chance is that if he decides to attack your organization, he will use

it!

As a person which was appointed to serve and protect our organization’s assets and our users,

we should have the integrity and the courage to admit that there are many threats and risks,

that could hurt us.

Instead of “closing our eyes” and ignore the vulnerability of our mail infrastructure, it looks to

me that the best state of mind should be – move on to the more constructive and mature

question such as – given that I am aware of this existential threat to my mail infrastructure, what

can I do to provide better protection to my organization and my users?

SMTP As Innocent Protocol | Spoof E-Mail And SPF As A Partial Solution

I describe the SMTP protocol as “Innocent protocol” because the main purpose of the SMTP

protocol is to transfer email messages from host A to Host B in the quickest and most effective

way.

When source Host (A) address destination Host (B), and asks to start an SMTP session, the basic

assumption of the destination Host (B) is that Host A is really who he claims to be.

This default assumption is being exploited by hostile elements, which disguise their real identity

by presenting the identity of a seemingly legitimate host \ recipient.

Over time, this “identity problem” reaches the awareness of organizations, that look for a

solution that will enable them to verify the sender’s identity, and be sure that the sender is really

who he claims to be.





http://www.openspf.org/




One of the most popular and well-known mail security standards that were invented to address

the need for verifying the sender identity is – the SPF (Sender Policy Framework).

The SPF standard is based on a very simple verification test; in which we verify if a specific mail

server is authorized to send or represent specific domain names.

The “specific domain name” is the domain name that appears in the E-mail address of the

sender who addresses our mail server.

The problem is that the SPF mechanism has an inherent weakness because that the sender

verification procedure, is implemented by verifying the sender identity that appears on the

Mail envelop but, not the sender identity that can appear in the Mail header.

This Inherent weakness is exploited by a hostile element that could easily bypass our existing

SPF wall, and perform Spoof E-mail attack.

Attached a quotation from the SPF organization site:

The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent

sender address forgery. More precisely, the current version of SPF — called SPF v1 orSPF

Classic — protects the envelope sender address, which is used for the delivery of messages.

See the box on the right for a quick explanation of the different types of sender addresses in e-

mails.

(There are other solutions that protect the header sender address or that do not care at all

about who sent the message, only who originally wrote it.)

[Source of information – Sender Policy Framework Related Introduction]

I assume that most of us are not aware or, only have partial knowledge about terms such as

Mail envelop , Mail header and the SMTP method in which the sender is using “multiple

sender identities”.

If you have the required patience, I promise you that after reading the current article, you will

understand better these concepts.

For the sake of full disclosure – my opinion is that the SPF stand is a very important and

considers as necessary mail security standard, that must be adopted by every organization that

uses mail infrastructure.

My main purpose is to bring to your attention the “blind spot” of the SPF standard and make

you understand that you will probably need to use an additional mail security standard and

mechanism, together or side by side with the SPF standard.





http://en.wikipedia.org/wiki/Open_standard

http://www.openspf.org/Specifications

http://www.openspf.org/Related_Solutions

http://www.openspf.org/Introduction




Additional reading

Sender Policy Framework Related Solutions

How Spammers Get Around SPF

So What Is The Solution For This SPF “Blind Spot”?

I would like to expand this question to wider range questions:

Q: Is there or, what is the “perfect solution” that I can use for providing complete protection for

my organization from Spoofing or Phishing attacks?

A: The good news is that there is such a thing as a “perfect solution” and when this solution is

applied, we can be sure that your organization has a very good protection from Spoofing

attacks.

The less good news is that there is no magic formula or a simple “red button” that we can use

for creating a “transparent dome of energy” that will protect our organization from any type of

“bad guy” and at the same time, enable our user to “do their thing” regularly and transparently

without any interference.

The solution of our distress is – a combination or a “cocktail” of different mail security standard

that enables us to verify the sender identity, such as DKIM, DMARC, Exchange Online Spoof E-

mail rules, user awareness program, etc.

The implementation of such combination will enable us to build a strong and thick “protection

wall,” that will protect our mail infrastructure and our users from most of the risks and the

hostile elements that are outside the wall and looking for a way to enter.

Our main tasks are:

Acknowledged the risk of Spoofing or Phishing attacks and the fact that while one way or

another, we experienced the danger of the above.

To be familiar with each of the possible solutions and the characters of each of the

possible solutions (advantages, disadvantages, etc.).

Decide what is the best combination of solutions that will best feet our organizational

DNA and our organization-specific business need.

Implement the existing protection mechanism, and have the required patience for the

required time that is needed to adopt and assimilate this solution (learning mode phase,

test phase, dealing with a false-positive scenario, etc.).

In the following diagram, we can see an example of the concept which I describe as a “security

cocktail”.





http://www.openspf.org/Related_Solutions

http://www.circleid.com/posts/782012_spammer_get_around_spf/

http://www.dkim.org/

https://dmarc.org/




The meaning of this term is a scenario, in which we use a combination of two or more mail

standard or another mechanism such as Exchange rule that will complement each other.

For example, in case that your mail infrastructure is based on Exchange architecture, we can use

an Exchange rule that will identify the

a un-authenticated recipient who uses an E-mail address with our domain name +

implementing the SPF sender verification standard, that will identify a scenario in which recipient

who uses an E-mail address with our domain name sends E-mail via an unauthorized mail server.

Another option could be using the DMARC mail standard that relies on the DKIM + SPF

standard, and provides a very good protection for most of the possible scenarios of Spoofing

attacks.

To recap – don’t look for any easy and simple solution that will that magically will solve all of

your problems. Be familiar with the existing risks and the existing solutions for this risk.

If you want to learn more about how to implement Exchange rule that will identify and will

respond in accordance, I have written article series of 12 articles that review the possible

options that you can use – Dealing with an E-mail Spoof Attack in Office 365 based

environment | Introduction | Part 1#12





http://o365info.com/dealing-with-an-e-mail-spoof-attack-in-office-365-based-environment-introduction-part-1-of-12/

http://o365info.com/dealing-with-an-e-mail-spoof-attack-in-office-365-based-environment-introduction-part-1-of-12/




If you want to learn more about how to implemented DKIM in Office 365 (Exchange Online

based environment, I have written article series of 5 articles that review subject – DKIM –

Domain Keys Identified Mail | Basic introduction | Part 1#5

The structure of the current article series

The article series – “How can hostile element execute Spoof E-mail attack and bypass existing

SPF implementation” includes two articles.

The current article our main focus will be:

1. The data structure of SMTP session and E-mail message.

2. The way that the SPF verification process is implemented.

3. The theoretical way that hostile element can use for bypassing existing SPF implementation.

In the next article, we will review the “how to part” in which we simulate a scenario of a hostile

element, that executes a Spoof E-mail attack and manages to bypass our existing SPF

infrastructure.

The Data Structure Of SMTP Session And E-Mail Message

Meta Data and E-mail message

Most of the time, when we use the term E-mail message, we relate to the E-mail message

content such as the text that is included in the E-mail message or the attachment in the E-mail

message.

In reality, each E-mail message includes an additional layer of information, which can be

described as metadata or as the “data about the data”.

The metadata that considers as part of the E-mail message, includes many details and

information about the specific E-mail message and a documentation of the journey that the

E-mail message undergoing begging with the source mail server, and ending with the

destination mail server that hosts the destination recipient.





http://o365info.com/dkim-domain-keys-identified-mail-basic-introduction-part-1-of-5/

http://o365info.com/dkim-domain-keys-identified-mail-basic-introduction-part-1-of-5/

http://o365info.com/how-to-simulate-spoof-e-mail-attack-and-bypass-spf-sender-verification-part2-of-2




Mail envelop & Mail header as a logical container for E-mail message metadata

The SMTP protocol defines two types of “logical containers” that will hold the metadata that

relates to a specific E-mail message:

The Mail envelope and the Mail header.

The Mail envelope is used by the mail servers who represent the sender and the recipient.








The Mail header is used by the mail client (by the user).

The information that is saved in the Mail Envelope

The Mail envelope includes the following type of information:

1. Hold Information about the “source mail server” that represents the sender – for example,

the IP address of the mail server that Initializes the SMTP session or information about a

specific security standard that the source mail server support such as DKIM.

2. Hold Information about all the mail servers who were involved in the mail flow.

3. Hold Information about the sender + recipient identity – the E-mail address of the sender

and the E-mail address of the destination recipient\s.








Mail structure – Mail Header & Mail Body

The “mail component” of E-mail message includes two parts:

1. Mail header – this is an “additional container” that holds metadata information. If you’re

wondering, why do we need to use an additional logical container for the metadata in addition

to the Mail envelope component, the simple answer is that very similar to the real-life scenario,

the

Mail envelope considers as a “temporary vehicles”, which is used for “transporting” the E-mail

message from point A to Point B.

After the E-mail, the message is accepted by the destination mail server that represents the

recipient, the mail server reads the information that appears in the Mail envelope copy most of

the information in the Mail header part and then, “tearing apart” the Mail envelope.

2. Mail Body – the mail body is that part which includes the text and the attachment\s that was

added to the E-mail message by the person who wrote the E-mail message.








The Mail header includes the following type of information:

1. Hold Information about the characters of the specific E-mail message – for example, the

character set of the specific E-mail message, MIME type etc.

2. Hold Information that was copied from the Mail envelope. As mentioned, the Mail

envelope is removed by the mail server before the E-mail message is delivered to the

destination recipient.

3. Hold Information about different security checks that was performed by the “destination mail

server” meaning, the mail server that represents the destination recipient.

Most of the time, the mail servers who represent the destination recipient perform a security

check that designed to identify “problematic mail” such as Spoof E-mail, E-mail that includes

malware, spam mail and so on.

The information about the “security check results, ” such as the SCL (spam confidence level)

value is saved to the Mail header.

Another example is a scenario in which the mail server is configured to perform validation of the

sender identity using a standard such as – SPF, DKIM, DMARC and so on. The results of this

sender identity test will also be written to the Mail header.

4. Hold Information about the sender + recipient identity – the information about the sender

E-mail address and the destination recipient E-mail address.








Note – in a common scenario, the sender \ recipient identities (E-mail address) of the Mail

header, will be copied from the Mail envelope.

The other optional scenario is a scenario in which the Mail envelope will include the sender \

recipient identities that the sender \ recipient identities that are specified in the Mail header.

The major type of identities in mail based infrastructure

Along this article, we mention the term “identity” many times.

Without going into depth technical discussion, it’s important to define the meaning of this term

when relating to mailing infrastructure.

When relating to mail infrastructure, the simple definition of the term “identity” could be

translated into:








1. E-mail address

2. IP address

3. User credentials

4. Certificate

Regarding the subject of – mail infrastructure and the SPF standard, the main identities that we

will relate to being mostly the E-mail address identity and the IP address identity.

When we say that senders want to send E-mail to a destination recipient, we relate to the E-mail

address of the sender and the E-mail address of the destination recipient.

Another type of “identity” is the identity of the mail server that sends the E-mail message on

behalf of a specific recipient. In this case, we relate to the identity of the mail server by as the IP

address that is used by the mail server.

Note – if we want to be more accurate, there is an additional type of identity that is derivative of

E-mail address identity, which is – the domain name identity. The domain name identity is

“taken” from the “right part” of the E-mail address.

Note – relating to mailing infrastructure, there are other types of “identities” such as user

credentials and certificate. In the current article, we will not relate to this type of “identities”

because this subject is beyond the scope of our article.

The need to verify the identity of the sender

One of the most basic security needs in mail infrastructure is – the need to verify beyond doubt

or verify with certainty, the identity of the involved parties in the mail flow session.








Note – It’s important to emphasize that many mail infrastructures don’t support, security mail

standard for verifying the identity of “external host” (sender or mail server) that address their

organization.

If we want to be more accurate, when we say that we need to verify a specific identity, most of

the time, the side that has had the interest to implement this procedure is – the “receiving side”

meaning the mail infrastructure of the destination recipient.

When “external entity” address the mail server that represents a specific domain (specific

recipient), and Introduces herself using a specific “identity” (specific E-mail address or specific IP

address), the mail infrastructure that represents the destination recipient needs to know that the

sender Is really who he claims.

For example, the basic of a Spoof E-mail or a spoofing and Phishing attacks is based on the

concept in which a hostile element address the mail server of a specific organization, and

“claims” that he is a legitimate organization recipient.

The be able to know if this “entity” is a real, legitimate recipient versus a hostile element that

camouflages itself by using the identity of a legitimate user, the mail server will need to

implement some kind of “identity check” for verifying the identity of the sender.

One of the most popular methods for verifying the sender identity is the SPF standard. When

using the SPF standard, the mail server that represents the destination recipient will verify the

identity of the “source mail server” meaning, the mail server that represents the sender by

verifying of the IP address of the source mail server IP appear in an “authorized list”.

Note – the “authorized list” is implemented by an SPF record (a TXT record), that is published on

the public DNS infrastructure, and include a list of IP address for the mail servers that are

authorized to send E-mail on behalf a specific domain name.

The different identities in a simple mail flow

To illustrate this “identities” concept, let’s use the following diagram.

In our scenario, side A wants to deliver an email message to side B.

1. The first identity (number 1) is the E-mail address that represents the user\ recipient who

wants to send the E-mail message. In our scenario, the identity of this user is –

[email protected]








2. The second type of identity (number 2), is implemented in a scenario in which the “original

sender” wants to send the E-mail message on behalf of other senders.

A classic scenario is a scenario of the assistant and the manager in which the assistant wants to

send E-mail to an external recipient on behalf of her manager.

In our specific example, the manager identity is – [email protected]

3. The third identity (number 3) is the identity of the mail server that represents the sender.

We relate to the source mail server identity by specifying the mail server IP address.

4. The fourth identity (number 4) is the identity of the mail server that represents the destination

recipient.

We relate to the destination mail server identity by specifying the mail server IP address.

In case that the destination mail server supports SPF, the verification process of the sender

identity is implemented by a verifying that the source mail server IP address is registered as an

authorized IP for a specific domain name (the domain name that appears in the E-mail address

of the sender).

In our specific scenario, the SPF verification process will check if the specific mail server is

authorized to send E-mail for the domain name – thankyouforsharing.org

5. The fifth identity (number 5) is the E-mail address that represents the destination recipient. In

our example, the destination recipient is represented by the E-mail address

– [email protected].

Note – in a real-life scenario, the mail flow could be more complicated and include additional

mail servers.








The Mail Fields That Contain The Values Of Sender And Recipient Identities

In the current section, I would like to review that specific “mail fields” that is used by the SMTP

protocol for representing the “identities” of the sender and the recipient E-mail address.

As mentioned, a standard E-mail message includes two parts – the Mail envelope and

the Mail header.

Each of these components uses different “mail fields” for representing the identity of the sender

and the recipient.

Mail envelope

(RFC 5321 | https://tools.ietf.org/html/rfc5321)

Source sender MAIL FROM

Destination recipient RCPT TO

Mail header

(RFC 5322 | http://www.rfc-base.org/txt/rfc-5322.txt)

Source sender FROM





https://tools.ietf.org/html/rfc5321

http://www.rfc-base.org/txt/rfc-5322.txt




Destination recipient TO

Mail envelope – the “mail fields” that hold the value of the sender and the recipient

1. The sender identity – the Mail envelope uses a “mail field” named – MAIL FROM for

“holding” the information about the sender identity (the sender E-mail address).

2. The recipient identity – the Mail envelope uses a “mail field” named – RCPT TO for

“holding” the information about the recipient identity (the destination recipient E-mail

address).

Mail header – the “mail fields” that hold the value of the sender and the recipient

Regarding the “mail component”, the part which holds the information about the sender and

recipient identities is the Mail header.

1. The sender identity – the Mail header uses a “mail field” named – FROM for “holding” the

information about the sender identity (the sender E-mail address).

2. The recipient identity – the Mail header uses a “mail field” named – TO for “holding” the

information about the recipient identity (the destination recipient E-mail address).








The Relationship Between The Mail Envelope Infrastructure And The Mail

Header Infrastructure

The method in which we use two sets of different identities (Mail envelope identities and Mail

header identities) can be regarded as confusing.

For now, let’s suffice basic answer that this “separation” was created by the SMTP protocol for

answering the needs of various business scenarios.

In some scenario, the information about the sender and recipient identities in the Mail

envelope will be identical to the information in the Mail header and in some scenario, not.








The common scenario – the identities in the Mail envelope are identical to the identities in

the Mail header.

The most common scenario is a scenario in which we use only one set of the sender and the

destination recipient identities.

For example, when a user writes a new E-mail address, his E-mail address configured

automatically in the MAIL FROM mail field, and the E-mail address of the destination recipient

is configured in the RCPT TO mail field.

Given that the destination mail server complete all the security checks and he is willing to accept

the E-mail message, the information about the sender and the recipient identities will be copied

from the Mail envelope to the Mail header.

The information from the MAIL FROM field will be copied to the Mail header field named

– FROM.

The information from the RCPT TO field will be copied to the Mail header field named – TO.

Another scenario – the identities in the Mail envelope is not identical to the identities in

the Mail header.

In this scenario, there are different “set of identities” that represent the source, sender and

different “identities” that represent the destination recipient.

To be able to demonstrate such case, let’s use the following scenario:

Suzan is the personal assistant of John.

Suzan was asked by John to send an E-mail message to one of his customers.

When Suzan creates a new E-mail message, the information about Suzan identity will be saved

in the Mail envelope in the MAIL FROM field.

The information about John’s identity will be defined in the FROM field.

In this scenario, the information stored in the MAIL FROM field in the Mail envelope, will not

be copied to the Mail header because the FROM field is already “populated” with the E-mail

address of John.








The “Additional” Identities That Involved In The SMTP Mail Flow

In the current section, I would like to briefly review three additional “identities”, that are involved

in the SMTP mail flow.

The source mail server’s identity | The HELO \EHLO command

As mentioned, the “main identity” of the “source mail server” is the server IP address.

Additional types of identity that the source mail server can provide when he Initializes SMTP

session with another mail server is – the hostname + domain name which the mail server

represents.

The information that the source mail server can provide is not a mandatory requirement but

instead optional.

In case that the source mail server wants to provide this type of identity (his HOST name, the

domain name that he represents or a combination of a hostname + domain name which

described as FQDN), the mail server can provide this information after the SMTP

command HELO (or EHLO).

The Reply-to identity

The second type of “identity” that can be included in E-mail message is the mail field

named – REPLY-TO.








As the name implies, the purpose of this mail field is, to include information about a specific

The E-mail address that we want that the destination recipient will use if he “hit” the reply

button.

By default, this mail field is empty and the default value (E-mail address) that will be used in the

case that the destination recipient uses the reply option is – the E-mail address that appears

in TO mail field.

The RETURN-PATH identity

The third type of “identity” that can be included in E-mail message is the mail field

named – RETURN-PATH.

The purpose of this mail field is to contain the E-mail address, that will be used by the

destination mail server to inform the “sender” about a problem such as non-existing recipient,

etc.

By default, the value (the E-mail address) of the mail field RETURN-PATH is not determined by

the source sender or by the source mail server but instead, by the destination mail server.

When the destination mail server gets the E-mail message, he will “extract” the E-mail address

from the MAIL FROM field, and copy this E-mail address to the RETURN-PATH mail field that

will be saved as part of the Mail header.








Most of the time, even if the source sender specifically states the value of the E-mail address of

the RETURN-PATH mail field, the destination mail server will ignore this information, and will

use the E-mail address that appears in the Mail envelope section in the MAIL FROM

Additional reading

Bounce address

What is the behavior difference between return-path, reply-to and from?

A Description Of A Standard SMTP Mail Flow And The Use Of Mail Envelope

And Mail Header

In the current section, I would like to “wrap” the information that we have reviewed in the

former section of the current article, so we will be able to understand better how the different

components are operating in a standard SMTP session.

Let’s describe a standard SMTP session in which sender A want to send an E-mail message to

the recipient B.

The source mail server addresses the destination recipient mail server and asks his

permission to start an SMTP session (by using the SMTP command HELO or EHLO).

The destination mail server is willing to accept the request for the SMTP session.

The source mail server delivers the information that is kept in the Mail envelope.

The destination mail server looks at the information and finds the required information

about the sender identity (E-mail address) and the recipient identity (E-mail address).





https://en.wikipedia.org/wiki/Bounce_address

http://stackoverflow.com/questions/1235534/what-is-the-behavior-difference-between-return-path-reply-to-and-from




Based on the information that appears on the Mail envelope , the destination mail server

can perform a variety of security check and sender identification checks.

For example, verify if the source mail server IP address appears as blacklisted, verify if the

source mail server is authorized to represent the specific domain name and so on.

The destination mail server adds to the Mail header information about all the security

test and their result.

The destination mail server copies most of the information that appears Mail envelope to

the Mail header

Regarding the mail fields that “contain” the information about the identity of the sender and the

recipient, one of the two possible scenarios can occur:

Case 1

In case that the information that was sent from the source mail server doesn’t include values for

the mail fields – FROM and TO, the destination mail server will implement the following

procedure:








Copy the E-mail address in the MAIL FROM field to the Mail header FROM

Copy the E-mail address in the RCPT TO field to the Mail header TO

Copy the E-mail address in the MAIL FROM field to the Mail header RETURN-PATH

Case 2

In case that the information that was sent from the source mail server includes values for one or

for all of the following mail fields – FROM or TO, the destination mail server will implement the

following procedure:

In case that one of the mail fields that “belong” to the Mail header (FROM or TO) include a

specific value (E-mail address), the information will not be copied or in other words, will not be

overwritten by the value that appears in the Mail envelope.

Reading the mail fields that “belong” to the Mail header (FROM or TO) and doesn’t include a

specific value (E-mail address), the information will be copied from the Mail envelope mail

fields respectively.








The end of the process will include the following task that will be implemented by the

destination mail server:

The destination mail server will remove the Mail envelope (the Mail envelope is not part

of the E-mail message that is sent to the recipient).

The destination mail server will deliver the E-mail message to the destination recipient








SPF Verification Process – Common Scenario

In the following section, I would like to briefly review the SPF verification process that is

implemented by the destination mail server will.

To demonstrate the SPF verification process, let’s use the following scenario:

Suzan is the source sender who uses the E-mail address – [email protected]

Bob the destination recipient who uses the E-mail address – [email protected]

The source mail server that represents Suzan, addresses the mail server that represents the

destination recipient – Bob.

In our scenario, the Mail envelope includes information about the sender (MAIL FROM), and

about the destination recipient (RCPT TO) but the Mail header fields (FROM and TO) are

empty.








Given that the destination mail is configured to use SPF for verifying the sender identity, the

mail server will perform the following tasks:

1. “Fetch” from the sender address (MAIL FROM) the part which represents the sender domain

name. In our scenario the domain name – thankyouforsharing.org

2. “Write down” the IP address of the source mail server.

3. Addresses DNS server and check if the domain thankyouforsharing.org have an SPF record (a

TXT record). In case that such record exists “read” the content of the SPF record.

4. Verify if the IP address of the source mail server appears as one of the IP addresses in the

SPF record.

5. In case that the IP address of the source mail server appears in the list, the SPF verification

test considers as “successful”. The meaning is that the source mail server is authorized to

send an E-mail message to thankyouforsharing.org recipients.








The More Complicated Scenario, And The Vulnerability Of SPF Verification

Method

In the following section, I would like to review the way that a hostile element can use for

implementing a spoofing or Phishing attacks to attack our organization + bypass the SPF

verification check that is implemented by our mail server.

The attack is based on the following building blocks:

1. The SMTP standard | using multiple sender identities

The SMTP protocol includes an option in which the “source” meaning the element that sends

the E-mail message to the destination recipient can provide two different identities:

The identity of sender A will appear on the MAIL FROM mail field (the mail field that

appears in the Mail envelope).

The identity of sender B will appear in the FROM mail field (the mail field that appears in

the Mail header).

2. SPF sender verification process | The MAIL FROM mail field and the FROM mail field

The SPF sender verification process is implemented only for the identity (the E-mail

address) of the sender who appears on the MAIL FROM

The SPF sender verification process is NOT implemented only for the identity (the E-mail

address) of the sender who appears on the FROM








The meaning is that the SPF standard has a “blind spot” because the “FROM” identity is not

checked or verified by the SPF verification test.

The major problem is that hostile element that knows about this “Deadly Cocktail”, can very

easily exploit this “blind spot” that the SPF standard have.

The DNA of Spoof E-mail attack that exploits the SPF “blind spot”

The exploits of the SPF “blind spot” is implemented by the hostile element in the following way:

When executing a Spoofing or Phishing attacks, the main purpose of the hostile element is to

Cause the other party to perform and do something for him (to transfer money to a bank

account, click on a web link and so on).

To convince the destination recipient whom he wants to attack to “do” the specific action, the

hostile element needs to conceal his true identity and present himself as a legitimate user \

recipient. In other words, provide an E-mail address which the destination recipient can trust.

To succeed in executing spoofing or Phishing attack, even when the mail infrastructure that

represents the destination recipient uses sender verification procedures that are implemented

by the SPF standard.

In order to actualize this “SPF bypass mechanism”, the hostile element performs the following

steps:

1. Purchase a dummy domain name – I use the term “dummy domain” because there is no real

meaning of the domain name. The purpose of the dummy domain name is to serve as a

decoy for the SPF sender verification process that will be implemented by the mail server

that represents the destination recipient.

2. Configure the required SPF record in the DNS server who hosts the dummy domain name.

3. Add the required information meaning the IP address of the mail server that he uses for

performing spoofing or Phishing attack.








The Spoof E-mail attack is implemented in the following way:

The hostile element creates an E-mail message, that includes two senders E-mail addresses.

The first E-mail address (MAIL FROM) uses the “legitimate domain name” (the dummy

domain name). In our specific example, the MAIL FROM E-mail address is the “red

domain” E-mail address.

The second E-mail address (FROM) uses the domain name of the recipient, whom he

wants to attack. In our specific example, the FROM E-mail address is the “green domain”

E-mail address.








Given that the mail server that represents the destination recipient support SPF, the sender

verification process will be implemented by verifying the “red E-mail address” (the E-mail

address that uses the dummy domain name).

Given that the hostile element

Create the required SPF record

Uses mail server that is IP address appears in the SPF record (the mail server that sends

the E-mail message using the dummy domain name)

The SPF sender dainty verification will complete successfully.

The destination mail server removes the Mail envelope , including the MAIL FORM address

and leaves the “green E-mail address” (the FROM E-mail address).

From the destination recipient point of view, the E-mail message was sent by the sender with

the “green E-mail address”. The destination recipient is not aware that the “first E-mail address”

that appears in the Mail envelope was removed.








The Demonstration Of How The Hostile Element Bypasses The SPF

Verification Check

To be able to demonstrate the way that hostile element can use for bypassing the SPF sender

verification check, let’s use the following scenario:

A hostile element plans to attack (execute Spoofing \ spear Phishing attack) company named –

o365pilot.com

The hostile element did the homework, and finds the required information about the persons

who hold a key role in the organization:

The company CIO is Bob that uses the E-mail address [email protected]

The company CFO is Suzan that uses the E-mail address [email protected]

The hostile element is planning to send Spoof E-mail to Bob that apparently delivered from

Suzan.

The hostile element knows that the mail infrastructure of o365pilot.com implements an SPF

sender verification check for each incoming mail.

To be able to bypass the SPF sender verification check, the hostile element uses a dummy

domain name named – thankyouforsharing.org

The hostile element creates the required SPF record that will use for publishing information

about the authorized mail server of the domain name – thankyouforsharing.org

The hostile element creates a new email message that includes two sender’s E-mail address:

[email protected]

[email protected]

The destination recipient whom the hostile element wants to attack is Bob the company CEO.





mailto:[email protected]




The hostile element mail server will address the mail server that represents the destination

recipient by starting an SMTP session, and ask him to deliver the E-mail message to the

destination recipient.

The destination mail server will perform the SPF sender verification test for the E-mail address

that appears in the MAIL FROM.

In our scenario, the mail server will try to verify the SPF record of the domain

– thankyouforsharing.org

Given that the SPF record was configured correctly, the SPF sender verification test is completed

successfully, and the mail server that represents the destination recipient “declares” that the

sender can be trusted (that the sender is a legitimate sender).








The destination mail server will copy the E-mail address that appears in the MAIL FROM

([email protected]) to the mail field – RETURN-PATH.

The destination mail server will remove the Mail envelope that includes the information about

the E-mail address – [email protected]

The mail server will forward the E-mail message to the destination recipient (Bob).

Bob sees the E-mail message as E-mail message that was sent from [email protected]








The next article in the current article series

In the next article –How to simulate Spoof E-mail attack and bypass SPF sender

verification? | 2#2, we will learn how to simulate Spoof E-mail attack and bypass SPF sender

verification.







How can hostile element execute spoof e mail attack and bypass existing spf implementation introduct

Documents