Assignment 2

Michalis Marcoux

Email Authentication Mechanisms - Part 1

There are a few separate way to increase the security of the emails going through and originating from a domain. Each provides its own check on specific areas in which a possible attack could be conducted, but all are placed within the DNS records of a given domain. This allows for any mail server to check against the DNS records of a given domain to ascertain the authenticity of a given email.

SPF - Sender Policy Framework

The first and simplest of all the defensive mechanisms, it serves to provide information to the Message Transfer Agent (MTA) on whether the email that they have received did indeed originate from its purported domain. This is in essence checking if the email originated from the address that it says it has. The SPF record is practically merely a list of domains or IPs that are considered to be valid mail servers for an email coming from the organisation.

SPF allows for a greater degree of certainty that an email has actually originated from a given domain; organisation.

Problems

The possibility of an attacker seizing on of the systems with a valid IP, means that this singular measure does not prevent an attacker being able to phish with a valid address. After gaining control of one of the aforementioned systems, they could potentially stay undetected for a while, having their malicious emails appear as having originated from the proper source - and in this case, they would be doing so, in a sense.

It is also easy to misconfigure the mechanism through the incorrect use of the ~ (tilde) symbol as opposed to the - (minus) symbol. The latter, which is usually the one that is intended to be used, denotes that the following specified domains or IPs - though it is usually used with all as a catch-all - be rejected. In contrast to this, the former classifies the email as a SOFTFAIL, which only results in it being marked, after being accepted. This greatly increases the risk that a recipient may believe that a truly inauthentic email may have simply been misplaced into their spam, and that it is actually authentic. If an attacker is careful in their manner of crafting the email and imitating the target organisation’s style, such an attack could be far more effective than might initially be thought to be.

DomainKeys Identified Mail - DKIM

In comparison to SPF, this is a much more complex security measure. Making use of public key encryption, it is another method of making emails that have not been produced from within a domain identifiable to recipients. The headers of emails sent from the domain are signed with its private key, and as the DKIM record on the DNS contains the domain’s public key, the recipients of emails whose headers state that they have originated from there are able to validate the authenticity and integrity of the message with the public key. It should be noted that the a hash of the entire message is generated and encrypted with the private key as part of this scheme (for message integrity). This is usually handled by the MTA rather than the end recipient, retrieving the public key and then proceeding to deliver the email only if the check has passed.

Problems

As with SPF, it remains plausible that a malicious actor who has gained access to one of the valid systems that operate for the domain may obtain the private key. In this case, there is no backup measure of authentication built in to the protocol.

That being stated, it increases the requirement for the sophistication of the attacker; as they no longer simply need to obtain access to the system, they must also be able to identify the private key within it and be able to create “proper” headers for their own emails. This raises the bar to only those who are well versed in both cryptography and the low-level structure of emails.

In terms of misconfiguration on the part of the domain holder, it is far more diffcult, as opposed to SPF, for this to even occur let alone be exploited. Effectively only occurring when the signing algorithm defined is out of date, or weak by modern standards, or if it is entirely invalid in its format, marking both authentic and inauthentic emails as fraudulent, enabling phishing emails to blend in with legitimate ones.

Domain-based Message Authentication, Reporting & Coformance - DMARC

Unlike the prior two systems, this is a framework for security policy; not a mechanism in itself. Instead of defining some parameter that must be met by an email, it specifies what should be done about a given email given the prior two mechanisms are in place and have returned either valid or invalid. For instance, an email which fails the DKIM and SPF checks may be allowed into the user’s mailbox, allowed in but marked as Spam or Suspicious, or entirely rejected; never touching the user’s mailbox, not even their trash.

Facilitating the communication of the sender to the receiver in regards to the general policy of the email of the domain, it allows for a great degree of control as to what should happen to an email, and even contains the option for only a given percentage of emails to undergo scrutiny; saving on compute in cases where volume is high.

Problems

Due to the great degree of control, which is one of the major benefits of this security framework, the possibility for lax or blantantly insecure policies to be set within the record exists. Simply having DMARC does not provide any guarantee. This, of course, results in attackers who are able to identify weak policies within the DMARC record - which is publicly available for them to examine - to either exploit the existing problem, e.g. sending emails with spoofed headers in the case of no policy being defined, or targeting the weakest link of the mechanisms defined within the policy, e.g. if email is considered valid after passing just SPF, they may target the least secure of all the systems specified within the SPF record.

The Mechanisms Combined

Alone both SPF and DKIM are mediocre solutions with obvious limitations, and DMARC cannot practically exist without the at least one of the prior two in place. Combined, however, they form a proper system of validation.

General Vulnerability

It should be noted, though this itself would be of great difficulty to a malicious actor, that all of these measures are contained within the DNS records of a domain, and as such any DNS attacks render these measures useless. Such an attack could be DNS spoofing, wherein the victim’s (mail server’s) retrieved records are fictional, or if the domain’s admins lose access to their registrar’s admin panel.

Practical Configuration - Part 2

In this section we will be creating the aforementioned configurations and records.

SPF

As an SPF record is simply a TXT record, all we have to do is refer to the specification to create a valid record. The following text would go inside the TXT record with the Host/Name field being securemail.com.

  1. In accordance with the specification we must first define the version; our record must start with:

v=spf1

  1. From our requirements we must introduce two valid mail servers, mail.securemail.com and smtp.partner.com, and we shall do so with the a operator (for A record lookup):

v=spf1 a:mail.securemail.com a:smtp.partner.com

  1. We must then reject all other origins. Notice the use of the - and not the ~ symbol, as we truly wish for any email purporting to be from our domain to be failed:

v=spf1 a:mail.securemail.com a:smtp.partner.com -all

As we do not wish to send email from our plain domain, nor from the mailservers defined within its MX records, we omit the a mx from the record. We also do not wish to include hardcoded IP addresses, so any ip:XXX.XXX.XXX.XXX or ip6:XXX... are omitted.

We are choosing to outright reject all other domains to increase our security, whilst simultaneously avoiding the hardcoding of IP addresses into the record, enabling us to change the corresponding systems that the domain points to without having to rewrite the SPF record every time this is done.

DKIM

In this record we require a public key that is associated with a secret key possessed by our two mail servers. As such we must create one before beginning the construction of the record.

  1. Generate the key pair with RSA-1024:

openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:1024 -out key.pri -outpubkey key.pub

Generation of Keys

Giving us:

Public Key

  1. We would then obtain the public key of our partner’s service (smtp.partner.com) to include within the record with a different selector.

  2. Write the first record, for our site:

our._domainkey.securemail.com

p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyvGhCB7/3Z8mj9ZbYBCDlYcwg
SZ2snXHuZhpfS5vRAl3Xtxc3q/HapijFZyyTXaGowm1z7BlzsO0+4SJ/nJ6xKJ/B
CXXGzRrdtkm4SbJsKzO6U1jkECFfEJwXf5CHtxZqR+YwjlfawBCtRbjnqdg0QLrO
Kfr93YsnM2u82LLyhQIDAQAB;```
  1. Write the second record, for our partner’s site:

partner._domainkey.securemail.com

p=THEIR_PUBLIC_KEY```

Unfortunately, we do not possess access to an actual domain within which we could place these records, and as such we cannot practically demonstrate the signing of emails. Though we can demonstrate this, in concept, using openssl.

  1. Signing and verifying

Creation of Email

Creation of Signature

Verification of Email with Signature

In terms of decisions made here, the only one is the specification of the algorithm and the bit-length used in key generation. RSA is considered to be an industry standard, but due to the nature of the domain we are securing - a mail provider - it would be very computationally expensive to sign every email with a large private key. For this reason, we have opted to use the less secure, but convenient 1024 bit-length for our keys.

DMARC

Like SPF, all we have to do is follow the specification.

  1. First we define the version; our record must start with:

v=DMARC1

  1. As defined in the requirements, we’ll begin with the monitoring mode, setting out policy to none:

v=DMARC1; p=none;

  1. Now we must add the emails to which the reports generated by DMARC will be sent:

v=DMARC1; p=none; rua=mailto:example@securemail.com; ruf=mailto:example@securemail.com;

This will now succesfully serve our purposes. However if we wish for more strict enforcment, we must continue.

  1. Specify rejection policy as well as the percentage of emails to vetted - in this case 100%:

v=DMARC1; p=reject; rua=mailto:example@securemail.com; ruf=mailto:example@securemail.com; pct=100

As we wish for the emails from the domain to be secure, we are choosing to completely reject any and all emails that fail the SPF and DKIM checks; vetting 100% of them. Though in practise this percentage may need to be reduced due to the company providing email as its primary service (securemail.com).

Analysis of DNS Records - Part 3

The analysis was conducted using MX Toolbox and all of its associated tools, as well as bind to examine the DNS records containing all of the relevant information. Please note that MX Toolbox could not find the DKIM records for unknown selectors, and thus their presence was inferred from the DMARC record.

google.com

Employing dig to obtain all the TXT DNS records:

google.com’s DNS records

Employing dig to obtain the DMARC TXT records:

google.com’s DMARC record

We can only obtain the DKIM records if we are aware of the specific name of the selector used by the domain. Unfortunately we do not know this, and there also seem to be no free tools available that list out the selectors for a given domain. As such, we will simply be inferring whether or not a domain has a DKIM record from the presence of the DMARC record; brute-forcing would be a waste of effort.

google’s DKIM records could not be found

Observing the TXT records, we see that SPF has been enabled by Google, though they have taken the SOFTFAIL approach for handling all mail that has not passed the validation. This is not secure, and though it might be more convenient for them to do this, given that their internal systems are likely to be rather complex, it is not an appropriate use of SPF. The should change this to -all. In combination with DMARC, as can be seen in the next figure, which implies the presence of a DKIM record, their mail servers are relatively secure. Due to the policy being set to outright reject emails, the “gap” presented by the lax configuration of the SPF record is correct here. They have also configured an address to which DMARC may send reports, which is standard practice.

amazon.com

Employing dig to obtain all the TXT DNS records, filtering with grep due to the large quantity:

amazon.com’s DNS records

Employing dig to obtain the DMARC TXT records:

amazon.com’s DMARC record

The SPF record uses the minus symbol instead of tilde, meaning that the outright rejection of emails with invalid origins is enforced from this point; proper configuration. We may also see that within this record there is the use of the include operator, that allows for the SPF records of the other domains listed to be inspected as well; for a fine-tuned configuration. In contrast to this, the DMARC record’s policy is only quarantine, which is a step back in terms of security. Though they have explicitly specified that 100% of the emails originating from their domain will be examined. Given that Amazon does not yet provide an email service, it would be a better approach to have the policy be marked as reject instead. Like Google, they too have defined email addresses to which reports will be sent by DMARC. DMARC’s policy should be set instead to reject.

apple.com

Employing dig to obtain all the TXT DNS records:

apple.com’s DNS records

Employing dig to obtain the DMARC TXT records:

apple.com’s DMARC record

The SPF record uses the of tilde like Google, resulting in the SOFTFAIL behaviour that was described earlier; not a proper configuration. The use of the include allows the other domains listed to be inspected as well; for a fine-tuned configuration. The DMARC record’s policy is also quarantine. This does not leave the overall system as secure. The one saving grace from the DMARC record is the sp=reject, that will reject any email sent from a subdomain. Despite the fact that some relaxed parameters within the configuration are expected, given that apple does in fact run a mail service (though on a different domain), their records should not be overly lax. Comparing them to Google makes these security decision seem rather questionable. If they wish to have a lenient policy they should at least ensure that either the SPF uses -all or that the DMARC specifies blanket rejection for all invalid emails.

microsoft.com

Employing dig to obtain all the TXT DNS records:

microsoft.com’s DNS records

Employing dig to obtain the DMARC TXT records:

microsoft.com’s DMARC record

The SPF record uses the minus symbol instead of tilde, meaning that the outright rejection of emails with invalid origins is enforced from this point; proper configuration. We may also see the include operator; allowing for a fine-tuned configuration with all of the valid subdomains listed. Unlike the previous entities examined, the DMARC record’s policy is also set to reject, meaning that both the SPF record and the DMARC record have been configured for maximum security. They have also specified that 100% of the emails must be inspected by the protocols. This configuration requires no adjustements as it is proper in all ways we can examine, at least from our external perspective.

meta.com

Employing dig to obtain all the TXT DNS records:

meta.com’s DNS records

Meta has configured a redirect to another location for the record, with nothing being specified within meta.com domain. So we are required to inspect this new location for the site’s SPF record.

meta.com’s SPF record

Employing dig to obtain the DMARC TXT records:

meta.com’s DMARC record

The SPF record uses the minus symbol instead of tilde, which is the most secure option. We may also see the include operator; allowing for a fine-tuned configuration. We also see hardcode values for IP addresses, which is not necessarily more or less secure than pointing to a domain which itself will ultimately point to some address. Reject is also the policy held by the DMARC record, which is the most secure configuration of it, especially considering that 100% of the emails will be inspected. This configuration requires no adjustements as it is proper in all ways we can examine, at least from our external perspective.