In my experience, the vast majority of corporate mail filters ban certain file types based on name extensions.
Fewer, but some, inspect files to deduce their type.
None care about encrypted zips with the file renamed to a common extension (encrypted zip manifests are unencrypted, so the file names are still visible).
And many people have learned to bypass these filters by renaming extensions. You can always zip things up or just rename foo.py to foo.py.pdf
But I understand that there is still reason to filter filetypes. Apparently some programs will run programs if they see certain filetypes... Here's a recent telegram exploit where the user did have to click on the file https://www.bitdefender.com/blog/hotforsecurity/telegram-pat...
Yes, it isn't just voodoo, "properly" labelled file types can carry dangers that "improperly" labelled ones do not. For example, if someone wants you to open a Word document with a bad macro, getting you to open it may be no big deal, but getting someone to "OK, first save it, then navigate to it with Explorer, then change Explorer to 'Show Extensions', then rename it to this, then open it" is likely to either set off some alarm bells, or simply be impossible for the technically-unsophisticated target.
Even if it is the same bytes nominally behind the "improper" and "proper" metadata labels the security profile of the two bits of content can still be very different.
Also, obviously, you'll always be able to get things "through" a filter like this. But the value of raising the bar of the exploit is still quite substantial; the "conversion funnel" for such exploits has a very sharp dropoff at every step, including even the first (most such attempts at an exploit even if delivered would not be unpacked by the target user).
Systems can generally block encrypted archives, though I suspect that many admins end up leaving that "off". I'm not sure it's a huge vector in the real world. My impression is that at the moment the most dangerous emails are the social attacks. Though the technical attacks are still non-trivial, still hit people, and technical folks can underestimate the need for non-technical folks to be protected from them.
I just want to stress this part.
So many people I talk to will just dismiss things because something isn't bullet proof. Like there's a binary option. But in reality there's a continuum. I'm the annoying person that tries to get my friends to use Signal, but then say if you won't install, that WhatsApp is my next preference. People on Signal forums will say that you shouldn't have the ability to delete or nuke conversations (now you can delete some, but only if <3hrs old) BECAUSE you can't guarantee the message content wasn't copied. Which is just fucking insane. It's not incorrect, but you have to think of things probabilistically and security is about creating speedbumps, not bullet proof vests. It is standard practice in many industry settings to remotely wipe a device (and then operate under the assumption that the data was leaked) because if you don't, adversaries have infinite time to copy that data rather than finite.
In most things, there are no perfect solutions. We have to think probabilistically and the tradeoffs for different environments (which are dynamic). Trying to make perfect solutions are not only unachievable, but even if they were they wouldn't last for long.
I hate those "features" because they blur the line of user control. You sent me a message, you shouldn't be able to decide to reach into my device and delete it.
It's okey if there's a feature where I can automatically and by default cooperate with your "deletion requests", but it should be possible to disable it.
I've always advocated that it be performed with consent. Both parties must consent. But I'd also advocate for a default on, since that is the position of higher security/privacy.
I actually believe that bulletproof vests are a good security analogue as well: they are typically only rated for certain cartridges/projectiles, only guaranteed to stop a certain number of projectiles, won't protect you from broken ribs or soft tissue damage, and most importantly, they're still, you know...a vest. Does nothing to stop you getting shot elsewhere.
The "threat model" of a vest specifically excludes certain threats and I still would _greatly_ prefer to be wearing one in a war zone.
lol yeah, I think this is fair. But I was going with how people think these vests work, not how they actually work. Because your analogy is spot on.
'Course, if the email filter keeps blocking legitimate content enough that recipients are accustomed to changing extensions to get around it, then it'll all backfire.
It’s wild to me that this has been the eventual consequence of file extensions.
MS decided that they were too advanced and hid them by default, thousands of companies tried to do automagic things instead of pushing for people to understand extentions, and inevitably the automagic stuff introduced exploits that were far worse than that education.
There's always just prefacing with magic bytes. :)
https://en.m.wikipedia.org/wiki/List_of_file_signatures
“Pushing for people to understand extensions” only does so much. So many file types are turing complete, and whatever runs them has access to a varying set of resources. That may be intentional, unintentional, by design, or through vulnerabilities.
What you need is proper sandboxing of the consuming applications, allowlisting of those applications (instead of “file types” with unspecified client applications), and ideally some type of trust system on top (but we all know how little acceptance stuff like PGP or even S/MIME has).
In other words: It should be safe for people to open any attachment they get. Think about web browsers: Heavy-hitting vulnerabilities aside, almost every web page you visit is safe for consumption by your computer, because of the browser’s security model. Same with iOS apps.
The remaining risk is addressed by provenance/trust.
A file name extension is a convenience for human-computer communication but insufficient metadata about a file to process without inspection. Examples include BOM, Exif.
https://stackoverflow.com/questions/2223882/whats-the-differ...
https://www.sciencedirect.com/topics/computer-science/file-s...
People also bypass this stuff by just using gmail or some other provider instead of their work email. We receive the lesson over and over that if you make a system too hard or too inconvenient to use, people will just do their own thing. But we never learn.
Our mail filter inspected zip files even if you renamed them to .txt or jpg, and if it couldn't check the contents because of encryption it would just delete the whole zip. It would also look for data that might be PCI related and flag that as well.
Another thing I've heard of is that commonly people include the password for the encrypted zip inside the email, so email filters have learned to try to decrypt the zip using every single word in the original email.
Use a space in your password.
This is an also a good strategy to prevent a good chunk of actual users from decrypting the zip.
Then I wouldn’t dare emailing a zip bomb with a message containing the password and an instruction not to try and unzip that file.
Another good reason to always send the passphrase via another channel.
That's when you start using the steganography.
There is a way to cajole zip into encrypting filenames if this is important enough to put up with unzipping twice. Plus you might get better compression!
https://unix.stackexchange.com/questions/289999/how-to-zip-d...
Isn't it better to just use 7z instead, which can encrypt filenames without tricks?
This is for times when you can't assume 7zip is available to the decrypter.
Point! I forgot about that, from my pathological remoted-through-3+-systems consulting days.
I don’t know. That’s extremely error-prone, often easy to fool, and in some cases hardly possible in the first place.
I think the only thing that’s really feasible is filtering out known bad things as some mild form of damage reduction.
Gmail uses Magika https://github.com/google/magika to deduce file types to determine whether and how to scan email attachments.
Neat. And I think that proves my point…
Especially the "whether" :D
This reminds me of working at a company in Brussels during eBays heydays. Their URLs looked like http://offer.ebay.com/ws/eBayISAPI.dll?...
And the filter saw .dll and denied my request.