Kraken, like any popular service, has clients that are targeted by scammers who try to send phishing emails from @kraken.com email addresses. You should never see this form of spoofed email because it should be rejected by mail providers like Gmail because their servers will notice that the scammer’s mail is not coming from Kraken. Behind the scenes, the accepting mail server is supposed to lookup common DNS records to verify that the email is coming from the right place (i.e., SPF, DKIM, DMARC records).
Kraken Security Labs believes in “trust, but verify”, and regularly tests the effectiveness of Kraken’s email security controls. During one of these tests we discovered that multiple mail providers are not performing simple checks and are thus putting their users (and potentially our clients) at risk for phishing: Specifically, yahoo.com and aol.com users were at risk of having email delivered to their inbox from non-existent subdomains of popular places, like email@example.com.
Kraken Security Labs reported this issue to Verizon Media (who owned aol.com and yahoo.com) on October 8, 2020. Unfortunately it was classified as low severity and our submission was closed due to low impact. However, since then, it seems like improvements to both email systems have been implemented, fixing some of the issues described below.
You can protect yourself by always being on the lookout for phishing scams. You should also consider switching your email service to gmail.com or protonmail.com if you are currently using aol.com or yahoo.com. If you run your own domain, ensure that your DMARC, SPF and DKIM records are up to date to limit the ability for scammers to use your domain.
At Kraken Security Labs, our mission is to educate and empower cryptocurrency holders with the knowledge they need to protect their assets and safely utilize their funds as they see fit. In this article, you will learn more technical details about this email spoofing technique, how we protect our domains and what steps you can take to ensure your security.
Spoofing was once a rampant form of attack just ten years ago. Email servers had no effective way to verify senders. Mail with a spoofed sender has a higher success rate, since many users don’t realize this field can be forged. A message from a recognizable domain (like firstname.lastname@example.org) can create an illusion of authority and security, especially when compared to an unfamiliar address like email@example.com. Thankfully, nowadays most mail providers have significant controls against spoofing. Standards such as DMARC have formalized techniques to make spoofing much more difficult.
Email security is more complex than what we’ll cover here, but the current best practices to prevent spoofing center around SPF, DMARC, and DKIM records. When a mail server receives mail, it does a few DNS lookups to the mail’s domain to check these records.
Each email server handles these checks differently. For example, Gmail tags all mail that fail SPF checks with a scary-looking warning banner encouraging users to be careful (even though these messages should technically never have been accepted by the mail server), and all emails that fail DMARC checks that have a “reject” policy will not be accepted at all.
Other mail providers can have dramatically different procedures, each with its own proprietary algorithm. For example, some providers choose to completely block emails, others send to a “junk” inbox, still others inbox emails with warnings.
Experimenting With Free Mail Providers
Inconsistent enforcement among different providers is concerning for us, so we did some further testing. We attempted to send spoofed emails for a locked down domain to the top free email providers and tracked their behavior.
Trial 1 – Spoofing of firstname.lastname@example.org (a secured base domain)
We sent a spoofed email from a domain that had a valid hardfail SPF record, a valid DMARC record, and a DKIM selector configured.
Expectation: Mail gets rejected because it isn’t from an allowed IP address and doesn’t have a DKIM signature.
No major surprises here, although sending a message to junk or spam means that users could theoretically still be fooled if they assumed it was a mistake.
Trial 2 – Spoofing of email@example.com (a Nonexistent Subdomain)
We sent a spoofed email from a subdomain domain that doesn’t exist. There are no records of any kind for this hostname.
Expectation: Mail gets rejected because the hostname doesn’t exist or have any records (no A record, no SPF or DKIM record). In addition, the DMARC policy was set to “reject”, and so any email that can not be authenticated by SPF/DKIM should be rejected.
Surprisingly, Yahoo.com and AOL.com mail servers accepted this obviously spoofed message and put it into the victim’s inbox. This is especially concerning, because it means an attacker simply needs to include a subdomain for their mail to be accepted and to look legitimate for users of these platforms (e.g., firstname.lastname@example.org).
AOL.com and Yahoo.com were at the time owned by Verizon Media, so we reported this issue to them on October 8th, 2020. Verizon Media closed the issue as being out-of-scope and informal. Kraken Security Labs reiterated the importance of protecting AOL & Yahoo users against phishing, but no further communication on fixing these issues was provided.
Since then it seems like improvements have been implemented: Emails are now rejected in accordance with the DMARC policy and better rate-limiting seems to be implemented.
We still argue that Yahoo & Verizon email users are at a higher risk, as other vendors have significantly better warnings towards their users when emails can not be authenticated (as is the case when no DMARC/DKIM/SPF is used at all).
Despite a domain owner’s best efforts, email providers are not always filtering email as expected. Users with @yahoo.com and @aol.com email addresses were at a higher risk of receiving spoofed messages, even though these messages could easily be detected and filtered by these providers. While the behaviors have improved, we still recommend switching your higher-sensitivity email to a provider that does better filtering, such as Gmail or Protonmail.
If you are running an email server, ensure your email DNS records for DMARC, DKIM & SPF are always up-to-date, and regularly verify whether your email controls are working.