How to prevent the spread of backscatter emails by email servers of MU
How do these types of malicious emails originate? Why do we need to prevent their spread and how?
What's the problem - the first scenario
Backscatter emails are created when an attacker sends a malicious email to an email server, spoofing the header of these emails so that the From and Reply-To fields contain the victim's email address. After the message is delivered to the email server and detected by its spam or anti-malware filter - or for some other reason that makes the email undeliverable (e.g., an invalid recipient address) - the email server "bounces" the message to the address that is listed in the email as the sender, which in this case is the victim; alternatively, the email server sends the victim a notification that the email was not delivered. Especially in the first case, the attacker will reach his target, but the second case may also suffice. In some cases, an otherwise legitimate email server may end up on spam blacklists in this way.
Unfortunately, Masaryk University's servers are vulnerable to this vulnerability, and it is this vulnerability that is currently being exploited by the mass sextortion campaign.
How does it work?
The attacker simply sets the victim's email address not only as the sender, but also as the recipient of the email, giving the user the impression that the email was actually sent from their account to themselves. Through this manipulation, the attacker attempts to convince the victim that he has full control over his device and, as part of this, he filmed him watching pornographic content in a discreet moment.
The user can be manipulated in this way even if he receives a notification of non-delivery of an email. After all, the e-mail was blocked by an e-mail server that is not infected and did what it was supposed to do. The attacker's narrative that he is in control of the victim's computer, and thus the victim's e-mail box, does not lose much credibility. At other times, the spoofed sender address is invalid, but even in this case, the attempt to "bounce" the email represents an unnecessary communication and computational burden.
How to avoid the first scenario?
Very simply - e-mail servers need to be reconfigured so that e-mails that any filter marks as malicious are not sent to the sender's address after they are received (bounce), but rejected directly upon receipt. This rejection is performed by the email server during SMTP transmission while the connection to the actual sender of the bad email is still open - that is, before it enters the email server. This rejection may have a return code of 4xx for a temporary rejection (for example, "mailbox busy") or 5xx for a permanent rejection (for example, "no such user"). [1] suggest return code 554, [2] and [3] suggest 550. Thus, only the actual sending server will receive the rejection and should notify its local sender, especially if it is a legitimate email. Spam is often sent by bots that don't even listen.
Such an elegant solution is no longer possible after the connection to the actual sending server is closed, and the "bounce" of the email can only be done by the information in the forged email headers, which only makes the problem worse. It is also no longer possible to reliably and securely notify the sender of non-delivery of an email. Even according to more recent RFCs, emails should not be "bounced" where there is no reasonable assurance that the "bounced" message will be "usefully delivered" - to the actual sender, of course. For this whole issue, it is equally not recommended to use auto-responders to emails, or if unavoidable, only behind a strong spam filter supplemented by a check by an authorized person. The same goes for Challenge/Response - they only shift the problem from the recipient to those falsely listed as sending the problematic emails, and they are easy to abuse and circumvent. Even using these mechanisms can easily lead to our email server ending up on blacklists.
For further details and advice that we consider particularly relevant, please see the last section of this article.
The Second Scenario
But there's an even trickier scenario that can lead to backscatter of malicious emails - when an email server user has set up a mail forwarder to forward mail elsewhere. If the attacker's email is only detected by a filter on the third-party email server, the filter rejects the email, and our email server informs the "original sender" - again, in this case, the victim - that delivery of the (malicious) email has failed. Since there is often a delay between the receipt of an email and its forwarding, it is not possible to wait for a response from the third-party email server when receiving an email and deciding to reject it.
How to avoid the second scenario?
The only way to avoid this second scenario is to be consistent in filtering malicious emails on our server to minimize the risk that a malicious email that we forward elsewhere will be bounced.
Further details on the solution
Many malicious emails can be filtered out more easily than with an advanced spam filter like SpamAssasin.This includes checking that the sender's address is not on a blacklist and that the email was sent by a regular email client, but also a lot of other things. Examples of such a Postfix configuration are in [1] and [3]. [1] recommends to start with less computationally demanding filters, especially for communication with other servers, and gradually move to more demanding filters, leaving advanced filters like SpamAssasin or Bayes filtering to the end. A message is finally accepted only if it passes all filters.In this way, maximum filtering efficiency can be achieved. [3] advises how to detect a spoofed sender address, at least in some cases, and finally outlines how to filter notifications from antivirus scanners. [4] describes a specific case of this problem.
Resources
[1] https://willem.com/blog/2019-09-10_fighting-backscatter-spam-at-server-level/ – simply explained with a partial example of Postfix configuration
[2] http://www.dontbouncespam.org/ – a page from 2007-2011, but still useful; explained in more detail and with context, includes advice on filtering spam, testing the correct behavior of a configured email server, and finding out if it's already blacklisted
[3] http://www.postfix.org/BACKSCATTER_README.html – an old article in the Postfix documentation; it focuses on a practical solution to this problem in Postfix
[4] https://serverfault.com/questions/792442/postfix-reject-not-bounce-unknown-virtual-aliases – describes a solution to a specific case of this problem in Postfix - rejecting instead of "bouncing" emails directed to unknown virtual aliases