Stopping Forged Email 4: Your Last Resorts
In previous posts we have examined how hackers and spammers can send forged email and how it can be extremely difficult to differentiate these messages from legitimate messages. We have looked at the various common techniques for anti-fraud such as SPF, DKIM, and DMARC and seen that, while these technologies can help a lot, they all have limitations; they all require strict and proper setup by the owner of the purported sender’s domain, and they must be well supported by your own spam filtering system.
Yet even with these technologies, it’s not hard in many cases for a determined attacker to send you a forged, fraudulent email message that still looks and feels legitimate.
What else can you do to validate email messages and protect yourself from phishing or social engineering attacks?
Simple Email Inspection Techniques
These simple techniques can empower you to identify many types of fraudulent email by yourself, without relying on any external filters or systems. Knowing what to look for can help you identify many of the common attack schemes.
Always show the “From” email address
The “From” line of a message can be made up of two parts: an email address, and a title which usually contains some bit of identifying information about the purported sender, such as their full name, job title, or company. When viewing a message, many email programs will often hide the email address portion of the “From” line by default and display the title by itself. However, the title can be arbitrary text and therefore is not a good indication of whether the message is legitimate or not. For instance, while the title may reference some person you know (e.g. John Smith), the email address may be more indicative of the true nature of the message (e.g. no-reply@buy-my-junk.com).
Configuring your program to show the actual email address in the “From” line will let you see what your SPF, DKIM, and DMARC alignment tests are actually looking at. If the email address or domain does not match the message content, you should be very wary.
Be aware of the Javascript capabilities of your email program
Most email messages function like complex web pages. They can contain or include arbitrary JavaScript programs that can do almost anything to the message content you’re looking at, such as obfuscate the true location that URLs link to.
Many WebMail programs greatly limit the use of JavaScript unless you view the message HTML body in its own window. In those cases, the “new window” allows you to see the HTML in its full JavaScript-and-CSS-laden glory. Individual email programs will have varied JavaScript capabilities, so be aware of the JavaScript context of the one you use. Does it block all JavaScript? Does opening a message in its own window allow all JavaScript? If you do not know and cannot find out, then you cannot trust anything about the message content (with the exception of the raw message source).
Be careful where you click!
One of the most common phishing tricks is for a message to look completely legitimate so as to entice you to click on a link or image that looks benign; it may warn you to perform some needed action or urge you to look at some important web site. But the kicker is that the link or image may not actually direct you to the web page that it indicates.
Hovering over the link may give you a tool tip containing the web site address in the link; however, if JavaScript is enabled, this may not be reliable. Similarly, if you right-click the link and copy the web site address, that may also be unreliable if JavaScript is running the show. In short, with JavaScript active, you cannot know where a clicked link or image will send you without opening and examining the message source with a very trained eye.
If the link or image is promising to take you to a web site you’re familiar with, the absolute safest thing you can do is open your web browser and navigate to that site yourself rather than using the links provided in the email message.
Look for anomalies
Look for things that do not match what you would expect from similar messages. Broken or incorrect images, poor grammar, requests for personal or private information, or requests that violate an organization’s policies or history are all red flags. If you are ever unsure, just call the company and ask.
Click Protection
If you have a capable spam filter, it can auto-detect all web site URLs in an email message and:
- Scan those URLS for malware or phishing information and auto-block them
- Replace the URLs with new ones that redirect through your filters and track the clicks
- Scan the URLs again when you click through (as often times, the malware is placed on sites later, after the phishing message is sent).
- Allow administrators to add policies controlling and monitoring click-throughs
Click protection can prevent you from going to malicious sites, though again, if JavaScript is in full swing, an attacker can easily avoid click protection methods.
Digital Signatures with PGP or S/MIME
Use of PGP or S/MIME in a sender’s email program allows the sender to digitally sign (and encrypt) the body of a message with their own “key”. As a recipient, you can then verify this signature and be sure that it was really sent by the person with that PGP or S/MIME key (and also confirm that it was not modified in transit).
This is a lot like using DKIM to verify the sender. It’s better than DKIM in that it’s insusceptible to inter-domain forgery and same-email-provider attacks, but it requires more work to setup. In a nutshell, the recipient and the sender must both be set up to use the same PGP or S/MIME technology, and the recipient must already have the sender’s public key (or be able to look it up) in order to validate the digital signature.
Read more details on PGP and S/MIME: The Case for Email Security.
PGP and S/MIME, if in use, provide a great way to “absolutely” ensure sender identity (that is, assuming the sender’s key hasn’t been compromised, and their computer hasn’t been stolen). S/MIME functionality is built into most email sending programs these days and into some WebMail interfaces as well. PGP can be added as a plugin (free or paid, as the case may be) to many email programs.
Regarding the sharing of public keys, PGP incorporates “key servers” that can be used for the storage and retrieval of such keys (as long as you trust them). S/MIME does not currently have a global key library, however the DIRECT Protect is working towards a scheme where S/MIME keys can be published in DNS. This will make them easily searchable and much more trustworthy. Finally, many secure email providers handle the key distribution automatically for you, such that everyone using that provider can automatically see everyone’s keys.
For cases where the circle of people communicating is well defined and can be on the same page, use of PGP or S/MIME is one of the best ways to ensure both encryption and identity on top of email.
Password / Secure Portal Access
In scenarios where one must login to a web portal (or App) first, then send the message, and where the message is logged in that portal for the recipient to see, we have a very strong automatic validation of identity. There is no way that the message could have been sent by anyone that does not have the sender’s login credentials to the portal.
For this very reason, many support and help desk systems only allow you to ask questions and request help after you have logged into a portal and only when using their support ticket interface. This provides validation of your identity and thus also your authorization to make requests. Inbound email messages are not a good vehicle for this at all.
Similarly, Secure Email systems where the message is signed, encrypted, and stored in a server-side database provide excellent sender verification (and can also provide good authentication on the recipient when s/he seeks to open it). The recipient opens the actual message by going to a secured web portal where the message is retrieved, decrypted, and verified. There is no chance for an attacker to intercept or modify that interaction (without setting up a fake secure email pickup web interface).
What about SMTP TLS?
With all the buzz about SMTP TLS and the trend for all companies to enable TLS on their email systems so that messages can be encrypted in transport, one might think that TLS helps with identity.
Unfortunately, it does not. TLS establishes a secure tunnel between the sending server and the recipient server to help prevent eavesdropping on the communications, but it does nothing to assist with sender identity verification or with ensuring the right recipient receives the message.
Ok — So What Should I Do?
There are a number of things that you should do to best protect yourself and your organization:
- Enable SPF, DKIM (and DMARC) on your domains, as strictly as possible
- Ensure that your email filtering software pays attention to SPF, DKIM, and (eventually) DMARC information to filter out obvious fraud.
- Keep your guard up! Look for message anomalies, be wary of links in emails, and know the JavaScript capabilities of the email program you use.
- Do not use unsigned email messages in your company for support and help desk requests. Always use a ticketing system that requires a login to access.
- Use S/MIME, PGP, or a Secure Message Pickup system when communicating with a group of people where those communications should be always identity verified (and maybe secure too).
- Use a closed system where only people on the system can send and receive messages to each other, and where both encryption and identity are baked in. This is generally not “email as you know it.” On example of such a system is LuxSci SecureChat.
Even the most security-minded among us can be targeted by determined attackers and compromised these days. So, while it is impossible to get it all right, we can be proactive, vigilant, and adhere to best practices, while staying on top of the changes periodically being swept in on the tide of technology.
Read Next: Email Identity Protection and LuxSci Email Hosting.
