In our last blog post we discussed the hype around Domain-based Message Authentication, Reporting & Conformance (DMARC), the upcoming deadline for compliance to DHS’ Binding Operational Directive (BOD), the emergence of the protocol as a trendy email security tool and provided background on what DMARC actually is.
In part two of this blog series, we’ll look at the interdependencies of SPF, DKIM and DMARC, explore the limitations and vulnerabilities of each, and identify the unintended consequences of DMARC adoption.
As previously discussed, DMARC’s ability to authenticate email domains is fully dependent on proper implementation of SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail), both of which have their own limitations. Remember, the underlying responsibility of DMARC is policy enforcement, so if SPF and DKIM are not properly implemented by both sender and receiver, then DMARC cannot be effective at protecting against domain spoofing attacks.
While SPF in particular might seem relatively straight forward, it comes with significant limitations, most notably its domain lookup limit of 10. Specifically, this rule states that “SPF implementations MUST limit the number of mechanisms and modifiers that do DNS Lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier.”
This constraint wasn’t much of an obstacle when companies operated their own on-prem email servers. But given that many organizations now utilize cloud services, such as Office 365 and G-Suite and third-party senders, such as Marketo, Salesforce, Zendesk, which can all send email on the senders’ behalf - this limitation is often reached very quickly. Large organizations in particular would need to use different domains (or subdomains) for different purposes, creating an administrative nightmare prone to misconfiguration.
Another SPF limitation is that records only apply to specific Return-Path domains and not those found in the ‘from’ address. This leaves a window for scammers to create messages that will authenticate, yet the ‘From’ address (i.e. what the recipient sees), is actually a fake intended to trick the recipient into a false sense of security.
From: Bank of America <billpay@billpay.bankofamerica.com>
Return-Path: <recepcionfacturas@grupo-emsa.com.mx>
Subject: Your eBill Due Date Is Approaching
From: Billpay <billpay@billpay.bankofamerica.com>
Return-Path: <tua02@tribunalesagrarios.gob.mx>
Subject: Your eBill for Alex H. Lehocky
From: Bank of America <billpay@billpay.bankofamerica.com>
Return-Path: <billpay@billpay.bankofamerica.com>
Subject: You have a new eBill from Comcast Cable Communications
DKIM is notoriously difficult to implement, as made evident by the thousands and thousands of organizations that have failed to adopt the protocol. Perhaps for this reason, and the fact that a missing DKIM signature does not always mean a message is fraudulent, many cloud-based email service providers are set to check for DKIM. If it is missing, the email will always get delivered. However, as with SPF, DKIM does not prevent a scammer from spoofing the visible ‘from’ field.
As it currently stands, the adoption of DMARC is unregulated, and as such, many businesses are not prepared to implement it any time soon. In fact, Help Net Security recently reported that 99 percent of all domains worldwide do not comply with the protocol.
Recent research found that even Microsoft servers are not currently enforcing the DMARC protocol , meaning these exact domain spoofing messages are not being rejected by gateway controls, such as Office 365 EOP and ATP. This is especially perplexing when considering Microsoft frequently ranks as a top 5 most spoofed brand year after year.
Interestingly, an unintended consequence of DMARC adoption is that the more companies & organizations implement it, the more that attackers will launch domain impersonation attacks, which DMARC does nothing to protect against. Domain impersonation attacks (also known as homograph or cousin attacks), change character(s) in a domain, replacing numbers with letters, symbols etc. that look the same to both the naked eye and technology. Domain impersonation attacks are far more popular and easier to execute than exact domain spoofing.
Cousin/homographic domains are similar-sounding domains intended to trick SPF and DKIM by replacing characters with similar fonts, alphabets and numbers. For example, IR0NSCALES.com, instead of IRONSCALES.com (the letter ‘O’ is replaced by a zero) or leveraging Punycode transcription, which displays domain names using labels stored as ASCII strings (so a “c” is actually the Cyrillic character for the Latin letter “s”) will look the same when rendered by a Mail User Agent (MUA), tricking even the savviest of recipients.
Another challenge is that DMARC can and will break your mail flow if you don't implement both SPF and DKIM before changing a DMARC policy to anything above "none," which could cause a backlog in email messages - that’s assuming you’ve not set it to mark all messages as fraudulent. DMARC is also not built for robust cloud app usage and actually requires significant maintenance beyond authorization.
It’s important to remember that even if both sender & receiver have implemented DMARC correctly, exact domain spoofing attacks can exploit vulnerabilities in email clients to mislead end users on the validity of a message.
Email spoofing and impersonation techniques are becoming increasingly sophisticated, making authenticity of messages extremely difficult to prove. Despite the hype, the DMARC protocol represents only a very small piece to the very complex email security puzzle - domain authentication. The perception of DMARC as a ‘silver bullet’ for email security is misguided and easily debunked when looking at the email threat landscape as a whole.
In the third and final part of our DMARC blog series, we’ll introduce a solution for complete email authentication that is proven to detect, prevent and respond to email phishing and business email compromise attacks.