-
Notifications
You must be signed in to change notification settings - Fork 58
Home
Email is an essential tool in modern communication, however, the underlying technology is often taken for granted. This lack of understanding can lead to serious security issues and unintended behavior of a company’s mail system such as email spoofing.
In this Wiki, we will delve into the world of email spoofing and how it can impact an organization's security. We will also introduce you to a tool called Spoofy, which is specifically designed to help identify and protect against email spoofing. To begin, we will explore the various components of the email system that is commonly used today and how small misconfigurations can lead to vulnerabilities. By understanding these potential weaknesses, we will then demonstrate how utilizing a tool like Spoofy can aid in identifying and addressing these issues before attackers can exploit them. Background To fully understand the significance of Spoofy, an email spoof checking tool, it is important to have a basic understanding of the underlying technology and concepts of email spoofing. In this section, we will provide a brief overview of the fundamental principles of email communication, as well as explain the concept of email spoofing and its potential consequences. This background information will serve as a foundation for understanding how Spoofy operates and the benefits it can provide in identifying and preventing email spoofing attacks.
The process of sending an email is similar to the process of sending mail via the US postal service. Companies set up a Simple Mail Transfer Protocol (SMTP) server, similar to a post office, to handle the influx of email messages going back and forth between a company's employees and other people in the world.
One of the big issues that affects not only physical mailboxes, but also SMTP servers is the ability to identify where the mail originated from. Anybody can write a letter, put it into the mailbox at the post office and ship it to the address of their choosing (so long as they have a stamp). In that regard, there becomes a large security problem that happens with the digital messages that we send back-and-forth. Without a great way to identify who sent the mail, we are clueless if the mail is legitimate or not. One security attack that uses this concept is called Email Spoofing.
Email spoofing is a type of cyber attack in which an attacker sends an email that appears to come from a legitimate server but actually comes from an attacker's server. When a successful spoof is combined with a phish, it can be difficult for even the most informed users and sysadmins to tell if email is legitimate. The attacker may use this technique in order to steal personal information or financial details, trick users into downloading malware, or gain access to confidential information. Most of the time attackers try to do this via phishing, which can often lead to a breach. In this blog post, we are going to cover the security measures that companies can use to secure their organizations mail servers, and prevent unauthorized mail from landing in your employees mailboxes.
Email security can primarily be broken down into three components, SPF, DMARC, and DKIM. As defined in the RFC, "Sender Policy Framework (SPF) protocol can be used to explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization."
Let's break that down:
SPF is a protocol that can be used to authorize hosts to use a specific domain of a receiving host. A good example of this would be for a company that utilizes greenhouse to send emails to candidates through their SaaS platform. To properly allow greenhouse to send emails to the candidates using the companies domain, an SPF record needs to be established that allows the 'greenhouse.com' domain to be included on the record. SPF records are published as a DNS TXT and can be easily found by performing the following command in terminal:
dig txt domain.com
If you dig the domain bishopfox.com for example, you'll see a SPF record where 'greenhouse.io' is being included. This allows greenhouse to send emails on behalf of the bishopfox.com domain. Pretty cool right!?
The chart below describes the different mechanisms that can be used in a domains SPF record:
| Mechanism | Description |
|---|---|
| v | SPF version (required) |
| ip4 & ip6 | Authorizes mail server by IPv4 or IPv6 address or address range |
| a | Authorizes mail servers by domain name |
| mx | Authorizes mail served by domain MX record |
| include | Authorizes 3rd party mail senders by domain |
| all | Specifies that all incoming messages match |
A valid SPF record requires only a few mechanisms, and their order is important. The "v" mechanism must be the first in the record, followed by any other mechanisms, and ending with the "all" mechanism. It's important to note that the "all" mechanism must be the last one in the record and multiple "all" mechanisms will result in only the first one being used and the rest ignored. This is a common mistake I have observed.
Additionally, the "all" mechanism in SPF is used to indicate what should happen when a message is received from a domain that is not listed in the SPF record as a valid sender.. The "all" mechanism can either be a soft fail or a hard fail:
- A soft fail (designated by the "~all" mechanism) indicates that the message should be accepted, but marked as potentially suspicious. This allows the email to be delivered to the recipient's inbox, but also gives them a warning that the message may not be legitimate. This is useful for domains that may have a valid SPF record but also send email from other sources that may not be authorized.
- A hard fail (designated by the "-all" mechanism) indicates that the message should be rejected outright. This is useful for domains that only send email from a specific set of authorized sources, and want to ensure that any other messages are not delivered.
- A neutral (designated by the "?all" mechanism) is far more spoofable than ~all. and is applied by default if an "all" mechanism is not specified.
It's important to note that while a hard fail with the "all" mechanism can be a more secure option, it can also lead to legitimate emails being rejected if the SPF record is not set up correctly.
The DomainKeys Identified Mail (DKIM) is a method for authenticating email messages. It allows the person receiving the email to check that it was actually sent by the domain it claims to be sent from, and that it hasn't been modified during transit.
When a message is sent using DKIM, a digital signature is added to the message headers. This signature is created using a private key, which is held by the sender. When the message is received, the recipient can use the public key, which is registered in the Domain Name System (DNS) of the domain, to verify the signature.
The recipient's mail server retrieves the public key from the DNS and uses it to decrypt the signature. If the decrypted signature matches the one in the message headers, the server knows that the email has not been tampered with, and that it was sent by the domain it claims to be sent from and it is more likely to be legitimate email.
The Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication protocol. SPF is primarily used in conjunction with DMARC acting as a whitelist of sorts that holds which hosts are allowed to send mail on a domain's behalf. The DMARC protocol's primary function is to authenticate sender IP addresses and tell receiving servers what to do with emails that don’t pass SPF or DKIM.
This is set up in the domain’s DMARC record, which contains a policy to either reject, quarantine, or do nothing with the mail. Specifically, the policies and descriptions are:
| Policy | Description |
|---|---|
| reject | This policy tells the receiving server to reject any email that fails SPF or DKIM checks and not to deliver it to the intended recipient. |
| quarantine | This policy tells the receiving server to mark the email as potentially suspicious and deliver it to the recipient's spam or junk folder. |
| none | This policy tells the receiving server to accept the email and deliver it to the intended recipient, even if it fails SPF or DKIM checks. |
However, the server will still collect and report the authentication data to the sender. |
By setting up a DMARC record and policy, the organization can protect its domain from unauthorized use and increase the likelihood that legitimate emails from the domain will be delivered to the intended recipients.
Using shared domain IPs in a SPF record can pose a number of risks to the security and integrity of an email system. One of the main dangers is that a shared IP address is used by multiple domains, so if one domain's SPF record is compromised, it can affect all the other domains that are using the same IP. This could lead to legitimate emails being rejected or marked as spam, causing confusion and potential loss of business.
Another danger of using shared domain IPs is that it makes it easier for fraudulent emails to be sent from the same IP address. If a spammer or phisher is able to gain access to a shared IP via registering a domain with the same registrar, they can use it to send unsolicited emails or phishing attempts to a large number of recipients. This can not only damage the reputation of the IP address and the domains that are using it, but it can also lead to a significant increase in spam and phishing attempts.
The Simple Mail Transfer Protocol (SMTP) does not authenticate email by default and requires domain owners to implement a set of DNS records correctly in conjunction with each other to achieve proper deliverability and security. Lack of authentication by default, a lengthy learning curve to understanding the email standards, non-standardized actions in response to security policies across mailboxes, and limited expertise in the field creates an environment rife with misconfigurations and misunderstandings which enables attackers to use inexpensive or open mail relays to perform spoofing attacks.
The process to spoof a domain is simple. Instead of claiming to be from the attacker's own domain, an attacker simply has to input any domain with no authentication instead into the sending header. Domains without authentication, essentially are setup for anyone on the internet to be able to send mail on the domain's behalf. Although this is not the proper way to authenticate the entire internet to send mail on your domain's behalf, it works.
The process for performing this attack is as follows:
- Use telnet (or similar program) to connect to the mail server
- Identify yourself to the mail server
- Tell the server the FROM and TO address of the email
- Include the message you want to be sent
- Full send!
It will typically look like this when connecting directly to a open relay server using telnet:
HELO server
MAIL FROM: [email protected]
RCPT TO: [email protected]
DATA
A message to be sent to the victim.
And that's it! It's really that simple in some cases. If you wanted to do this quickly in python the pseudo code below would work as well:
import smtplib
# specify server and port
server = smtplib.SMTP('mail.server.xyz', 25)
# initiate connection
server.ehlo()
# specify sender and recipient
sender = '[email protected]'
recipient = '[email protected]'
# send the HELO command
server.helo('server')
# send the MAIL FROM command
server.mail(sender)
# send the RCPT TO command
server.rcpt(recipient)
# send the DATA command
message = "this is a spoofed email message"
server.data(message)
# end the message
server.rset()
# close the connection
server.quit()
The python code mentioned above is equivalent to manually connecting via telnet. An open relay server is one example of this method, but there are other forms of email spoofing attacks. Below is a table of some of the most frequent types of email spoofing attacks:
| Attack | Description |
|---|---|
| Look-a-like attack | These are emails coming from addresses that look like valid email domains but are non-existing domains or use invalid characters. You spoof a non existent domain and register a phishing domain |
| BEC reply-chain, fake insider attack | These are emails coming from addresses that look like valid email addresses from within your company. |
| Fake-Subdomain attack | These emails appear to come from a subdomain of a valid email domain. |
| Domain attack | These are emails that impersonate a valid email domain. |
| Subdomain attack | These are emails that impersonate a valid email subdomain. |
With the understanding of how easy it is to send an email from a spoofed domain, it is clear how important it is to have a way to detect and prevent these types of attacks. To address this need, I have created a tool called Spoofy, which automates the process of checking a domain for email spoofability.
To hear more about the features and capabilities of Spoofy, and how it can help protect your organization from email spoofing attacks check out this article I wrote for Bishop Fox: https://bishopfox.com/blog/spoofy-email-domain-spoofing