Prevent email spoofing

Table of Contents

Securing email servers

Offense: What is email spoofing? "The sender is real..."

E-mail spoofing or spoofing refers to the actions of a hacker, for example, when he pretends to send an e-mail in the name of a company or domain to which he does not belong. A small example: An invoice is sent to companies or private individuals in the name of Telekom.de, but this invoice does not come from Telekom, but from the hacker. However, the domain looks correct upon closer inspection. So how can that be? 

Since e-mail is a form of communication that enables decentralized sending and receiving of messages via protocols such as SMTP, there is no central body that can check sent messages for validity. This means that sender addresses can easily be forged. Think of it like entering the wrong sender address on a letter. It is not possible for the recipient to evaluate whether a letter was actually sent by the specified sender without further measures and checks. It's basically the same with email.

The technical implementation of email spoofing

Basically, you do not need an email server to send emails. We use the tool here, for example swaks 

				
					swaks --to y.knoll@prosec-networks.com --from spoofuser@spoofdomain.de  --h-From: '"Spoof User" ' --server 104.47.7.138 -p 25 --header "Subject:Titel der E-Mail" --body ‘Guten Tag,\n\ndies ist der Start des Mailtests.\n\nMfg Spoof User’ --ehlo spoofdomain.com
				
			
–To Recipient's e-mail address
--from Email address of the sender
-h-From Sender's display name or spoofed email address
-server The mail server of the receiving domain
-headers The header part of the e-mail can be adjusted here, primarily the "Subject" or subject field
-body The content of the e-mail can be defined here
-ehlo Name with which the sender registers with the receiving mail server

The recipient of the e-mail will then see it as follows:

Prevent email spoofing
Prevent email spoofing

  Technically, the sending of the e-mail looks like this in the background:

So easy?

No, it's not that simple. Certain prerequisites or misconfigurations must be met so that the hacker's mail does not end up in the spam folder or does not arrive at all.

There are two DNS records for this that a domain should have stored so that such a spoofing process is not possible. These are the Sender Policy Framework (SPF) Record and the DomainKeys Identified Mail (DKIM) Record.

Run through attack scenarios under realistic conditions?
You can do it legally in our holistic hacking lab!
To the Junior Penetration Tester course

What exactly are these records?

The Sender Policy Framework (SPF) is a procedure that mail servers can use to check whether a received email actually comes from an authorized server. This is a fully automatic mechanism that runs unnoticed by the end user. 

Example of an SPF record

 

Hostname

Type

time to live

Value

Example.org

TXT

1 Hour

v=spf1 ip4:192.0.0.1 ip4:192.0.0.2 -all

Such an entry must be stored on the DNS server of the sending domain. The first part is the hostname. This is the domain or subdomain to which the record applies. Type describes the type of entry. SPF records are entered as TXT type. Time to Live instructs the DNS server to cache the DNS record for a specified amount of time.

The value is the actual SPF syntax. The "v" parameter describes the SPF version used, in this case version 1. Then, in the example, two IPv4 addresses are given as mail server addresses. Other entries could also be made here, such as A or AAAA (“a”) mail server records (“mx”). In addition, not only individual IP addresses but also IP ranges can be specified with IP4 or IP6.

The end of the SPF syntax is a directive that gives the checking mail server recommendations on how to handle emails that fail an SPF check. In the case of the example, it is recommended that the mail server should treat all checked emails that do not meet the criteria of the SPF record as "Fail" ("-") and not deliver them at all. There is also the option of defining a "soft fail" ("~"), "neutral" ("?") or "pass" ("+").

What is a DomainKeys Identified Mail - DKIM

What is a DomainKeys Identified Mail

DKIM (DomainKeys Identified Mail) is a method of email authentication. E-mails sent are signed by DKIM. A key pair consisting of a public and private key is used for this purpose. The public key is stored as a DNS entry on the DNS server of the sending domain. Receiving mail servers can then use this public key to check whether the signature was made with the corresponding private key. A sender of an e-mail can thus prove that his e-mail is actually a legitimate e-mail from the corresponding domain.

This is how DKIM works in detail

When an email is sent, DKIM adds a so-called DKIM signature to the email header. In this case, the "headers" of the sent e-mail are signed using the private key. At least the "from" header must be used as a signature, additional headers can be optionally added.

When the email is received, the receiving server asks for the public key. The signature can only be validated if the sender is in possession of the private key. The recipient can then check whether the signature matches the checksum. If there is a match, then it is proven that the sender has the private key of the DKIM key pair and is therefore very likely a legitimate sender.

Example DKIM signature:

				
					v=1; a=rsa-sha256; d=example.net; s=brisbane;

     c=relaxed/simple; q=dns/txt; i=foo@eng.example.net;

     t=1117574938; x=1118006938; l=200;

     h=from:to:subject:date:keywords:keywords;

     z=From:foo@eng.example.net|To:joe@example.com|

       Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;

     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;

     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ

              VoG4ZHRNiYzR
				
			

Source: Wikipedia

Explanation of the structure of the signature

v: version
a: Signature algorithm, in this case RSA with a SHA 256 hash
d: domain of the sender
s: selector. Identification of the corresponding record in the DNS entries. This is required if several SPF records are published for a domain
c: Canonicalization. Indicates how strict the signature verification is. The value "simple" or "relaxed" can be specified here for the header and body options. These potential changes are changes to the e-mail header or body that are made by the e-mail server itself when it is sent. The "simple" option states that almost no changes may be accepted. Even small changes lead to the failure of the signature verification. The "relaxed" option allows moderate changes. This can be, for example, a conversion to lower case and the removal of unnecessary spaces.
q: Query methods. Defines the procedure used to request the public key. Default is "dns/txt"
i: identity of the sender
t: Timestamp of the signature
x: Signature expiration time
l: Body length count. Describes the number of octets in the body that are part of the signature hash
h: signed header fields. Specifies the header fields for which the signature is formed. These must contain at least the "from" field. Other headers are optional
z: Copied Header fields. Copies of the signed headers
bh: The hash of the message body, corresponding to the length specified by "l"
b: The hash formed from the header fields

Example of a DKIM entry:

Hostname

Type

Time to live

Value

Mail._domainkey.example.com

TXT

1 Hour

v=DKIM1; p=76E629F05F70
9EF665853333
EEC3F5ADE69A
2362BECE4065
8267AB2FC3CB
6CBE

 

Under the host name we find an entry that is divided into the selector "Mail", the fixed part "_domainkey" and the domain name "example.com". A receiving server can use this name to request the public key. The entry then represents the actual DKIM syntax. "v=DKIM1; p=76E629F05F709EF665853333EEC3F5ADE69A2362BECE40658267AB2FC3CB6CBE"
is divided into the parameter v, which stands for the DKIM version used, and the parameter "p", which specifies the public key. The k parameter, which specifies the signing procedure, is often found in DKIM records.

DomainKeys Identified Mail

How to protect yourself from email spoofing

  • Email servers can be secured using SPF and DKIM.
  • However, spam can only be prevented if a receiving e-mail server also checks the corresponding functions of SPF and DKIM and reacts accordingly if one or both methods fail.
  • The sender can also provide instructions on how to proceed in such a case.
  • This is done using the domain-based message authentication, reporting and conformance method (DMARC).
Don't want to waste time on your way to becoming a penetration tester?
In our courses, led by experienced penetration testers, you will learn everything you really need for this.
Go to the Junior Penetration Tester Intensive Course
DIVIDE
Newsletter Form

Become a Cyber ​​Security Insider

Get early access and exclusive content!


By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!
OTHER CONTRIBUTIONS

Table of Contents

PSN_KU_Cover
NewsLetter Form Pop Up New

Become a Cyber ​​Security Insider

Subscribe to our knowledge base and get:

Early access to new blog posts
Exclusive content
Regular updates on industry trends and best practices


By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!