Fake letters. How to defend
Hi habr! In this article I decided to touch upon the topic of protection against fake emails (Email spoofing, Forged email). It will be about letters in which information about senders is somehow forged. The recipient sees the letter sent ostensibly by a trustee, but in fact, the letter was sent by the attacker.
Recently, we are increasingly hearing about the problem of fake emails from our customers, or simply from friends. This problem is not only relevant, but seems to be gaining momentum. Here is a real story from a friend who was close to losing a sum with four zeros in dollar terms. The company conducted correspondence in English with a foreign company about the acquisition of expensive specialized equipment. First, the nuances arose on the side of our friend - it was necessary to change the details of the sender's account (the company-buyer). After some time, after the successful negotiation of new details, the equipment supplier also announced the need to change the details of the recipient’s account (seller company). Here are just letters about changing the recipient's data were already from the attackers who successfully replaced the sender's address. Against the background of some common turmoil, aggravated by the fact that both sides were not native speakers of the correspondence, it was almost impossible to notice the substitution of letters. It should be noted that the attackers diligently copied styles, fonts, signatures and photos in letters. How exactly the information about the transaction leaked - most likely the mail correspondence was compromised. A week before the final approval of the transaction, which is discussed in this article, a letter with a trojan came to the post of a friend in the form of an invoice in the * .exe archive. At the time of arrival of the letter, the antivirus did not catch the malware, and for some time he managed to “work” on the computer, and even pull up a couple of his fellows for help.
')
A few days later, the anti-virus signatures were updated and the malware with the brethren was removed, but by that time they had already entered the correspondence, the sender was forged, the money went to someone else's account.
In this example, the substitution of the sender's address was made extremely straightforward. We will not publish real addresses, but we will give a similar example.
The correct sender address is: best@bestofall.com
Fake sender address: bestbestofall.com@spoofed.ru.
The attacker's email account included the name “best @ bestofall” and the last name “.com”. A part of the correspondence was conducted by a friend from a mobile device whose email client displayed only the sender's name and surname in the sender field. And so do all mobile mail clients. Therefore, the incoming letter in this email client was seen as from best @ bestofall “space” .com. Which is very similar to the original. Below is a letter from the attacker and a legitimate letter under him in the Yandex.Mail interface:
In Outlook, the letter from the attacker also looked quite similar to the original, if you carefully do not peer, you can also not notice a fake.
Everything came to light when the supplier called and asked: “Is it Mayer Mani?”. Fortunately for a friend, due to a double change of details (recipient and sender) regarding the original signed agreement $$$$$ were not finally credited to the account of the malefactors, but hung up on the transit account of the receiving bank, and managed to return them.
Companies around the world suffer significant losses due to email attacks. So from October 2013 to August 2015, the cumulative loss from corporate email compromises of companies around the world amounted to 1.2 billion US dollars. And attacks with fake emails are among the most common types of attacks on corporate email systems.
Special attention is paid to attacks in which the attacker sends a fake letter on behalf of a high-ranking company executive. In the text of the letter, the attacker requires an immediate response, or some urgent reaction from an employee or group of employees of the company. For example, it may request to respond to a letter by sending any confidential information. This can lead to data leakage. Or the attacker may require an urgent bank transfer of any large amount. In the scenarios described, the employee is under pressure: a high-ranking manager requires immediate action. This fact increases the likelihood of attack success. In addition, the attack may be preceded by reconnaissance methods of social engineering, to most effectively form the text of the letter and most accurately identify the target group of employees who receive a fake letter. This approach also has a beneficial effect on the success of the attack.
In order to understand the mechanism of falsification of the sender's address, let us recall the structure of the e-mail message transmitted via the SMTP protocol. An email consists of an envelope (envelope), headers (headers) and a letter body (message body). Information about the sender is contained in the envelope. This information is generated by the mail from SMTP command and has a direct impact on the message transfer process as the Mail Transfer Agent (MTA) mail servers pass. However, the sender information is also contained in some of the message headers, such as “From:”, “Return-Path:”, possibly “Reply-To:”. The “From:” heading does not have to be the same as what is written in the envelope of the letter and can represent some “friendly name” (friendly name, friendly from). The “Return-Path:” header copies the sender from the envelope. The “Reply-To:” header contains the address for the reply. The headers are significant for the email client (for example, MS Outlook), the corresponding fields are filled in by the headers.
Consider an example of SMTP commands for sending emails with fake “From:” and “Reply-To:” headers. Connect to your Exchange mail server using telnet:
telnet 10.1.2.3 25 220 Exchange Microsoft ESMTP MAIL Service ready at Wed, 26 Oct 2016 10:28:00 +0300 helo 250 Exchange Hello [192.168.100.100] mail from: attacker@spoofed.ru 250 2.1.0 Sender OK rcpt to: uskov@cbs.ru 250 2.1.5 Recipient OK data 354 Start mail input; end with <CRLF>.<CRLF> From: Ivanov Ivan <CEO@cbs.ru> To: Boris <uskov@cbs.ru> Reply-To: attacker@yandex.ru Subject: Urgent! Need your credit card information. Ivanov Ivan Ivanovich, CEO, Computer Business Systems . 250 2.6.0 Queued mail for delivery quit 221 2.0.0 Service closing transmission channel In this example, we send a letter from the real address to attacker@spoofed.ru, but in the “From:” header specify the name and address of the head of the company, and in the heading “Reply-to” the address to mail.yandex, where the inattentive employee will send confidential information. As a result, the letter in the Outlook email client will look like this:
And if you click "Answer" the recipient’s address will be automatically filled in:
As you can see from the previous example, sending a fake letter is not difficult if the mail server is not protected. In the worst case, the value in the envelope of the letter mail from can also be replaced by a legitimate one. If the body of the letter is composed carefully and using the results of social engineering, it becomes increasingly difficult for the end user to identify a fake letter. The situation is even more aggravated for users of mobile devices. The concept of mobility implies that we perform all actions quickly, “on the go,” and even on a small screen, not paying attention to trifles / inconsistencies. Incidentally, in the example of a friend’s deal with a foreign company, a friend also didn’t do without the “mobility” factor. Part of the correspondence took place from a mobile device, the mail client in the sender's field displayed only the name / surname of the sender, but hid the full postal address.
There is no unified method of dealing with spoofed letters. Protection against this type of attack requires an integrated and multi-level approach. Let me try to highlight the main approaches to countering fake emails:
- Filtering based on the reputation of the sending server.
- Filtering based on checks of the DNS records of the sender server.
- Filtering on the basis of checks of the DNS records of the sender's domain from the letter envelope.
- Filtering based on SPF records checks.
- DKIM based filtering.
- DMARC based filtering.
- Creating granular filters "manually."
Of these methods, the first three are coarse filters that allow you to deal with the mass mailings of spam, malicious mail, including a spoofed sender. In this case, the attackers use the mass effect, not carrying out any special reconnaissance before the attack and not trying to accurately select the content for the recipient. For example, letters on behalf of Sberbank with a request to provide any confidential information (username / password from personal account, card numbers, PIN codes) sent to a huge number of recipients. According to the principle, anyone bite.
Methods 4-6 help to deal with exact substitutions of senders, that is, situations where an attacker specifies a substitutable sender with an exact sign in the letter headers.
Method 7 will have to be resorted to in cases like in the example about correspondence with a foreign company at the beginning of the article, when the letter header is modified in such a way as to become like the real sender. But at the same time, the heading in the replaced letter is still different from the heading of the real sender, which allows you to bypass the verification methods 4-6.
Consider these methods in more detail.
1. Filtering based on the reputation of the sending server. If the corporate mail protection system provides a high-quality database of senders' reputation, we can filter a significant percentage of spammers and malicious correspondence of any kind already at the stage of establishing a TCP session, without looking at either the body or the envelope of the letter. This approach significantly saves system resources. As soon as the sender tries to establish a TCP session on port 25, the security system determines the reputation for the sender's IP address and makes a decision.
Cisco ESA example. Reputational filtering.
It is a little specifics on the example of Cisco ESA. The solution uses the Sender Base reputation database. We see that reputational filtering helps to stop around 80% of malicious emails. Moreover, from the many years of experience in implementing and maintaining this solution, I can say that the number of false positives of the Cisco ESA reputation filtering tends to zero.
Below is a summary of our organization:
Depending on the reputation of the sender, Cisco ESA not only decides to drop the letter or skip further, but also determines the further script for processing the letter. For different values ​​of reputation, we can apply different policies:
Below is a summary of our organization:
Depending on the reputation of the sender, Cisco ESA not only decides to drop the letter or skip further, but also determines the further script for processing the letter. For different values ​​of reputation, we can apply different policies:
2. Filtering on the basis of the DNS records of the sender server. The sender of mail messages must be correctly registered in DNS. For the sender, there must be a valid PTR record, A record. The sender must be correctly presented in the HELO SMTP command. When mass mailings of spam and malware attackers are constantly changing the IP addresses of sending servers. Addresses change every day and even more often. Registering the necessary records in DNS is difficult and even impossible. Therefore, many distributors of spam and malicious messages neglect these requirements, respectively, it is possible to filter them by the DNS features.
Cisco ESA example. DNS checking the sender's IP address.
Consider DNS checks using the example of Cisco ESA. When a TCP session is established, the following DNS sender checks are performed:
If the PTR record does not exist, or the found A-record points to a third-party IP address, we are more likely to accept the session from the illegitimate sender. For such senders on Cisco ESA, we can apply restrictive policies (discard the letter, send to quarantine, modify the header, limit the number of sessions, etc.), depending on the requirements.
I want to pay attention, at this stage of the checks, the ESA does not control the legitimacy of the sender, that is, does not check whether the sender has the right to send letters from the specified domain. Moreover, at this stage, neither the envelope of the letter, nor the headers are viewed. Only validates by IP address. For example, if letters from the mycompany.ru domain come from the “left” IP address with correct A- and PTR-records in the DNS, for example, “smtp.spamer.ru”, the check will pass successfully and the letter will be skipped for further processing. Checking the legitimacy of senders is carried out by other methods (see below SPF records, DKIM, DMARC).
- Check for PTR record. The PTR record must be unique and return the correct canonical name of the sender's host.
- Check for the presence of an A record for the host name found in the first step (by PTR record).
- Checking the forward DNS lookup match for the A-record from the previous step with the sender's IP address.
If the PTR record does not exist, or the found A-record points to a third-party IP address, we are more likely to accept the session from the illegitimate sender. For such senders on Cisco ESA, we can apply restrictive policies (discard the letter, send to quarantine, modify the header, limit the number of sessions, etc.), depending on the requirements.
I want to pay attention, at this stage of the checks, the ESA does not control the legitimacy of the sender, that is, does not check whether the sender has the right to send letters from the specified domain. Moreover, at this stage, neither the envelope of the letter, nor the headers are viewed. Only validates by IP address. For example, if letters from the mycompany.ru domain come from the “left” IP address with correct A- and PTR-records in the DNS, for example, “smtp.spamer.ru”, the check will pass successfully and the letter will be skipped for further processing. Checking the legitimacy of senders is carried out by other methods (see below SPF records, DKIM, DMARC).
3. Filtering on the basis of checks of the DNS records of the sender's domain from the letter envelope. Information in mail from is also subject to verification by DNS. For example, Cisco ESA can be discarded if:
- Information about the sender's domain is not in the envelope.
- Domain name is not resolved in DNS.
- Domain name does not exist in DNS.
This type of checks is not particularly effective; letters with intentionally incorrectly formed envelopes are discarded.
4. Filtering based on SPF records checks. SPF - Sender Policy Framework is a system for checking email senders. Checking method 2 “DNS records of the sending server” says only that for the IP address of the sender there are necessary records in the DNS (PTR and A records). However, these checks do not help determine whether the sender has the right to send emails from the specified domain. It is worth noting that often A-records of mail servers contain the domain name of the company, for example, smtp01.mycompany.ru. If the same server is used to receive mail, then the same A-record will be included in the MX-record. It can be assumed that if the letter from mycompany.ru is sent from the server smtp01.mycompany.ru, then this letter is not fake, otherwise, if the letter is sent from smtp01.anythingelse.ru, the letter is fake. But in fact, companies often send e-mail not directly from their mail servers, but through any additional MTA servers, for example, through the servers of their providers. In this case, we receive that a letter from the domain mycompany.ru is sent through servers, for example, smtp01.provider.com, smtp02.provider.com, etc. The canonical names of the sender servers do not belong to the domain of the company mycompany.ru. How does the recipient in this case understand whether the sending servers are legitimate or not? This task is solved by the SPF checking system.
The problem is solved again using DNS. For the sender's domain, a special format TXT record is published. This TXT record lists the IP addresses, subnets, or A records of servers that can send mail, servers that are not legitimate senders. Thanks to the SPF system, the recipient can contact the DNS and clarify whether the server can be trusted to the sender of the letter, or the sender server tries to impersonate someone else.
At the moment, not all companies form SPF records.
5. Filtering based on DKIM. DKIM - DomainKeys Identified Mail is an email authentication technology. Let's return to the example from the consideration of SPF-records, when the company mycompany.ru sends correspondence to the outside through the provider MTA smtp01.mycompany.ru and smtp02.provider.com. For MTA, there are SPF-records, so letters from mycompany.ru, sent through these servers, are successfully tested. But what if the MTA data is compromised, and the attacker will also be able to send fake emails through these servers? How to authenticate the sender in this case? Authentication of letters comes to the rescue.
Asymmetric cryptography and hash functions are used for authentication. The private key is known only to the sender server. The public key is published again using DNS in a special TXT record. The sender server generates an imprint of the message headers using a hash function and signs it using the private key. The signed imprint is inserted into the header of the letter “DKIM-Signature:”. Now the recipient of the letter using the public key can get the decrypted imprint and compare it with the imprint of the fields of the received letter (hash function is known). If the fingerprints match, the signed headers are not changed during transmission, and the sender of the letter that formed the “DKIM-Signature:” header is legitimate.
6. Filtering based on DMARC. DMARC — Domain-based Message Authentication, Reporting and Conformance — a technical specification that describes exactly how the results of the SPF and DKIM checks should be used. DMARC policies are published as usual using DNS in TXT records. DMARC policies indicate what exactly needs to be done with the letter on the recipient side (deliver, discard, send to quarantine), depending on the results of SPF and DKIM checks. In addition, DMARC provides feedback from the sender to its recipients. The sender can receive reports of all emails that have the sender's domain. The information includes the IP addresses of the sending servers, the number of messages, the result in accordance with the DMARC policies, the results of SPF and DKIM checks.
7. Creating granular filters "manually." Unfortunately, not all organizations use SPF, DKIM, DMARC when sending email. In addition, in some cases, SPF, DKIM and DMARC checks may succeed, but emails are still forged (Cousin domain, Free Email Accounts). For such cases, help filter settings. The capabilities of various systems for creating filtering rules vary. Filters are configured for different attack scenarios and depend on the organization of mail systems in companies. For example, in some companies they may come from outside the letter with the sending domain of the same company. Although in most cases such letters should be forwarded only within the organization’s perimeter.
We are more focused on Cisco ESA, so in conclusion we will look at a few examples of setting up filters on this solution, as well as interesting functionality that appeared in release 10.0 (June 2016) of software for Cisco ESA - Forged Email Detection. This functionality just allows you to deal with inaccurate fake senders, as in the example from the beginning of the article. If interested, well in the tackle.
Cisco ESA example. Filters.
Cisco ESA offers two types of filters: Content Filters and Message Filters. The former are configured using the GUI and offer a finite (albeit fairly extensive) list of conditions and actions. GUI example:
If Content Filters are not sufficient to describe the conditions of a letter under the action of the filter, you can use Message Filters. Message Filters are configured from the command line, use regular expressions to describe conditions, and allow you to create complex conditions (for example, If ( ( (A and B) and not C ) or D ) ). Message Filters process the letter before Content Filters and allow you to create more granular rules.
Consider several sender falsification scenarios and the corresponding Cisco ESA filters to counter attack.
Example 1. Letters with the organization's domain in the sender should not come from outside. An example is taken from cisco.com: link . An example is relevant when an organization is not ready to publish its SPF and Domain Keys in DNS. This example uses the following Message Filter:
Other options can be selected as actions: send to quarantine, drop a letter, etc.
Example 2. At the beginning of the article, we looked at an example where the mail from the letter envelope was not fake (attacker@spoofed.ru, that is, the attacker writes his correct address), but in the From header there was a fake address (uskov@cbs.ru). At the same time, nothing prevents an attacker from having SPF and Domain Keys in the DNS for the domain spoofed.ru. We receive that the counterfeit letter will pass checks of SPF and DKIM. Also, SPF and DKIM checks will be successfully passed if the attacker uses free mail (free mail accounts - gmail.com, mail.ru, etc.).
We can deal with this situation by checking the equality of values ​​in the mail from and the From header. Immediately it is worth making a reservation, in general, the RFC does not require at all that mail from be equal to From. Therefore, you need to apply such a filter only to some senders.
Cisco ESA at the moment (November 2016) has a limitation: you cannot compare field values ​​to each other, that is, you can't just write if mail from! = Header (From). The problem can be solved in another way. Create a dictionary of sender names Spoofed_senders, in which we will add senders subject to substitution. In the filter set the condition: if the mail from does not contain the sender from the dictionary, and the From header contains the sender from the dictionary, perform the action. You can send the letter to quarantine or drop it, but cisco recommends writing the forged value of the From header to the new X-Original-From header, and removing the From field altogether. In this case, the Cisco ESA will automatically generate a From header from the mail from value. An example of such a filter:
Example 3. Attackers use addresses that are similar to sender addresses, the so-called “Cousin domains” and “Cousin addresses”. For example, the address uskov@cbs.ru is replaced by usk0v@cbc.ru. For the cbc.ru domain, the SPF and Domain Keys are formed in the DNS, so the letters pass the corresponding SPF and DKIM checks successfully, and the recipient sees the sender’s friend. To deal with this substitution is more difficult. You will have to enter into the Spoofed_senders dictionary from the previous example all similar variants of sender names and domain names, which is hardly possible.
To combat this type of sender substitution, Cisco ESA, starting with the release of AsyncOS 10.0 (June 2016), has an interesting feature “Forged Email Detection”. First, a sender name dictionary is created (in the examples, the name of the FED dictionary is used), as in the previous example, into which we will add senders subject to substitution. This dictionary is formed from sender names, not from mailbox names. That is, you need to write Olivia Smith instead of olivia.smith@example.com. The Forged Email Detection system will check the From header with the names from the FED dictionary and provide a probability (from 1 to 100) with which the sender can be considered forged.
For example, if the dictionary contains “John Simons” and the From header contains j0hn.sim0ns@example.com, the system will give a 82 fake probability. If the From header contains john.simons@diff-example.com (that is, the same name , but another domain), the system will give the probability of a fake 100.
Forged Email Detection is configured via Content Filters or Message Filters. Below is a screenshot of Content Filter settings:
You must specify the name of the dictionary, and the probability threshold value, after which we consider the sender as forged. For this condition, you can select any of the available actions (discard, send to quarantine, modify the subject of the letter, etc.). In addition, a new additional action for Forged Email Detection has appeared: replace the value of the From header with the value from mail from. This action does not offer any options:
Cisco ESA offers two types of filters: Content Filters and Message Filters. The former are configured using the GUI and offer a finite (albeit fairly extensive) list of conditions and actions. GUI example:
If Content Filters are not sufficient to describe the conditions of a letter under the action of the filter, you can use Message Filters. Message Filters are configured from the command line, use regular expressions to describe conditions, and allow you to create complex conditions (for example, If ( ( (A and B) and not C ) or D ) ). Message Filters process the letter before Content Filters and allow you to create more granular rules.
Consider several sender falsification scenarios and the corresponding Cisco ESA filters to counter attack.
Example 1. Letters with the organization's domain in the sender should not come from outside. An example is taken from cisco.com: link . An example is relevant when an organization is not ready to publish its SPF and Domain Keys in DNS. This example uses the following Message Filter:
MarkPossiblySpoofedEmail: if ( (recv-listener == "InboundMail") AND (subject != "\\{Possibly Forged\\}$") ) // , «Possibly Forged» { if (mail-from == "@yourdomain\\.com$") OR (header("From") == "(?i)@yourdomain\\.com") // mail from From { strip-header("Subject"); insert-header("Subject", "$Subject {Possibly Forged}"); } } // «Possibly Forged» Other options can be selected as actions: send to quarantine, drop a letter, etc.
Example 2. At the beginning of the article, we looked at an example where the mail from the letter envelope was not fake (attacker@spoofed.ru, that is, the attacker writes his correct address), but in the From header there was a fake address (uskov@cbs.ru). At the same time, nothing prevents an attacker from having SPF and Domain Keys in the DNS for the domain spoofed.ru. We receive that the counterfeit letter will pass checks of SPF and DKIM. Also, SPF and DKIM checks will be successfully passed if the attacker uses free mail (free mail accounts - gmail.com, mail.ru, etc.).
We can deal with this situation by checking the equality of values ​​in the mail from and the From header. Immediately it is worth making a reservation, in general, the RFC does not require at all that mail from be equal to From. Therefore, you need to apply such a filter only to some senders.
Cisco ESA at the moment (November 2016) has a limitation: you cannot compare field values ​​to each other, that is, you can't just write if mail from! = Header (From). The problem can be solved in another way. Create a dictionary of sender names Spoofed_senders, in which we will add senders subject to substitution. In the filter set the condition: if the mail from does not contain the sender from the dictionary, and the From header contains the sender from the dictionary, perform the action. You can send the letter to quarantine or drop it, but cisco recommends writing the forged value of the From header to the new X-Original-From header, and removing the From field altogether. In this case, the Cisco ESA will automatically generate a From header from the mail from value. An example of such a filter:
SpoofedSendersFilter: if (header-dictionary-match("Spoofed_Senders","From", 1)) AND (NOT (mail-from-dictionary-match("Spoofed_Senders", 1))) // From , mail from { insert-header("X-Original-From", "$From"); strip-header("From"); } // X-Original-From From Example 3. Attackers use addresses that are similar to sender addresses, the so-called “Cousin domains” and “Cousin addresses”. For example, the address uskov@cbs.ru is replaced by usk0v@cbc.ru. For the cbc.ru domain, the SPF and Domain Keys are formed in the DNS, so the letters pass the corresponding SPF and DKIM checks successfully, and the recipient sees the sender’s friend. To deal with this substitution is more difficult. You will have to enter into the Spoofed_senders dictionary from the previous example all similar variants of sender names and domain names, which is hardly possible.
To combat this type of sender substitution, Cisco ESA, starting with the release of AsyncOS 10.0 (June 2016), has an interesting feature “Forged Email Detection”. First, a sender name dictionary is created (in the examples, the name of the FED dictionary is used), as in the previous example, into which we will add senders subject to substitution. This dictionary is formed from sender names, not from mailbox names. That is, you need to write Olivia Smith instead of olivia.smith@example.com. The Forged Email Detection system will check the From header with the names from the FED dictionary and provide a probability (from 1 to 100) with which the sender can be considered forged.
For example, if the dictionary contains “John Simons” and the From header contains j0hn.sim0ns@example.com, the system will give a 82 fake probability. If the From header contains john.simons@diff-example.com (that is, the same name , but another domain), the system will give the probability of a fake 100.
Forged Email Detection is configured via Content Filters or Message Filters. Below is a screenshot of Content Filter settings:
You must specify the name of the dictionary, and the probability threshold value, after which we consider the sender as forged. For this condition, you can select any of the available actions (discard, send to quarantine, modify the subject of the letter, etc.). In addition, a new additional action for Forged Email Detection has appeared: replace the value of the From header with the value from mail from. This action does not offer any options:
Conclusion
Email attacks with a fake sender are, unfortunately, a daily reality. And the consequences of a successful conduct of this kind of attack can be extremely deplorable both for each person individually and for the organization under attack as a whole. Substantial material losses and confidential information may occur.I hope the article will help to deal with the anatomy of attacks with fake letters, and with methods of protection. In the examples, I operated on a Cisco ESA solution; however, the security tools mentioned in the article are also implementable on other corporate email security systems.
Source: https://habr.com/ru/post/314738/
All Articles