Hacker News Reader

Comment by lifeisstillgood | Hacker News Reader

tl;dr using an old but still valid OLE component, you can embed any exe in a word doc, convert to rich text, that then faithfully re-expands the exe onto users runtime when they open the word doc - a perfect malware delivery method that if correct has almost no defence beyond ... Plain text emails.

(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.

View on HN

>> One suspects that a lot of spear-phishers 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.]

Alas, if only you could move away from Outlook.

To what?

GMail works OK for me. Mutt does, too, but in a very different way.

> you can disguise any exe as a rich text word doc that then faithfully re-expands the exe onto users runtime when the open the word doc

...and click through the warning.

If they are worried enough (that their boss has sent them a report to be checked by 4:30 or else) to open a doc in a mail, then they are worried / dumb enough to click through the warning (NB I comtract in Fortune 500 and every time I open my own excel file on my own desktop I have to click through three yes/no. It's no longer a defence)

Yea, I was waiting to see the "and to disable the warning" part of the tutorial. But to be fair, even though you or I would be stopped by the warning, most people wouldn't.

Really OLE needs to be deprecated and removed. It's ancient cruddy technology. It needs to die like ActiveX and <IE11

Like ActiveX? A Microsoft ActiveX control is essentially a simple OLE object that supports the IUnknown interface.

No actual Word doc is involved here - only the pretense of one. This is functionality supported by Outlook directly.

>> (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) I'm really surprised that those dedicated anti-spam components like Barracuda, or those enterprise apps like ESET which hook into Exchange, don't perform this sort of analysis already. The volume of incoming mail even for a large organization would be pretty easy to analyze every single byte of every single message coming in and check it for certain things.

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[1]. 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.

[1] https://technet.microsoft.com/en-us/library/dd723683(v=ws.10...

Application whitelisting is a great idea, but there's simply too much management overhead for it to feasible in anything but the most security-conscious environments. In a large network (WRT number of users), you're gonna need an FTE just to keep the policies/hashes updated (we tried it on a small scale years ago at a previous job and quickly abandoned the idea).

FWIW, I do have Barracuda spam appliances and I'd bet $10 that they don't catch this.

Options like the Barracuda, or something like FireEye or Cisco's AMP may detect this, but even doing a full virtualized Windows environment like FireEye does (at rather high cost!) can be tricky. How do you reliably detect in dynamic analysis that Word has unpacked an executable if it doesn't do anything?

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.

He does work in corp sec trying to stop spearphishers who target food processors. I think the point is to educate other IT staff while trying convince MS to provide more security controls for OLE. Glad to see doc on the ShowOLEPackageObj reg key which I was unaware. EMET also helpful.

Reply on news.ycombinator.com