16 ms·
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 t
by ethbr1 3y ago
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).
- stvltvs 3y agoThere 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-directory-with-encryption-for-file-names#290088 https://unix.stackexchange.com/questions/289999/how-to-zip-d...
- godelski 3y agoAnd 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-patches-zero-day-python-script-vulnerability-in-windows-client/ https://www.bitdefender.com/blog/hotforsecurity/telegram-pat...
- jerf 3y agoYes, 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.
- godelski 3y ago> 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 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.
- mrgoldenbrown 3y agoOur 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.
- userbinator 3y agoThat's when you start using the steganography.
- kccqzy 3y agoAnother 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.
- srockets 3y agoThen I wouldn’t dare emailing a zip bomb with a message containing the password and an instruction not to try and unzip that file.
- consp 3y agoAnother good reason to always send the passphrase via another channel.
- nkrisc 3y agoUse a space in your password.
- kccqzy 2y agoThis is an also a good strategy to prevent a good chunk of actual users from decrypting the zip.
- WirelessGigabit 3y agoThis reminds me of working at a company in Brussels during eBays heydays. Their URLs looked like http://offer.ebay.com/ws/eBayISAPI.dll http://offer.ebay.com/ws/eBayISAPI.dll?... And the filter saw .dll and denied my request.
- anyfoo 3y ago> Fewer, but some, inspect files to deduce their type. 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.
- kccqzy 3y agoGmail uses Magika https://github.com/google/magika https://github.com/google/magika to deduce file types to determine whether and how to scan email attachments.
- anyfoo 3y agoNeat. And I think that proves my point…
- stuffinmyhand 3y agoEspecially the "whether" :D