The art of email spoofing protections.
Email is a vital backbone of all businesses in todays fast moving
connected world, defined as a protocol it is called ‘Simple Mail
Transfer Protocol’ and it’s quite correct in saying that the protocol is
quite simple. Email was never designed with security in mind, it was
created when networks were small enough that everyone knew each other,
and that alone was considered good enough reason to implicitly trust
emails from each other, there were no identification checks in place.However, as time went on networks got larger and larger with the internet becoming a massive global spanning network, and no longer could everyone implicitly trust each other. It was realised that it was possible to in effect ‘lie’ about who sent the email, giving rise to a form of attack known as email spoofing, where an attacker will forge the email headers to say the email is from a person it is not from. This can lead to various scenarios, most commonly where an attacker will forge the identity of someone to use their authorization in order to gain something, for example impersonate a CEO to order someone to wire money to a bank account.
In response to this three protocols have been introduced over time to attempt to mitigate the issue of email spoofing by providing mechanisms to verify that incoming mail is from the domain it claims to be sent from. These three protocols are known as the Sender Framework Policy (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication Reporting & Conformance (DMARC). These protocols will be explained in detail in how they operate, what they mitigate, and how to use them to help protect your own domain from being spoofed.
It’s important to note that there is no complete solution to prevent email spoofing. These protocols rely on the mail provider of the victim adhering to the usage of these protocols which cannot be guaranteed. However, the majority of mailbox providers will support these protocols and consequently deploying all three protocols will help to mitigate a vast majority of email spoofing attacks.
Sender Framework Policy (SPF)
The Sender Framework Policy works by providing a list of IP addresses
that are authorized to send email on behalf of the domain. This IP list
is stored in the DNS records of the domain as a TXT record. Email
providers that have SPF implemented will lookup the DNS records of the
domain from where the email is claiming to be from and if it finds an
SPF record in the DNS it will then compare the SPF record’s authorized
IP addresses to that of the originating IP address of the email. If
these IP’s match then the email will pass the test, otherwise it will
fail the test. What then happens to the email will depend on the fail
states of the SPF implantation by the email provider, it may be marked
as spam, or even rejected from the inbox. The following figure
demonstrates SPF in action:
Image Source: https://itzap.com.au/prodimages/sender-policy-framework-explained.jpg
How to setup SPF
To setup SPF a TXT record is added to the DNS records of the domain
sending the emails. The TXT record to be added is known as an SPF record
and will define the parameters of SPF such as what IP addresses are
valid senders for the domain. This SPF record can be created from
scratch or by using online tools, below examples of the two are linked:SPF from scratch: https://www.openspf.org/SPF_Record_Syntax
SPF from online tool: https://www.spfwizard.net/
Once the SPF record is created place this in the DNS records as a TXT record. To verify that it has correctly been added to the DNS records we can use a tool called DIG against the domain. DIG will lookup the DNS records of the specified domain, this is shown in the following picture where we can see that the SPF record exists in the domain:
Failures of SPF
While SPF does aid in the mitigation of email spoofing, it also has multiple downfalls. Firstly, SPF
will only check the ‘envelope from’ of the email for the domain name
and its related SPF DNS Record. This is separate to the ‘header from’
field which is the from email address that is visible to the end user in
many email clients. This difference allows an attacker to create a
spoofed email without failing SPF. Additionally,
SPF has multiple fail states, including still permitting SPF failed
emails to continue into the inbox of the victim. The settings for these
fail states are often controlled directly by the Email Provider, which
can cause difficulty in having these settings adjusted and tailored to
what the company requires. Overall this makes SPF unreliable to solely
use for preventing mail spoofing.
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail (DKIM) is a mail protocol that enables the
signing of emails in such a way that it is possible to verify who sent
the mail through cryptographic signature. Elements of the email will be
selected to be converted into a unique signature to the email through
the method of hashing. These elements must remain unchanged throughout
sending the email otherwise DKIM will fail its check on the receiving
end.Once this DKIM hash is created it is then encrypted with a private key held by the original sender. This encrypted DKIM signature is then sent along with the original email to the receiver. On receiving the email the mailbox provider will lookup the from domain for the public key which will be used to decrypt the DKIM signature into its original hash. The mailbox provider will now hash the selected elements themselves and compare it to the sent DKIM signature hash, if the two matches then it will pass DKIM authentication, proving who claims to have sent the email did send it. Otherwise if the hashes don’t match then the email fails DKIM authentication.
How to setup
To setup DKIM a TXT record is added to the DNS records of the domain
sending the emails. This TXT record is known as a DKIM record and
defines the parameters required by DKIM to be operational. One of the
primary parameter of this record will be the public key of the
private/public key required in order to encrypt and decrypt DKIM
signatures. As shown in the following figure:
For the exact details on how to setup the record the following guide can be used: https://support.dnsimple.com/articles/dkim-record/
Failures of DKIM
However, DKIM has the same flaws as
SPF, in that an attacker can forge the ‘header from’ address of the
email which is the from email address that is visible to the end user in
many email clients. DKIM will only authenticate the ‘envelope from’
address of the email which is generally hidden from the user. This, just
like with SPF, can make DKIM unreliable for solely preventing mail
spoofing.
Domain-based Message Authentication, Reporting & Conformance (DMARC)
Domain-based Message Authentication, Reporting & Conformance
(DMARC) is the latest mail protocol that combines and improves the SPF
and DKIM protocols, while also adding its own checks to resolve known
issues with SPF and DKIM.DMARC verifies that the email is being tested against DKIM and SPF correctly, and that the email is passing these protocol’s respective checks, DMARC also provides a way for organizations to specify what should happen if an email does fail the DKIM, or SPF checks, should the email be marked as spam, rejected, accepted, etc. DMARC also then adds another layer of check in the form of alignment checks which verifies the ‘header from’ domain in SPF matches the ‘envelope from’ domain name used, and that the ‘header from’ domain also matches the DKIM signature ‘d= domain’ header, thus preventing the use of ‘header from’ for email spoofing as has been an issue for SPF and DKIM. This process of alignment is shown in the following figure:
Source: https://www.dmarcanalyzer.com
How to setup
To setup DMARC there are three requirements that must be completed
before enabling DMARC. Firstly, both SPF and DKIM must be enabled and
correctly functioning beforehand. Secondly the Envelope FROM, Header
FROM, and d=domain fields must all align and have the same domain and/or
subdomain in order to pass DMARC’s alignment checks. Lastly two email
accounts should be created to receive aggregate and forensic DMARC
reports.Once the aforementioned requirements are completed, setting up DMARC is a relatively simple process. The following link can be used in order to generate DMARC records simply:
DMARC Record Generator: https://mxtoolbox.com/DMARCRecordGenerator.aspx
A great feature of DMARC is that you can set the record up to have a policy of ‘none’ so that forensic and aggregate reports get sent on a DMARC failure, but the emails do not get rejected straight away. This is useful for troubleshooting the setup stages of DMARC, without causing any impact on emails being sent and received. Once the record is correctly setup and only failing the intended emails, then the policy can be upgraded to enact on emails failing DMARC. Once the DMARC record is created place this in the DNS records as a TXT record. This can be verified in the same way that the SPF records were verified by using DIG against the domain to lookup the DNS records of the specified domain, this is shown in the following picture where we can see that the DMARC record exists in the domain:
Contact Us..!!
__________________________________________________________________________________
https://www.facebook.com/Walkalone3933?ref=bookmarkshttps://www.instagram.com/walk._.alone/
https://www.instagram.com/hackingtipsandstuff/
---------->Walk._.Alone<-----------
 |
| we are anonymous we are legion we do not forgive we do not forget expect us!! |
No comments:
Post a Comment