Starting emails with "BEGIN PGP MESSAGE" will fool the filter
nondeterministic.computer
nondeterministic.computer
I remember annoying friends in a mailing list by quoting emails with "begin quote from Person Name:" :)
This is known since at least 2004, with workarounds (https://link.springer.com/article/10.1186/1471-2105-5-80), yet people still use Excel instead of learning a bit about proper data storage. In my lab I sent a mail with the steps to harden Excel against this "bug". Want to guess how many did it? Zero.
Excel is second after Access for bottom-up developed data storage. And since Access is all but gone, it's absolutely not surprising people reach for Excel.
I would love to see a link for this, blows my mind!
Outlook Express: https://www.betaarchive.com/wiki/index.php?title=Microsoft_K...
Outlook: https://www.betaarchive.com/wiki/index.php?title=Microsoft_K...
Seems sensible.
The bug here was not "begin" followed by two spaces, but rather its "begin" followed by some other text followed by two spaces, which if i recall correctly is exactly what Microsoft would auto-format your text to.
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 :)
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)
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.
- Steven Seagull
- Sylvester StallionI think most punters sent large amounts of data in many consecutive IMs and hid the local modals so they didn’t punt themselves.
I'm pretty sure these Netgear routers were trying to create an automatic port forwarding rule so the DCC connection would work through NAT without any configuration.
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).
https://unix.stackexchange.com/questions/289999/how-to-zip-d...
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.
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.
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 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.
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.
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...
And the filter saw .dll and denied my request.
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.
That way, for a "normal human" it works like they expect, is technically correct, and doesn't trigger on backends fetching the resource. Unless they fetch the resource with some headless chrome or such. Which, unfortunately, is rather necessary these days.
Don't do this, most bots now actually load JavaScript.
Still, corporate email belongs to the employer.
For "magic links", It doesn't solve the problem that the email is intended for a specific individual, for one time use, and the filters are not aware or intelligent enough to do so.
In other cases privacy and security of the communication in some cases is being compromised.
It does give rise to a bootstrapped solution that delivers links well so I guess that's good.
<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.
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)
head {display:block; background:Canvas; color:CanvasText;}
meta[content] {display:block; padding-bottom:1em;}
meta[content]::after{content:attr(content); display:block;}The disadvantage is that threads don't render.
Twitter has to be bad by virtue of being a corporation driven by profit motive and requiring JS to collect and sell user data. Mastodon doesn't have to be crap since it is not required to generate maximum profit. It just chooses to be as shown from the content being in the HTML but hidden. This makes Mastodon worse. Either it's malicious or, more likely, incompetent cargo culting of corporate practices. Devs unable to separate themselves from the use-cases they have to develop for at their paid jobs or lacking the knowledge to do so.
Should start giving people your public key then!
Now I'm thinking if there was some smart idea behind that trying to fool some filters.
----- BEGIN EDIT -----
I can see it from the mastadon app but not in browser. I took a screenshot for others: https://i.imgur.com/q3DA7wQ.png
Text is:
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
@martin@nondeterministic.computer----- END EDIT -----
But I have an interesting issue which is (presumably) related. I keep getting obviously spam emails in my gmail and Google has refused to do anything about it (after finally getting through to support). These are embarrassingly bad emails. Ones you'd expect a naive bayesian classifier to get near 100% accuracy on!
In the "to" address is something that's not even remotely my email. Suppose I'm godelski@gmail.com, the "to" has something like "robbert01@gmail.com" and always has a CC with a different number. Subject lines will be things like "confirmation of receipt" but in non-standard and inconsistent fonts. And the message body is that all too typical single image and claim of something like winning a home depot gift card. The "from" address is always some scammy looking address. So Naive Bayes should get it on just this alone!
But the weird thing is when you show the original message. There's PAGES of stuff in here (about 20 pages or 9.5k words)! All kinds of email conversations, things including stuff like "here is your one time <account> password", stuff in other languages, survey questions, conversations, and a lot more. I actually did a diff on a few of these and they're almost identical too! I can't help but think that these are some weird prompt injections. It looks like it is written by a madman, but it it's probably some "throw shit at the wall and see what sticks" kinda thing.
But the message ID always comes from some Microsoft (something like microsoftstore1.microsoft.com). This is where Google support said it isn't their problem and moved on. I'm pretty critical of LLMs and their ability to reason, but I feel often we're trying to turn humans into machines instead of letting them complement one another. And I think this is why so many business people like LLMs, because they think everything can be figured out with clear immutable rules. But the thing is that the environment always changes and you need something that's not only adaptable, but can reason AND understands the actual desired outcome that humans want.
I hope someone at Google pays attention. Because you can't just hand all thinking over to humans. We're not there yet and it's why everything is going to shit (not just Google)
You probably already know this, but the content of these headers is not relevant for email routing. The list of email addresses which will actually receive an email message can be found on the SMTP commands, which precede (and are independent from) the email headers and body. If you look closely at all headers, you can probably find it, since most SMTP servers AFAIK add one or more header fields containing the email address found on the SMTP command.
That's how BCC can work: the list of emails in the BCC is never sent within the email message (unlike TO or CC), they are only sent on the SMTP commands.
But I was suggesting that the actual content in the headers should be providing a hint at spam. Because if something like being "from" home depot shouldn't match with an edu domain. Still, these emails are just wild and I'm very upset that google will do nothing about them. I get them at least once a week.
And it is unfortunately hard to switch emails... I'm in the process by trying to create unique emails with a relay service so I can just redirect, but still....
As already mentioned, the email might also be encrypted (the most common case). Then the signature would not be available as it would be hidden under the encryption. These sorts of filtering issues are why corporate cybersecurity people, somewhat ironically, tend to dislike encrypted email. There is an opportunity here to make better email clients that treat encrypted, but unsigned, emails with suspicion.
This is a bypass game on something like proof point url protection that rewrites URLs to go through a central redirect so that reputation check can be separated from reputation delivery, usage detected, and one liner URLs still work. I’m over a decade out of this space so take with a grain of salt.
The tool could do a better job inspecting “oh that’s a pgp formatted massage”. You could probably just route them all to spam and almost no one would notice.
Yeah you at Proton. I'm talking to you.
Stop doing this.
No touchy the email.
Also, DKIM can optionally be lax about whitespace.