Come fly with me, let's fly, let's fly a mail

With e-mail spoofing an increasingly common threat, how can you help prevent yourself being impersonated? You’re sat at your desk, and you receive an email from one of your clients “Thanks for letting us know of the updated bank details - we’ve made the transfer to the new address.” They’re replying to an email that you supposedly sent them this morning, but that definitely didn’t happen. And you certainly haven’t updated the bank details for invoice payment. You’ve warned your contacts to watch out for fake emails, so you inspect the original email. The “from” address is indeed from your email address me@mycompany.com. It looks exactly like every other email you might send to your clients. A scammer has sent a fake message impersonating you, and made off with a tidy sum of money. But how did this happen? Did I get hacked? Surely if an email says it’s from my address, then it’s actually from my address? Unfortunately not. You see, when we receive emails, all we can really tell about who they are and what they contain is what they tell us themselves. So if any email from any sender says it’s from me@mycompany.com, there’s nothing within the email that will allow the recipient to check if that’s true or not. We seem to have a pretty big problem - anyone can send emails pretending to be me! Indeed, this is turning into a common story for businesses. As CFC Underwriting revealed, Funds Transfer Fraud (which includes this sort of mail spoofing) accounts for around a quarter of cyber claims. And in the US, incidences of these claims rose by 92% last year. Email scams are prevalent, and only seem to be growing. So can I trust anything?! Thankfully, there are protections we can put in place to protect ourselves: either from appearing to send fake emails, or from unknowingly receiving them. Unfortunately the world of email isn’t always the most accessible, and can confuse even the best of us. So I’m going to play out the scenario in the world of air travel (as anyone who knows me also knows of my anorakish enthusiasm for planes!). How might Los Angeles airport know a plane coming in to land is genuine? We can imagine the situation of the operations manager at Los Angeles International LAX (let’s call her Fiona). Planes arrive at LAX from all over the world, and making sure those incoming flights are verified & secure is critical to the safe operation of her airport business. One day, Oceanic Airlines flight 815 is coming in to land from Sydney Airport (SYD). At least, it says it’s an Oceanic plane. Asking the pilot of the plane won’t do any good to check - they can just repeat that they are flight Oceanic Airlines flight 815. We’re back in the tricky situation we were in earlier. However, Fiona has an idea. “I’ll ask Oceanic Airlines where real Oceanic planes come from!” Thankfully Oceanic have a public statement on their website that says “Planes that depart from Sydney Airport (SYD) are real Oceanic planes. Planes that depart from any other origin are definitely not real Oceanic planes.” Having seen this, Fiona knows the inbound flight is actually an Oceanic - as she can see it took off from SYD. She therefore decides to let the plane land and taxi as normal. In the land of email, that public statement from Oceanic is called SPF¹. It’s a statement that companies can publicly post (on their internet infrastructure) that says “Emails that depart from Server A are real emails from this website. Emails that depart from any other server are definitely not real emails from this website.” What if the plane comes from somewhere else? The next day, another flight is on approach claiming to be an Oceanic plane. Checking its origin, Fiona sees that it took off from Auckland Airport. Again, she checks the Oceanic public SPF statement, and it’s the same as yesterday. Real Oceanic planes don’t come from Auckland Airport. Realising that the plane fails the test against this SPF statement, Fiona has to decide what to do. Does she:

1. Deny the plane landing permissions so it never touches down at LAX?
2. Let the plane land, but assign it to a special holding hangar, or make a warning announcement to the terminal that it could be fake?
3. Let the plane land & taxi as normal, but just let Oceanic know that a plane arrived from Auckland claiming to be one of theirs?

Again, Fiona can ask Oceanic what to do “If I’ve got a plane that isn’t a real Oceanic plane according to your SPF (it didn’t come from Sydney), what should I do with it?” And Oceanic (rather than responding individually to every airport operations manager who asks) publish their answer, which is “If a plane fails the test against our SPF statement, you should deny it from landing, and let us know, by sending an email to this dedicated address.” Deciding what to do - with senders setting a policy of how receivers should treat planes (emails) that fail our tests - is what we call DMARC². Depending on the sender’s DMARC policy, your email provider will decide to either:

1. Reject emails that fail the SPF test
2. Quarantine those emails: route them to an admin to inspect, or put them in your spam/junk folder, or display a warning to you that they came from somewhere suspicious
3. Let all the emails through, sending a notification to the sending domain that they failed SPF tests

Unfortunately in the land of email, if the sender hasn’t published a DMARC policy, all those emails are likely to arrive as normal. And if the sender hasn’t also published their SPF statement, there’s no way for you to confirm that those emails are genuine. Just like Fiona might have been confused and let all of the planes land if Oceanic hadn’t published their policies, email providers will likely show emails to recipients if senders haven’t published their SPF & DMARC. Just like the planes arriving at LAX, verifying authenticity requires action from both the sender and recipient. But with public SPF statements, and DMARC policies to check those statements, Fiona knows what to do with planes that claim to be Oceanic flights, and your email provider knows what to do with emails that appear to be from your accountant.

Why might Oceanic want spoofed planes to arrive as normal?

As a side note - setting this DMARC policy does run the risk that some real Oceanic Airline planes might be rejected from landing. For instance, if some Oceanic planes operate out of Perth, or divert via Melbourne, and this isn’t covered in the SPF statement, then a stringent DMARC policy would mean lots of Oceanic planes being denied landing, or being quarantined. As a result, Oceanic may deliberately set their DMARC policy so that airports don’t take any action when their planes fail the SPF validation. But of course, the more robust solution for Oceanic Airlines would be to update their SPF statement to say “Planes that arrive from Sydney Airport (SYD), Perth Airport (PER), or Melbourne Airport (MEL) are real Oceanic planes. Planes that arrive from any other origin are definitely not real Oceanic planes.” This would allow those diverted and alternate flights to land correctly, while minimising the risk of Oceanic Airlines flights being spoofed.

Similarly, some organisations may choose to implement laxer DMARC policies (especially if they’re using external mailing services which send emails from different servers) so that they don’t run the risk of legitimate emails being rejected. While this does maximise deliverability, it does leave these organisations open to being spoofed. The more robust solution is to properly add these servers/domains as legitimate senders in the SPF statement, and implement stronger DMARC policies - to maintain deliverability of emails while minimising the risk of being spoofed.

That’s all well and good, but how do I know the cargo hasn’t been changed? From the Oceanic statements, Fiona can know if any given plane is really an Oceanic plane, and what to do if it appears it isn’t. But it won’t help her check if the plane’s cargo and passengers have been changed between Sydney and Los Angeles. Similarly, SPF (and a DMARC policy to take action if SPF checks fail) will confirm that an email is really from the address it says it’s from. But it won’t help us check that the message hasn’t been changed by an attacker at some point between the sender and the recipient. Often hackers intercept an email after it’s sent, and change the message before it’s delivered to the recipient – e.g. changing the bank details you just sent to your client! Seems we’re back to square one… unless there’s a way to seal the delivery? For the Oceanic plane landing at LAX, the ground staff at SYD could maybe use some special tape on the cargo and cabin doors. If anyone tries to change even the tiniest thing about the flight, the tape will tear, and show clearly that the plane’s contents have been tampered with since it left Sydney. And if Oceanic make their tape so unique that no one else in the world could replicate it, any tear would be irreparable & obvious to the recipient. So any would-be smuggler couldn’t get into or out of the plane without tearing the tape, and making their interference obvious to Fiona when the plane lands. Similarly, there’s a way to wrap emails, called DKIM³. When someone sends an email, their provider can place it in a digital cargo box, so that if the email contents are changed (even in the slightest), the recipient can immediately see that it’s been interfered with. With DKIM, we know that the message hasn’t changed since the sender sent it. Recipients will still need to decide what to do when they see an email with an altered message, just like Fiona will need to decide what to do with a plane with altered cargo. Again, this is where our DMARC policy comes in - based on the sender’s policy, the recipient can reject, quarantine, or just report these emails. Towards safer skies In our analogy, proving a plane’s integrity when landing at LAX requires Oceanic Airlines to use SPF to show that it’s really an Oceanic plane, and DKIM to show that its cargo & passengers haven’t changed since takeoff. A DMARC policy from Oceanic would inform Fiona at LAX of the actions they should take based on the outcome of these tests. Then Fiona can check for those proofs and follow the DMARC policy when the plane or its cargo fail the verifications. Similarly, mail security will only improve when senders set up verifications for the email they are sending into the world, and inform receivers how to treat those emails if they don’t pass verification. But if you had SPF & DKIM implemented properly, with an effective DMARC policy, your client would be able to verify if that email really was from me@mycompany.com, and if anyone had changed the message. Email security the KYND way At KYND, we make these and loads of other cyber risks simple to understand, quick to monitor and easy to prevent. With a simple product that speaks your language, just enter your website name, and we do the rest. To speak to a KYND person, and see a demo of what KYND can do for your business, get in touch. As a freebie, we’ve created the KYND email analyser add-on for Gmail. You can use it to check the SPF, DKIM & DMARC status of emails you receive, and the SPF & DMARC settings of your own domain. Just add it on to your Gmail sidebar, and we’ll let you know what anti-spoofing settings are in place, and what they mean. We hope this is helpful! Tune in next time, where we’ll be giving the KYND treatment to more cyber risk essentials. Until then, safe emailing!

---

1. Sender Policy Framework
2. Domain-based Message Authentication, Reporting and Conformance
3. DomainKeys Identified Mail