Overview of email security

Introduction

Email remains a primary channel for exchanging information. However, the convenience of email also opens doors to potential security threats. To address these concerns, the email industry has developed a series of protocols and authentication techniques to ensure the authenticity, integrity, and security of email messages. In this article, we will dive into SMTP protocol security and explore the key authentication techniques.

What does email security relate to?

Human

While technology plays a pivotal role in this domain, the human element remains a critical aspect of ensuring the effectiveness of email security measures.

It will always be hard for human to identify phishing attacks, avoid clicking on the beautiful link, or not to open the attachment.

Of course, we have to educate people, but we also have to make sure that the technology is there to help them. We can't expect people to dodge a phishing mail if it's send from a legitime domain. That's why, we have to maximize the protection against domain spoofing attacks.

SMTP protocol

Simple Mail Transfer Protocol (SMTP) is the backbone of email communication. While its primary function is to route and deliver emails, SMTP security is paramount to prevent abuse and unauthorized access. Here's how SMTP security works:

According to the RFC 788, the SMTP protocol is a set of rules that govern the exchange of emails between servers. It defines how emails should be formatted, transmitted, and delivered. SMTP is a text-based protocol that uses ASCII characters to communicate between servers. It uses TCP port 25 by default.

SMTP protocole simply relay MIME (Multipurpose Internet Mail Extensions) messages between servers. It means that SMTP is not responsible for the content of the message, but only for the transmission of the message.

> As you can notice, at the start, SMTP protocol didn't support authentication nor encryption.

The need of authentication

Good to know: Originally, SMTP servers were typically internal to an organization, receiving mail for the organization from the outside, and relaying messages from the organization to the outside. But as time went on, SMTP servers (mail transfer agents), in practice, were expanding their roles to become message submission agents for Mail user agents, some of which were now relaying mail from the outside of an organization. (e.g. a company executive wishes to send email while on a trip using the corporate SMTP server.) This issue, a consequence of the rapid expansion and popularity of the World Wide Web, meant that SMTP had to include specific rules and methods for relaying mail and authenticating users to prevent abuses such as relaying of unsolicited email (spam).

As described in the RFC 2554, the SMTP protocol was extended to support authentication. However, we talk about SMTP authentication between a client and a server. It means that the client has to authenticate itself to the server. At this step, there is still any authentication process between 2 servers.

As you can imagine, is impossible to provide authentication between servers, because they don't have to know each other at the start, and can proove that they are legitimate when connecting. Skipping TLS, they is no way to secure communication between server, that why we created some security measures over the SMTP protocol itself.

Security layers added to SMTP protocol

While RFC 2554 focuses on client-server authentication, it's worth noting that there are other protocols and mechanisms, such as TLS (Transport Layer Security), DKIM (DomainKeys Identified Mail), and SPF (Sender Policy Framework), that address security concerns between servers in the email infrastructure. These mechanisms enhance the overall security and integrity of email communications by establishing secure connections, verifying sender domains, and preventing email spoofing. Let's discover them!

DKIM

DKIM stand for Domain-Keys Identified Mail. DKIM is an email authentication technique that verifies the legitimacy of the sender's domain. Here's how DKIM works:

DKIM involves adding a digital signature to outgoing emails. The sender's domain generates a cryptographic signature and adds it to the email header. The recipient's server can then verify the signature using the sender's public key published in the DNS records of the domain. If the signature is valid, it confirms that the email content hasn't been altered in transit and originates from the claimed domain.

Adding a DKIM signature to outgoing emails is a simple process that can be automated using an email service provider. You only need to generate your keys (RSA or ECDSA), publish your public key in your DNS records, and add the DKIM signature to your emails.

You can find a lot of articles covering this subjects on the web.

SPF

SPF stand for Sender Policy Framework. SPF is an email authentication method that helps prevent email spoofing. It works by specifying which IP addresses are authorized to send emails on behalf of a domain. Here's how SPF works:

The domain owner publishes SPF records in their DNS. When an email is received, the recipient's server checks the SPF record of the sender's domain to see if the sending IP address is authorized. If the sending IP isn't listed in the SPF record, the email may be treated as suspicious or fraudulent.

As you can understand, SPF is like a whitelist of IP addresses authorized to send emails on behalf of a domain. It's a simple and effective way to prevent email spoofing.

DMARC

DMARC stand for Domain-based Message Authentication, Reporting, and Conformance. DMARC builds upon DKIM and SPF to provide a comprehensive framework for email authentication and reporting. Here's how DMARC enhances email security:

Policy Enforcement: DMARC allows domain owners to define a policy for how emails failing authentication should be handled. They can choose to monitor, quarantine, or reject such emails.

Reporting: DMARC generates detailed reports on email authentication results, allowing domain owners to gain insights into how their domain is being used for email communication.

Note: It's only effective when used in conjunction with other email security measures, such as DKIM and SPF. DMARC is becoming a requirement in many security standard, like PCI-DSS.

BIMI

BIMI stand for Brand Indicators for Message Identification. BIMI is a newer authentication technique that aims to enhance email security and brand visibility. Here's how BIMI works:

BIMI allows organizations to display their official logo in the recipient's email client when certain authentication criteria (such as DMARC alignment) are met. This provides recipients with a visual indicator that the email is from a legitimate source.

BIMI is simply a record in the DNS of the domain. It's a TXT record that contains the URL of the logo of your brand. You can self-assert your brand logo, meaning that you publish your logo without it being verified as belonging to your domain. The only requirement for self-asserted BIMI logos is that they be in SVG P/S format. If you left the “a=” attribute blank in the BIMI record, you’ve published a self-asserted logo.

Some mailbox providers accept self-asserted BIMI records today (e.g. Yahoo!, AOL, and Netscape) and may begin to display the logo on qualified messages. Some mailbox providers (e.g. Gmail), however, do not accept a self-asserted BIMI record and require that the logo be “certified” as being associated with a specific company and domain.

How to setup your domain security

Adding records to your domain

All viewed security layers can be added to your domain using TXT records.

SPF records

To add an SPF record to your domain, you can simply add the following (place it on the root of your domain):

v=spf1 a mx ip4:192.168.1.0/24 include:_spf.example.com -all

• v=spf1 indicates the version of the SPF protocol being used.
• a allows the domain's A records (IPv4 addresses) to send emails.
• mx allows the domain's MX records (mail servers) to send emails.
• ip4:192.168.1.0/24 allows the specified IPv4 address range (CIDR notation) to send emails.
• include:\_spf.example.com includes the SPF record of another domain (_spf.example.com) as an authorized sender.
• -all indicates a "fail" result for all other sources. This means that if the sending IP does not match any of the authorized sources, the email should be rejected.

As you noticed, we use here -all flags that is strict. For testing purposes, you may want to use: ~all The tilde (~) followed by all indicates a "soft fail" result. This means that if the sending IP does not match any of the authorized sources specified in the SPF record, the email will not be immediately rejected. Instead, the receiving mail server may mark the email as suspicious or treat it with caution, possibly placing it in the recipient's spam or quarantine folder.

DKIM records

To set up DKIM for your domain, follow these steps:

Step 1: Generating DKIM Keys Choose a Method: There are different ways to generate DKIM keys. Here, we'll cover two options: an easy method and a more secure one.

• Easy Method: You can use an online DKIM key generator tool to quickly create DKIM keys. Simply search for "DKIM key generator" online, and you'll find several user-friendly options.

• More Secure Method: For a more secure approach, it's recommended to generate DKIM keys using your mail server software or a command-line tool. Check your email server's documentation for specific instructions on generating DKIM keys.

Step 2: Adding DKIM Records to DNS Once you have your DKIM keys, you need to add DKIM records to your DNS (Domain Name System). These records are public keys that receiving email servers will use to verify your emails.

Retrieve DKIM Records: Your DKIM key generation method will provide you with two important pieces of information:

• Selector: This is a unique identifier for your DKIM key, usually in the form of a text string like "selector1."
• Public Key: This is a long string of characters that represents your DKIM public key.

Create DNS Records: Log in to your domain's DNS management panel (often provided by your domain registrar or hosting provider). Then, create DNS TXT records for DKIM using the following format:

selector.\_domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=<your_public_key>"

Replace selector with your specific selector, yourdomain.com with your domain name, and <your_public_key> with the actual public key provided by your DKIM key generator.

Publish Records: Save the DNS records, and they will be published to the DNS server. It may take some time for these records to propagate across the internet, so be patient.

Step 3: Enabling DKIM on Your Mail Server To complete the setup, you need to enable DKIM signing on your email server using the private key corresponding to the public key you just published in DNS. Refer to your email server's documentation for instructions on how to configure DKIM signing.

Additional Information Testing: After setting up DKIM, it's essential to test it thoroughly. Send test emails to various email providers and use online DKIM validation tools to ensure that your DKIM signatures are working correctly.

DMARC records

We can now add a DMARC records (place it in the subdomain: _dmarc):

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; sp

• v=DMARC1 indicates the version of the DMARC protocol being used.
• p=reject specifies the policy action to take if an email fails DMARC checks.
• rua=mailto:dmarc@example.com indicates the email address to which aggregate DMARC reports will be sent.
• ruf=mailto:dmarc@example.com indicates the email address to which forensic DMARC reports will be sent.
• sp specifies that only SPF alignment should be evaluated for DMARC. This means that DMARC alignment and checks are based solely on SPF authentication results.

In the following example, we used p=reject, this means that if the email fails DMARC checks it will be totally rejected and not delivred. Consider starting using p=none for development, and when you think you're ready p=quarantine is the way to try the configuration and improve you're DMARC check before switching to p=reject.

BIMI records

BIMI (Brand Indicators for Message Identification)

Setting up BIMI, especially using self-signed certificates, involves a few steps:

Step 1: Create a BIMI-Ready Logo Before setting up BIMI, you need a logo that adheres to specific guidelines. The logo should be in SVG (Scalable Vector Graphics) format and meet the recommended size and aspect ratio. Typically, the logo should be square and have a transparent background. Ensure that the logo represents your brand accurately.

Step 2: Generate a Self-Signed Certificate To set up BIMI with a self-signed certificate, you'll need to create a certificate for your domain. This certificate is used to sign your logo and validate its authenticity. You can generate a self-signed certificate using open-source tools like OpenSSL.

Here's a simplified guide to generate a self-signed certificate with OpenSSL:

openssl req -x509 -nodes -newkey rsa:2048 -keyout yourdomain.key -out yourdomain.crt -days 365

Replace yourdomain.key with the name of your private key file and yourdomain.crt with the name of your self-signed certificate file. Keep your private key secure since it will be used to sign your BIMI assertion. Store it in a safe location with limited access.

Step 3: Create a BIMI Assertion A BIMI assertion is a DNS TXT record that provides information about your logo and the location of your self-signed certificate. Create a BIMI assertion by adding the following TXT record to your domain's DNS:

default._bimi.yourdomain.com. IN TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=yourdomain.crt"

Replace yourdomain.com with your actual domain, and ensure that the URLs are accurate and point to your logo (in SVG format) and self-signed certificate.

Step 4: Enable BIMI on Your Email Server To enable BIMI on your email server, you'll need to configure it to include the BIMI header in your outgoing emails. The exact steps for this configuration depend on your email server software. Refer to your email server's documentation for instructions on enabling BIMI.

What about non-emailing domain ?

You probably have a domain that you use, but you will never send email from it. The best way to handle it is to create a record that reject all emails emitted from the domain.

To do it, you can simply add this SPF record to the domain you never use for mailing:

v=spf1 -all

This is really important if your company own multiple domains. By blocking all emails from the domain you don't use, you prevent attackers to spoof your domain and send emails from it. Don't forget that domain is know of your employes and if they receive a mail from it, they will probably trust it...

How to test your email domain security

During my whole research about email domain security, I decided to develop an open-source tool to easily craft email and test domain security named Gosurp.

Visit Gosurp at https://leofvo.github.io/gosurp/.

Gosurp allow you to quickly test your email security by checking your domain records configuration and craft handmaid payload to test usurpation on it.

For example, you can query your domain's records using:

gosurp inspect domain <yourdomain.com>

Craft and try your payload locally:

# Start you local SMTP server
gosurp smtp listen --hostname localhost --port 2525 -vvv

# And then you can try to send payload on your local SMTP server from a second shell
gosurp smtp send -vvv --from attacker@fsociety.local --to victim@localhost --port 2525

Have fun!

Conclusion

In an era where cyber threats continue to evolve, ensuring the security of email communication is crucial. By implementing protocols like SMTP encryption and authentication, along with advanced techniques like DKIM, DMARC, SPF, and BIMI, organizations and individuals can significantly reduce the risk of email-based attacks, such as phishing and spoofing.

There are multiple mechanism to secure email communication, neverless be sure to use a good SMTP server that support all of them.

It's hard to counter or predict human behavior, but we can make sure that the technology is there to help them, we have to.