security How To Avoid Domain Theft - Part 2: Phishing Emails

In part 1, we covered how to avoid domain theft by understanding a bit about how hackers operate. Next, let's discuss phishing emails.

We're pretty lucky that phishing email senders aren't too smart. Most the phishing emails I see have poor English, look rather slipshod, and aren't actually from the domain of the website they're impersonating.

Email is completely unauthenticated and anonymous. It was developed long before the internet when each network only had a handful of computers. It wasn't necessary to prove that someone was actually who they said they were: just the fact that they had access to the network made them an authority.

Over time, standards have been created that append to the existing email specifications; many attempt to add security, but most fail miserably. A classic and well-known example of a failure is SPF, which really doesn't add any security that's relevant to the receiver of an email, contrary to popular belief. (We'll talk more about SPF later.)

To understand how phishing works, we'll need to know a bit about email. An email message contains three parts: the envelope, the headers, and the content.

• The envelope is the outermost layer. It describes exactly where the message came from and where it will go. None of this information is ever available to the reader.
• The headers contain metadata describing who the email came from, who the email is for, and how it got to where it is. Sometimes it also contains authentication data. The To, From, and Subject fields that a reader sees correspond to identically named headers.
• The content contains the text of the email, along with any styling and attachments.

You may already be noticing some unnecessary redundancy. There are several fields that describe who an email came from:

• Envelope sender: This is the only one that's required. The reader never sees it. It's also the only one that SPF attempts to verify.
• "From" header: This is typically what the reader sees.
• "Reply-To" header: If the reader attempts to reply, their new email will use the address from this header.
• "Sender" header: Almost identical in purpose to the "From" header, but the reader never sees it.
• "Return-Path" header: If there's an error delivering the message, the address in this header will receive the error notification.

Similarly, there are multiple fields that describe who the recipient is:

• Envelope receiver: This is the only one that's required. The reader never sees it. It tells the receiving server exactly which mailbox to deliver the message to.
• "To" header: This is typically what the reader sees. It describes the intended recipient, but not necessarily the ultimate recipient. For example, if an email is sent to a group or mailing list, the "To" header will have the common address; however, the envelope receiver will have the address of the individual person that is to receive this particular copy of the message.

The obvious issue here is that the addresses the user sees and the addresses that are actually used can be completely different.

Since people first realized this was a problem, there have been multiple attempts to add security to email, with the most notable being:

• SPF
• SPF2
• DomainKeys
• DKIM
• DMARC

SPF2 and DomainKeys never saw widespread use, so we'll skip those.

SPF uses DNS to validate the envelope sender of an email. If I were to send an email with an envelope from [email protected], the receiving mail server would look for a specially formatted DNS record at example.com; if found, the record would contain a whitelist of servers allowed to send emails from example.com. This doesn't do any good because the envelope sender is never shown to the user, so the whole system is mostly pointless.

DKIM, the successor to DomainKeys, uses a form of encryption to "sign" an email and most of its headers. Like SPF, it uses a special DNS record to store information. Instead of acting as a server whitelist, though, the record contains a key. The key, the signature, and the email will fit together like a puzzle if the message is authentic. If the pieces don't fit, then the receiving server knows that the email is either forged or has been tampered with. DKIM has one major problem: while it does allow a receiving mail server to verify a message with a DKIM signature, a message without a signature can neither be verified nor proven inauthentic: there's no way for the receiving mail server to know for sure that the message should have come with a signature.

Both SPF and DKIM are in widespread use. They help mitigate some spam and phishing emails, but they don't completely solve the problem.

This is where DMARC comes in. DMARC also uses a special DNS record. This record allows a domain owner to say that messages that do not pass either SPF or DKIM should be declined and/or reported to a certain address. Additionally, DMARC specifies that SPF must be applied to the "From" header, which contains the email address the reader sees.

Great, so we've solved the problem, right? Not quite. Very few website operators are aware of DMARC; even fewer commit to enabling it. Let's take a look at some popular domaining websites to see if they use DMARC:

• GoDaddy: No; the necessary DNS record exists, but it's set to allow emails that fail DMARC
• Uniregistry: No
• NameCheap: No; looks like they attempted to configure it at one point
• Dynadot: No
• eNom: No
• Sedo: No
• Flippa: No
• Escrow.com: No
• NamePros: Yes

Our industry is pretty far behind. Here are some websites outside the domaining world for comparison:

• PayPal: Yes
• Google: Yes
• Facebook: Yes
• Amazon: Yes
• Yahoo: Yes
• Twitter: Yes
• Visa: Yes

Let's demonstrate why this is a problem. Here is an email I just sent to myself using a special script:



Yes, that really says [email protected]. It's not an IDN or anything like that. GoDaddy uses SPF, but it was irrelevant for this email because the envelope sender did not have a godaddy.com address. Do you see any indication that the envelope sender was something other than [email protected]? I don't, even in the details:



For those of you who think Mac is more secure:




Looks about the same to me.

It's worth noting that GoDaddy does have a DMARC record. Here's the contents of the TXT record for _dmarc.godaddy.com, with a little censoring to stop the spambots:
See that p=none bit? That means if an email fails DMARC, the message should be accepted anyway. In other words, this DMARC record is mostly useless, aside from the fact that it will send a notice to GoDaddy that there was a failure. p stands for policy; none means "do nothing."

Here's what _dmarc.namepros.com looks like:
This one has p=reject and sp=reject. sp stands for subdomain policy; reject means that if a message fails DMARC validation, it should be rejected. pct=100 indicates that these policies should be applied to 100% of messages. This will make for a strong defense against the type of email pictured above.

So, what does this mean for you?

• Don't use your hosting provider's email service; most don't support DMARC validation. Use something like Google Apps instead.
• Use a tool like dmarcian to analyze a website's DMARC policy (or lack thereof). At minimum, you want to see p set to something other than none and pct set to 100 or omitted. Ideally, sp should also be set to something other than none.
• Complain to any websites you use that don't have functional DMARC policies.
• If the sender of an email does not have a functional DMARC record, or if your email provider doesn't support DMARC validation, do not trust the email even if the domain matches perfectly.

In general:

• Don't click anything in an email you're not expecting. This includes emails from friends; often viruses spread by sending emails as the user they've compromised.
• Avoid collaborating via email. Use something more secure, like Slack.
• Don't email files to yourself or other people. Email was designed for text, not files. Use a service such a Dropbox or Google Drive instead.
• If you receive a scary email, don't panic. Stop and think: is someone trying to use your emotions against you? Don't forego your normal precautions.
• If you receive a questionable email from someone you know, respond to ask if the email is actually from them. There's a trick here: as soon as you start the reply, delete the email address that's automatically added to the "To" field and manually type their email address. Alternatively, contact them via some other communication channel.

Next: How To Avoid Domain Theft - Part 3: Managing Personal Information