45

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.

  • 26
    I can deny passing you a knife (exe file) if I think you are prone to stabbing yourself or others with it (which most users are) but I really have no way of stopping you from going out and getting your own knife. The former is fault of the administrator, the latter is fault of the user. If you have an actual need to be emailing executables then you are quite frankly "doing it wrong". – MonkeyZeus Jan 14 '20 at 19:07
  • 4
    If I remember correctly, historically outlook used the IE to show emails, which was in principle the windows explorer. So passing along a bit of javascript code you could autorun an embedded .exe file. And since outlook (express) was automatically delivered since windows 95 you had a HUGE attack-surface, which was often used. The well-known "I love you" virus from 2000 built on this. Open the email in the quasi-standard outlook(express) on windows 95 / 98 and you had it infecting your system. It then automatically multiplied itself by sending a copy to everybody in your address book – eagle275 Jan 15 '20 at 13:35
  • 8
    RE: Big fat warning: [... users don’t read *anything*.](https://www.joelonsoftware.com/2000/04/26/designing-for-people-who-have-better-things-to-do-with-their-lives) – Andrew Keeton Jan 15 '20 at 14:34
  • 3
    Because if you don't block it, users will click it. – amalloy Jan 15 '20 at 21:19
  • Related: Renaming EXE files to eg .XEX was often enough in the past to allow them to transit successfully. Having the recipient need to rename the file allows your warning messages to form a more effective barrier and allows a degree of 'qualification' of the recipients. eg "The attached is a renamed executable" would stop many users. That + suitable large warning in a 'readme' file with the rename comment embedded between eg large crimson deaths heads etc would add "a degree of increased security". For certain, some people would ask a friend to convert the file for them and ...., but useful. – Russell McMahon Jan 16 '20 at 11:09
  • 2
    @MonkeyZeus If you have an actual need to be emailing executables, then you should be using an encrypted .7z archive containing the .exe. ;) – Andrew Jan 16 '20 at 16:49
  • 3
    @Andrew Ah yes, the ol' file in a prison cake trick. – MonkeyZeus Jan 16 '20 at 20:21

7 Answers7

80

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 13
    "That's going to get more than a few people curious about why HR is using some 3rd party file hosting service." - not when they all do that because various peoples' email systems keep blocking their attachments. – user253751 Jan 14 '20 at 14:01
  • 25
    @user253751 Why is HR sending executables? And why are the files not available internally to attach/link? – schroeder Jan 14 '20 at 14:06
  • 14
    They're not sending executables, but the files they do send keep getting rejected by systems that block more file types than just executables. – user253751 Jan 14 '20 at 14:37
  • 18
    @user253751 then you are talking about rules beyond the scope of the question and beyond my experience with any organisation. – schroeder Jan 14 '20 at 22:03
  • 4
    They have started sending .ISO files, which have an autoplay exe. Some people open it, which mounts the virtual drive and runs the virus. So, the email contains a `totallylegitfile_really.pdf.iso` attachment. I've seen this a few times. – Ismael Miguel Jan 15 '20 at 00:22
  • 1
    HR should (mostly) be dealing with emailing people on its own company. Which are controlled by the company IT team. So, they should reach an agreement on acceptable content to send. Perhaps they are inadvertently sending documents with embedded macros. – Ángel Jan 15 '20 at 00:31
  • 6
    @schroeder File size restrictions maybe? They're a good reason to use file hosting services instead of email attachments. – Bergi Jan 15 '20 at 00:54
  • @user253751 It is possible that the HR systems are compromised and the files being attached are infected. This is clearly an IT issue and the solution is not to simply bypass the filters in place. – Nelson Jan 15 '20 at 03:43
  • 1
    @schroeder [Why would they block XML files?](https://security.stackexchange.com/questions/103712/why-do-email-programs-block-xml-files?rq=1) [or images?](https://security.stackexchange.com/questions/7489/why-would-someone-want-to-block-images-in-email?rq=1) – user253751 Jan 15 '20 at 10:11
  • 3
    @user253751 HR sending out lots of XML, are they? And the answers are provided in your links ... – schroeder Jan 15 '20 at 10:42
  • Wouldn't it just be much more effective for Windows to just show the user a file's extension? I would've thought after all these years of Windows viruses, they'd have figured out to at least inform the user they're downloading an executable (from a browser or email client). – At0mic Jan 15 '20 at 14:26
  • 4
    @At0mic that assumes people understand the extension and understand the risks. The data shows that's not the case. Extensions help those who already know. – schroeder Jan 15 '20 at 14:29
  • @IsmaelMiguel autorun is not "auto" at all on most modern systems. – ave Jan 15 '20 at 17:37
  • @Ave Well, it does give a warning but people may allow it to run. Or they themselves will double-click on the drive icon, which will do the autorun. – Ismael Miguel Jan 15 '20 at 17:48
  • 1
    I have had users tell me they clicked on the link to stop that annoying warning message popping up. – MortimerCat Jan 16 '20 at 12:21
  • @MortimerCat Well, that's terrifying. Also, ["Nothing is foolproof to a sufficiently talented fool" and "If you make something idiot-proof, someone will just make a better idiot."](https://en.wikipedia.org/wiki/Idiot-proof) – MonkeyZeus Jan 16 '20 at 13:35
  • 1
    Also, Windows is quite helpful with this kind of attack by hiding the last file extension. So for a file with the name `totallylegitfile_really.pdf.exe` it would display `totallylegitfile_really.pdf`. This makes the attack much easier. I really wonder what they were thinking when setting this as a default setting -.- – Dakkaron Jan 16 '20 at 15:00
  • @schroeder I've seen increasingly many systems refuse all attachments except a small set of allowed extensions (usually .jpg, .png, .pdf, .docx&co, maybe .zip). I guess the logic is that many applications are not safe to use with untrusted files and obscure file extensions could get opened with whatever obscure application people have installed. – jpa Jan 16 '20 at 17:06
  • If the purpose is to protect gullible users who might disregard warning dialogs, why don't they allow a setting in the client application which can be set to allow executables? The users can then allow it on their own responsibility, and non-technical users (who could be fooled by a something.pdf.exe) won't meddle in the settings (or won't even know they exist) in the first place. – vsz Jan 17 '20 at 08:25
21

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • 7
    "using advanced encoding" Yup! Like changing the file extension to `.txt`. "Text" files never get purged. – Tezra Jan 14 '20 at 19:02
  • 6
    @tezra Unsure for Gmail and Outlook (I use neither of them), but the security system included in my corporate mail server detects executable files whatever the extension, and even insiste zip archives... – Serge Ballesta Jan 15 '20 at 04:22
  • 5
    "What is admitted by both Google and Microsoft is that end-users should never exchange executable files." Do you have sources of them saying this to back this up? – nick012000 Jan 15 '20 at 04:59
  • 4
    @nick012000: I don't. But if they assumed that exchanging executable by mail was a natural operation they would not ban it. – Serge Ballesta Jan 15 '20 at 06:32
  • Users _should_ be able to send any file. Unfortunately, the O.S. (and most users) cannot distinguish a user from a hacker. The loophole I used was to compress the exec into a .zip but, sorry, that loophole has been closed. Now I just ftp to my web server and email the URI. – WGroleau Jan 15 '20 at 16:54
  • 2
    @SergeBallesta they're probably checking for magic bytes, [here's an example](https://elixi.re/i/rvnxjqkf.png). – ave Jan 15 '20 at 17:38
  • @WGroleau: Desktop OS are not concerned here. Only mail servers (for Gmail.com or corporate servers depending on their configuration), and mail readers (for Outlook) can add security policies. For example Thunderbird has none, and AFAIK *by default* most free mail server software implement no attachment policy besides the size. – Serge Ballesta Jan 15 '20 at 17:39
  • Server and client can’t do it either. – WGroleau Jan 15 '20 at 17:43
  • @WGroleau it works if you change the file extension, zip the file and password protect it. A password protected zip can't be analyzed but you still need to change the extension because even with password the file names are in plaintext and as soon as the system see .exe the file is rejected. – Marco Martinelli Jan 16 '20 at 00:45
  • Last time I did it, .zip worked. But I've been retired for five years and thankfully no longer have to tolerate Outlook. – WGroleau Jan 16 '20 at 01:05
  • @MarcoMartinelli: Unsure for Gmail.com and Outlook, but a correctly configured corporate mail server doing attachement filtering should reject a password protected zip... – Serge Ballesta Jan 16 '20 at 11:04
  • @SergeBallesta But it won't reject a password protected .7z, because it can't even see the file list. ;) And if that doesn't work rename it to .png or something... And if that doesn't work, set your house on fire. – Andrew Jan 16 '20 at 16:53
  • @Andrew: most mail server security add ons use heuristics and magic data in files to guess what they actually are (like Unix or Linux `file` does). So changing the extension is useless. And a password protected archive file is rejected precisely because it is not possible to know what it contents. It is like trying to enter a place where a guard asks you for your id card to control your age. If you present no id card, they will not let you in. – Serge Ballesta Jan 16 '20 at 18:55
  • 1
    @nick012000 *"What is admitted by both Google and Microsoft is that end-users should never exchange executable files."* - because obviously software should only be bought from these big companies, no pesky private individuals should be even allowed to write their own software, as it might cut into the profits of developer companies. – vsz Jan 17 '20 at 08:28
18

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. :-)

Ángel
  • 17,578
  • 3
  • 25
  • 60
  • 4
    "Not all of them, of course" -> "All of them, of course." Everyone is an idiot some time or the other. – muru Jan 15 '20 at 05:47
  • 3
    All users have moments of inattention. It's not fair to say that "Users are stupid". I know a CISO at a major bank who gets and processes 600 emails a day. He's more than an expert in security, has a PhD in cryptography from Cambridge and worked with the military in the field to hack hostile networks and devices. He will still click on phishing emails. Is he stupid? Absolutely not. He just can't always spend the extra few seconds of attention needed to assess all emails. Even experts need a safety net. – schroeder Jan 15 '20 at 10:44
  • 1
    @schroeder: "Users are stupid" is just shorthand for "user's will do dangerous things they should never do". They don't really mean they're actually stupid. A better phrase is probably in order. And I believe you about the CISO, that click is almost automatic after you've seen enough emails. – President James K. Polk Jan 15 '20 at 13:02
  • 2
    @JamesReinstateMonicaPolk it's called "human factors" and it is multi-layered. I offer a better phrase: "Even experts need a safety net." – schroeder Jan 15 '20 at 16:00
  • @schroeder Actually I would classify not spending the extra few seconds of attention needed to assess all emails as stupidity. – Andrew Jan 16 '20 at 16:55
6

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.

Philipp
  • 48,867
  • 8
  • 127
  • 157
3

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.

dandavis
  • 2,658
  • 10
  • 16
1

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.

supercat
  • 2,029
  • 10
  • 10
  • 2
    In modern times, are emails ever relayed through a server that is not controlled by either the sender or the recipient or their respective email providers? – user253751 Jan 16 '20 at 10:59
0

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.

rackandboneman
  • 975
  • 4
  • 9