(The firewall would need to re-expand the rich text using this OLE, then scan the word doc, then repackage. Unsurprisingly nothing on market seems to. Jeez - stick to plain text)
One suspects that a lot of spear-phisers know about this already.
We have seen this attack vector. We have seen key-loggers, as well as crypto-locker Trojans, delivered in this way.
It has been an up hill battle educating staff who view themselves as non-computer people, but we are getting there. Most staff have come to think as safe behind our spam, content, and security filters, and getting them to think critically about whether they should open an attachment has been very difficult.
[edit / I press 'submit' too early and my comment was incomplete.]
...and click through the warning.
Really OLE needs to be deprecated and removed. It's ancient cruddy technology. It needs to die like ActiveX and <IE11
Barracuda rack-servers' sole purpose is to block spam and viruses, do they really not do deep-inspection? I mean every Win32 binary, even if packed, compressed, dynamically self-modifying, whatever, still needs an entry point. Those bytes still need to be embedded into your plain text somewhere, even if it isn't via the SMTP attachment standard. The attack vector surely must have some commonality (haven't read any post mortems but if it's an OLE exploit, "contentType="application/vnd.ms-word" is going to be there in straight up ASCII).
Either way, one might not know what's in a binary, but you can definitively determine when something is a binary, at which point, anything which isn't white-listed doesn't get in. Is this just a matter of network admin's not being able to be aggressive enough with their filtering policies and/or GPO? The next line of defense would be to only let white-listed signed apps run which is fairly trivial with Win 10. Disable the ability to install extensions in your white-listed browser (Firefox Youtube Downloader Plus!! Awesome!! is likely to have adware that's bundled in), disable Flash, and one would have a pretty sanitary network right?
Edit: Yeah, I should have finished reading the article. He mentioned application whitelisting too as a defense. Critical environments with good security will not be effected by this. Also, the author mentioned "most" anti-viruses won't detect this-- I don't have a Barracuda box to test against, but I'll bet $10 it catches this. So yeah, there are (quite a few) defenses within a properly locked down environment.
Clever find though.
Dynamic analysis for malware is a great idea but it can definitely be bypassed, usually very trivially. It comes down to the inherent complexity of the computer. There are a lot of ways to pack executables, and there are a lot of ways to make executables appear to not do anything malicious, so even if you use a full environment for dynamic testing it may not be easy to tell whether or not something bad has happened.
On the other hand, what's being delivered does matter, and detection might be better if it had a real payload rather than a demonstration. A direct payload or a request for a second-stage binary are all things that dynamic or static antimalware systems can try to pick up.
FWIW, I do have Barracuda spam appliances and I'd bet $10 that they don't catch this.
I look at the various clients/interfaces and test each of them to see how their controls compare. It's quite often that certain clients or interfaces have far less security on them than others because it simply isn't convenient.
One example would be two-factor on a VPS administration page. It's on the main site, but if you download the mobile app it's password only.
Which means...it's password only (assuming you know how to use a proxy like Burp).
So important to ensure that all interfaces to your app have the same minimum requirements for security.
If not, good catch, that's a glaring issue and a great attack vector as you could likely script away emulating the traffic of the device, and you've got a decent chance that since they're using a different authentication method, maybe rate limiting wouldn't be factored in as well.
Out of curiosity, what else do you audit?
Well, you might want to read the article again. See now the difference?
I found this trick, we used to play doom and rise of the triad with this and some other glue. I am surprised this trick still works so well for foxing security checkers
Better duplicate management is something we're working on. Keep in mind, though, that HN doesn't consider a post a duplicate until the story has had significant discussion. Otherwise too many good stories would go unnoticed.
Anyways, I think this case with URLs not being completely the same but directing to the same page should be pointed out and discussed.
My submission linked to:
While this submission links to:
Doesn't this leave room for multiple "spammy" posts?
I think it's indeed only worthwhile pointing to an existing thread if there is already a valuable discussion.
And I totally regret pointing it out since my karma has suffered great damage...
Still, one can take down all the new stories if they want, to promote their content for example, by using such methods.
Wish I could just delete my parent post but unfortunately I can't...
Are reposts ok?
If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok.
Code that can go through is a bug. Usually a buffer overflow, but in this case, it's a specification bug back from the days when the world wasn't so networked.
Also, I think you meant steganography.
That's not it. Just read any magazine from that year. Everybody thought it was a terrible idea, just as autorun.exe was completely insane. Viruses was a huge problem at the time, and they spread via infected floppies or CDs and documents. So automatically running embedded code if possible even worse back then. But they went with it anyway. It's good as long as it moves the goal posts for the competition. The business case is not always the use case.
At least 2 clicks, one of which is a warning.
Although I accept the warnings are mostly pointless.
Every other mail system other than Outlook and Notes (and I say this having started my career as an NT4-era Windows person) has been incredibly successful at blocking executable code in email messages in comparison. Safe defaults are hard, but they're also a minimum expectation of software these days.
To further back this up, I'm sure newer Outlook apps (eg, the iOS one) definitely do not have this issue.
I'm sure there's a great joke around that punchline, but I can't find it.