Why do email server/clients block executable attachments?

Question

If I send an email with an .exe attachment to an Outlook recipient, the email client blocks the attachment and the recipient has no way of overriding this security setting (short of making certain changes to the registry). If I send the same email to a Gmail recipient, the email is refused by the server.

Why are they being so strict? Is there a possibility that the attachment may execute automatically, or is it simply to protect naive users from explicitly executing an untrusted attachment? Would it not be sufficient to use a big, fat warning aka "Are you really sure you want to do this?"

Of course, I can upload my .exe file to a file sharing service and provide the link in the email. Why is this considered any more safe than an attachment? A malicious scammer may do the same thing.

EDIT: I ask this question partially to learn whether it is safe to turn the feature off (by modifying HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Security\Level1Remove). I take it from the answers that this is safe for me personally, but probably not on the administrator level.

Answer 1

Would it not be sufficient to use a big, fat warning

Sure, if they worked. Most people tend to just "click away the annoying" without thinking.

Blocking executables means that attackers can't do something like sending totallylegitfile_really.pdf.exe It's a very basic social engineering defense to block executables.

Attackers have to go through the extra steps like you described, and so does the end user. Those extra steps give the user a little more time to think about whether this whole interaction makes sense. That extra time is key.

If I spoof the HR department's email (or make it look similar) and send out staff_bonuses.pdf.exe and it hits the user's inbox, there is little to protect the user. One click is all it takes. To do the same as an attacker, I would have to upload it somewhere then send the link. That's going to get more than a few people curious about why HR is using some 3rd party file hosting service.

It's a basic defensive measure. It raises the threshold of difficulty for attackers forces them to use 3rd party tools and gives end users a little more time to think.

Answer 2

This is the good old cost/benefit ratio.

@schroeder's answer is about the gain, this one is about the cost

What is admitted by both Google and Microsoft is that end-users should never exchange executable files. Images or video files are end-user objects, as are office files. But when it comes to executables they should only come from a store.

Such a decision is certainly not developer-friendly, but developers are expected to be advanced enough to find a way to circumvent it, for example by using a relay HTTP site, or using advanced encoding. Said differently the cost is assumed to be negligible.

Answer 3

Put bluntly Users are stupid

Not all of them, of course. But when you are handling the email for hundreds or even thousands of users, you will have some of those users that will open anything, provide their credentials on any phishing page (even those mimicking a different site!), etc.

Thus all kind of filters get added to mail systems for preventing that malicious content arrive to the users. They may include url reputation, antivirus filtering, and one of the most powerful ones is to simply block certain content.

When was the last time you needed to send an extension to Windows Control panel by email? Yes, a few people do develop them. The rest of the world receiving one it's just a virus. Even if it's not detected by your AV solution.

Similarly, in a comment Ismael Miguel mentions .iso files. What good is sending a .iso file by email? A typical iso file will be at least 500-600 MB. Some of your users would happily send them by email (even a 4 GB one), but that is an abuse of the system, email is not designed for file sharing, and does a relatively poor job at that. You should be looking at other solutions for file sharing (email is the lazy way, though).

The fact is that virus are using odd formats such as .iso, or old compression ones, precisely to overcome (Email) filters that would block their virus if they used a more common container (such as zip).

‎

So, yes, it is simply to protect naive users from explicitly executing an untrusted attachment.

Would it not be sufficient to use a big, fat warning aka "Are you really sure you want to do this?"

Experience has showed that it is not.

Look at the interface of Microsoft Office when opening a document with macros. It will do exactly that, when opening a file downloaded from the internet / an email it will show a bar such as:

Be careful - email attachments can contain viruses. Unless you need to edit, it's safer to stay in Protected View.

(List of Protected View messages)

However, almost every malicious document will contain content instructing the user to disable the Protected view "in order to view the document". Actually, so that the malicious macros will run.

And the bad news is that -for a fraction of users- they work. Users are receiving malicious emails, opening the attached (or linked) documents infected with macros, disabling the Protected view "Sandbox" and getting infected. The recent Emotet infection waves mostly(?) used macro document. And people got infected. By loads.

It's not that it is a bad design. In fact, Microsoft engineers didn't have much choice than allowing the users to override it (note: the system administrator may enforce that they get blocked), as there are certain legitimate cases for sending and receiving documents with macros.

There are of course legitimate cases for receiving otherwise blocked attachments, including suspicious or even known-to-be malicious content. For instance, an abuse@ email address, should be able to receive a notice of the malicious url on their own infrastructure that is serving a trojan, or a sample of the email they are sending out rather than blocking it at reception like some systems do (the best practice would be to apply filters both on sending and receiving).

Thus, the filters could be configured to exempt certain senders / recipients / mailboxes that need to receive otherwise blocked attachments. A good setup may additionally ensure that they can only be accessed from certain systems (isolated from the network, maybe?) and/or by some users known not to be stupid. :-)

Answer 4

Email systems once used to allow to send executable files, but stopped doing that because it lead to the spread of lots of viruses. One key event in this regard was the "ILOVEYOU" email worm of 2000, which consisted of a malicious visual basic script which would delete various files and forward itself to all other email contacts of the user. Users had to execute it manually, but a surprising number of users did. So many that estimations for the worldwide damage caused by the worm go up to 8 billon dollar.

Answer 5

My cat has opened attachments by walking on the keyboard ( I guess Tab and the 10-keys' Enter are one stride apart); hosing a system shouldn't be so mindless.

Answer 6

Executable files should only be transported by a secure tamper-resistant medium. If emailing of executables were widespread, it would be fairly simple for a malicious actor who had control of an email server to make it insert viruses into executable files sent as attachments to mail that went through that server. Since neither the sender nor recipient of email generally has control over the path it takes, there would be no way of knowing whether any particular message would reach its destination without being infected.

Answer 7

Another reason is making it more difficult to use email as a coordinated channel in an attack.

If an attacker eg succeeds in compromising a PC into scripting a limited set of user actions or overlaying misleading images onto application programs (to make users do something else than they think they are doing), the very last thing you want to facilitate is supplying executable files to such attacks - this would turn a limited attack into an effectively unlimited attack.

Granted, such an attack could also utilize a web browser accessing a prepared web server as a channel - however, for a web browser downloading large and/or executable files is routinely a needed function, and web browser designers will have to deal with making their software more resilient against such abuse anyway - and in a very security conscious environment, web access might already be well policed against such incidents.