How adding digital signatures (DKIM+DMARC) to your organization’s emails might be the easiest thing you can do to prevent an attack

Email is just like a letter from your grandma.

Note – This is an oversimplified guide to just one concept of email security. There are much more secure and advanced methods for ensuring confidentiality and integrity than DKIM available for implementation. 

Many people fail to understand how utterly insecure the email standard is by default. The best way to understand email security is to compare it to a USPS First Class Mail Letter. 

A sample USPS letter

As you see above, I’ve addressed a letter to the president with my return name and address on the envelope. When this letter reaches the White House and to Obama’s desk, he’ll know immediately that it came from Montel in Chicago.

But, what if I was feeling a little bit malicious and I wanted to say a few not nice things to Mr. Obama pretending to be someone else? I could simply put someone else’s name in the return address.

A malicious sample letter

Now, when this letter reaches Obama’s desk at the White House, Obama would see this letter is from Mr. Trump and perhaps grant it a little bit more importance.

You see, by default, there’s nothing necessarily ensuring that any mail we receive is authentic and we never think much of it because  we rely on obvious things like knowing the person’s tone or unique words our signatures our senders use. But what if someone was really motivated and did some social engineering? Things could go downhill pretty quick.

The From: Attribute in Email

Like letters, Email has a return address as well. Or technically, the “from” and “reply-to” attributes. Look below at the following header (raw source code of email) from a sample message I received from Amazon support.

This raw data that my server received, says this message is from “ Customer Service <[email protected]>” But just like letters, this From: address can easily be changed to appear from another email address. Someone could do the following attack-

  1. Fire up an SMTP server (Using any computer, or commonly an already hacked server)
  2. Use social engineering and craft a nice, professional sounding email  with the subject “New Sale!!  Headphones Discounted to 60% off!” with a fake web link to the hacker’s server crafted to look like the Amazon login page.
  3. Now that I’m on this familiar looking page, I proceeded to sign in with my Amazon account info and the web page just returns a 404 perhaps. I shrug and disregard the email.

Jackpot. The hacker now has my Amazon account info and can order lots of things from my account and have it shipped to him.

Now obviously Amazon is a smart company has mechanisms to prevent this from actually causing damage, like asking for your payment card information when shipping to a new address, or perhaps flagging your account when logging in from a foreign IP address.. so it’s really not that big of a deal.

Your company.

The real threat is when the attacker is targeting individuals in an enterprise environment.

How easy would it be for  an attacker to spoof an email pretending to be your boss, asking you to click on a link to fill out an IT form to request a new laptop? You click on this link, and you’re presented with a web page asking you to login with your system credentials before submitting the form. Just like thatthe hacker now has access to your email, your contacts, your online storage, and anything else that is linked to your  network login credentials. Here’s a quick few things a hacker could do having access to your account.

  1. Send malicious mail (let’s throw a virus in there too!) to your entire organization, appearing this time as you, and having a higher rate of deliverability coming from an internal address.
  2. Send malicious mail to all your external clients.
  3. Have open access to your online storage. Depending on the individual, this could be things such as PII, health data, intellectual property or employee records.

And many more. This is almost exactly how the infamous Sony attack started.

DKIM and DMARC to the rescue

DKIM is a great, easy to implement technology that can ensure an email’s authenticity. Essentially, DKIM is a type of PKI that adds a short cryptographic signature to each message. This signature is verified against a key placed in DNS called a selector.

DKIM Authentication workflow
  1. Sending mail server attaches the DKIM signature to the header of the outbound mail
  2. Receiving mail server analyzes the DKIM signature, verifying it against DNS.
Amazon’s DKIM key and DMARC policy

DKIM is kinda pointless without DMARC, because DKIM by default doesn’t tell a server what to do with your email if it doesn’t contain the key.

DMARC  is a validation system living completely in DNS that instructs servers what to do with our DKIM failed messages.

capture’s DMARC policy

DMARC can be configured to send messages to spam (p=quarantine), completely reject them (p=reject), what percentage of these emails to reject, (pct=100) and where to send a daily digest of mail deliverability reports ([email protected])

With our DKIM keys in the email, and DMARC policy in DNS, we now are fully equipped to help thwart spoofed email coming from our domain.

One important thing to note is that with DKIM your emails are protected globally. This means not only will your internal emails be authenticated internally, but emails outbound to your clients, vendors, contacts etc will also be authenticated.  

How to – Implement DMARC and DKIM

Leave a Reply

Your email address will not be published.