Details are hazy as this was a long time ago, but at some point you could make parts of messages not render in Outlook and Outlook Express by writing "begin something" (two spaces after "begin") by itself in a single line. Outlook would thing that it was the start of an uuencoded block and not render anything after that.
I remember annoying friends in a mailing list by quoting emails with "begin quote from Person Name:" :)
The unix mbox format uses the sequence ["F", "r", "o", "m", " "] as its indicator that a new mail has started. If you're not careful about escaping your stored mails, you can easily corrupt them by starting a body paragraph with the word "From".
How do you escape the word From? Well, that's up to the client! Be careful using different clients for a given mbox file!
The fun part is that the actual uuencode format has the file mode in octal after the word begin. Somebody at microsoft decided this was optional and that begin with two spaces and then the filename should also be the start of a uuencoded section. Of course also without checking if there was any content that was actually encode in that format.
Reminds me of a bug from the early 00s in a bunch of router firmware, where the router would crash/reboot on receiving a malformed "DCC SEND" message, so people would spam "DCC SEND ANYLONGSTRINGHAHAPWNED" in large IRC channels and watch as half the participants dropped.
Similarly, at one time posting "startkeylogger" in IRC would also kill some people's connection because of an antivirus mistaking it for traffic from/for a trojan
oh the memories, the CTCP ping with the string "+++ATH0" string on the message, or the `/skin "/con/con"` command on Quake2 online games, and the ";cat /etc/passwd" on old Unix's finger services, fun simpler times, what a mess.
treating data as privileged input was never out of fashion. last one in memory: google pixels modem accepting AT for custom firmware things from the outside. recommendation was "disable 4G and 3G until update" (which was the first one they delayed)
Everything I can find points to an issue on some Netgear routers. At least some people say that disabling a specific router feature (stateful packet inspection firewall) would fix it, which seems like damning evidence. Presumably the router didn't actually crash, it just triggered the firewall. Interesting bit of archeological security. The fun part is that nothing has improved.
mIRC having a security hole with DCC SEND is exactly why some routers decided to filter it. EDIT: Perhaps I'm misremembering this. It seems it might have been due to some bugged port remapping code in the routers.
A lot of antivirus would do similar things, because they monitor IRC connections and go haywire if they see a message that suggests you’re on a command and control botnet running over IRC
I remember before AOL’s standalone Instant Messenger became popular, mid-1990s, we could go into AOL chat rooms (and Yahoo’s) and throw inline HTML tags into the chat box, and they’d affect everything below them until we either sent a closing tag, or enough posts came through to finally push it off the top of the screen. It’s kind of wild how long it took them to implement even very basic protections.
In early 2000 I was playing a stand alone mod for Unreal Tournament 99 called Tactical Ops. UT99 provided an IRC client right in the game and people used it to coordinate matches, when somebody from nato-ladder (North American Tactical Ops Ladder) discovered that spamming a specific character to a player in private message (or even in public channel where the player was) caused the game to crash with nothing to show in the logs.
They used it intelligently during tournament, not overusing it, just making a particular player drop at the right moment and probably abused it for sometime before it became publicly known.
I don't remember if this was an issue also present in UT99 or just TO.
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.
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.
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.
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.
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!
I've never really understood how this 'urls via our own redirector' really works, if at all.
I can imagine some reasons why it would work better than merely checking the URLs when filtering: not rewriting but simply checking and scoring against other spam rules. But also see reasons why it secures less well.
Pro: you can block URLs post-delivery. E.g. an advisary changes the link to malware or phishing after some time/n requests/based on user agent.
Con: all encryption, including DKIM, GPG etc break.
Edit: to clarify why I don't understand why this works: and advisary can still do the same: i.e. serve an innocent page to the checker but then a bad webpage to the actual visitor. Not trivial, but not hard either.
A good middle ground might be to scan URLs on the mailserver against lists and maybe open the page and scan its content before delivering.
Then have the client intercept links and redirect them through another on-demand checker?
Because obviously, training people to "not click links in emails" or use only plain text or both, hasn't worked in the last decades.
The most funny filters are those that visit the URL to check what it is. Those break all the magic login links, email verification links et. al. that people receive.
Here is the content that is in the HTML but which the linked page refuses to actually show on the screen, instead opting for a "run javascript" message:
<meta content='Our university deployed a mail filter that rewrites URLs in emails to redirect them via a service that checks for bad websites. Somebody clever worked out that PGP-signed emails are exempt from the rewrite rule, so now people are starting their emails with "BEGIN PGP MESSAGE" even though they haven't used PGP at all, just to fool the filter
Anybody sending malware links has probably also worked out that trick by now, thereby rendering the entire filter pointless' name='description'>
A trick which works if you use Mastodon, since that page is a Mastodon post:
Go to the Mastodon instance where you have an account, and paste the URL in the search box. It should load the post within your Mastodon instance (and allow you to boost/favorite/etc), without running any JavaScript from the post's instance.
(It won't surprise me if someday a Firefox plugin is created to open these Mastodon post pages without running their JavaScript, by detecting it's Mastodon and going through the same protocol as federated instances to fetch the content. Of course, it would be better if the Mastodon server software didn't require JavaScript for simply showing a post page in the first place.)
IMHO, there's definitely some security value is at least running a non-standard config.
Moving from seeing all attacks (even if blocked) to only targeted attacks decreases the amount of noise a detection system/reviewer has to deal with.
The important bit, though, is remembering only the above doesn't mean things that make it through are secure, which is usually where companies fall over. (I.e. implement dumb mail filter, then assume any mails that make it through are safe)
There was a time when prefacing your message with `begin 644` would hide your message, or the remainder of it, from users of MS Outlook. Maybe still works, who knows.
Readit News
I remember annoying friends in a mailing list by quoting emails with "begin quote from Person Name:" :)
I would love to see a link for this, blows my mind!
How do you escape the word From? Well, that's up to the client! Be careful using different clients for a given mbox file!
Email sucks :)
https://en.wikipedia.org/wiki/Mbox
treating data as privileged input was never out of fashion. last one in memory: google pixels modem accepting AT for custom firmware things from the outside. recommendation was "disable 4G and 3G until update" (which was the first one they delayed)
Deleted Comment
I think most punters sent large amounts of data in many consecutive IMs and hid the local modals so they didn’t punt themselves.
They used it intelligently during tournament, not overusing it, just making a particular player drop at the right moment and probably abused it for sometime before it became publicly known.
I don't remember if this was an issue also present in UT99 or just TO.
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).
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...
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.
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.
And the filter saw .dll and denied my request.
https://unix.stackexchange.com/questions/289999/how-to-zip-d...
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.
I can imagine some reasons why it would work better than merely checking the URLs when filtering: not rewriting but simply checking and scoring against other spam rules. But also see reasons why it secures less well.
Pro: you can block URLs post-delivery. E.g. an advisary changes the link to malware or phishing after some time/n requests/based on user agent. Con: all encryption, including DKIM, GPG etc break.
Edit: to clarify why I don't understand why this works: and advisary can still do the same: i.e. serve an innocent page to the checker but then a bad webpage to the actual visitor. Not trivial, but not hard either.
A good middle ground might be to scan URLs on the mailserver against lists and maybe open the page and scan its content before delivering. Then have the client intercept links and redirect them through another on-demand checker?
Because obviously, training people to "not click links in emails" or use only plain text or both, hasn't worked in the last decades.
Really can't understand who approved such things.
<meta content='Our university deployed a mail filter that rewrites URLs in emails to redirect them via a service that checks for bad websites. Somebody clever worked out that PGP-signed emails are exempt from the rewrite rule, so now people are starting their emails with "BEGIN PGP MESSAGE" even though they haven't used PGP at all, just to fool the filter
Anybody sending malware links has probably also worked out that trick by now, thereby rendering the entire filter pointless' name='description'>
Go to the Mastodon instance where you have an account, and paste the URL in the search box. It should load the post within your Mastodon instance (and allow you to boost/favorite/etc), without running any JavaScript from the post's instance.
(It won't surprise me if someday a Firefox plugin is created to open these Mastodon post pages without running their JavaScript, by detecting it's Mastodon and going through the same protocol as federated instances to fetch the content. Of course, it would be better if the Mastodon server software didn't require JavaScript for simply showing a post page in the first place.)
I guess the redirect and re-open on your own instance would be a feature for graze? IDK.
¹ https://addons.mozilla.org/en-US/firefox/addon/graze/
Moving from seeing all attacks (even if blocked) to only targeted attacks decreases the amount of noise a detection system/reviewer has to deal with.
The important bit, though, is remembering only the above doesn't mean things that make it through are secure, which is usually where companies fall over. (I.e. implement dumb mail filter, then assume any mails that make it through are safe)
The disadvantage is that threads don't render.
Should start giving people your public key then!