Bringing down the house, a.k.a. losing 20+-years old attachment to the email attachments

It’s been 20+ years since we observed the first mail worms out there (VBS files, SHS files, Macro viruses). I think it’s time to start thinking of reasonable measures that can stop these infections/propagation efforts. It’s easy to talk about macroviruses hidden in attachments, same as we did in1999, but it’s shocking to discuss this in 2018. And the problem is much wider – it’s any attachment that can be processed in a way that is undesirable…

The solution is simple:

  • Disable all email attachments, by default.
  • Enable email attachments only as per business need.
  • Encourage non-attachment file exchange+formal protocol for file exchange (email/slack/microsoft teams/skype for business conversation prior to sending, so it’s expected, whitelisting senders, etc.).
  • And for every email attachment that actually passed through the first line of defense checks, run through a sandbox, observe behavior, block if malware.

It’s a pretty simple algorithm. One that may actually work. And AFAIK it’s been utilized for at least 5 years in many setups.

Yet… day by day, month, by month, we discover new file extensions that can sneak in through a poor man’s blocking device which is ‘block files with the extension xyz’. Again, instead of blocking everything by default, we only block using a small number of file extensions. This is a wishful thinking.

Why do we do it this way?

I have no idea. It seems to be a standard.

Even if we all know the good ol’ firewall rules of thumb: first block everything by default, and then enable as per need, via a formalized process, we still let attachments fly.

But it’s 2018. The era of a smarpthone, Dropbox, and other cloud solutions.

Coming back to blocking… let me repeat: if we can block _all_ email attachments, and then only allow some per business needs we are already establishing some control over the environment that has not been a subject to such scrutiny. This is good news.

So…. In case you are wondering… why block all, for good?

Well… what about the fact that an email is an archaic way of communication?  And email attachments are even more archaic. To send one via email vs. to upload it to cloud is a great test of sender’s capabilities/access to modern solutions. It’s almost like sending via fax vs. email 10 years ago. Email attachments should simply die, peacefully, but quickly.

Plus, blocking by extensions is a whack-a-mole game. Every day you can find users installing new cool tools that ‘takes care’ of many new file extensions (see examples below) + they are often real vulnerabilities, 0days are not impossible.
So, even if you block 200 file extensions, there could be still one that you don’t know about, and which may help to exploit or bypass some security control.

And so that we are more specific – with regards to programs ‘handling’ more than they should….there is a Winzip registering handling ‘by default’ for these files extensions:

There is Winrar for these as well:

And it’s just a tip of the iceberg.

One could e.g. send .ace files, .vmdk files. As long as these popular archivers are installed and associated with the respective file extensions, any sort of trickery using these files is actually very feasible.

And to expand on this: Office, Acrobat, Libre, Office-wannabes and clones, Flash, Adobe products, programming editors, file managers, even sysinternals tools add a lot of Registry entries that will be accessed anytime the program-specific file will be opened e.g. via a double click in Windows Explorer. Again, so many opportunities for an abuse.

It’s actually a lost battle, if you want to chase after each new file extensions, the only way to tackle it is to block everything seen as an attachment by default, and manage exclusions as per need. While it doesn’t resolve all issues, it helps to mitigate many.

And.. why not… maybe there is a need for non-technical people to convey business in 2018 using other, more secure means than e-mail; e.g. ones that are company specific, and can be as simple as using a private cloud to exchange files, instead of emailing them. Dunno, this is a new way of thinking of it (despite this being a subject for discussions for many years), so there is no ‘good, one-and-only’ solution as of now. Since we know what the problem is, perhaps one comprehensive solution will eventually emerge….

Blocking attachments by a file extensions can be a good defense-in-depth approach, but real-life case scenarios teach us that it is a reactive way to react to techniques that are at least 20 years old. I think we can do better… And on that note, a file extensions is nothing when compared to analysis of an internal structure of the attached file. Sending a CSV file with an extension XLS, or RTF with an extension .docx will make Office application open these files no matter what, and in a format they ‘feel’ the most ‘comfy’ with. Internal conversions may happen on the way. Some of them may require manual confirmation, but still, who out of all users understands the quirks of file formats? Especially these that involve macros (again, this is a common occurrence of non-malicious macros)?

And by an example… When we see a csv file extension in the attachment …. Is it a CSV file, a Word Document, an Excel, or even an Access file? Is it written using the old document-writing routine (OLE compound file), or a new one – the zip archive format (Office 2007+). Is it malicious? or shows traces of possibly malicious activity? Is it handled properly by an assigned application?

Despite Windows 10 being really “security-conscious”, the 3rd party tools will imho remain a big problem that can’t be tackled w/o some dramatic changes to the way we do things today. Perhaps starting with a ‘simple’ thing like dropping by default email attachments… or at least quarantining all of them.

Beyond good ol’ Run key, Part 94

This is a short post to cover a ‘new feature’ of Windows 10 that some users complain about online.

When you use this ugly system for a while, and at some time need to restart it, you may notice that sometimes applications that are running prior to restart are re-launched after you log on.

A good example is Regedit. If you open it, restart the system, the application will be re-launched after the reboot.

How does the Windows 10 know which processes to re-launch after the reboot?

Prior to restart the system populates the RunOnce key adding a list of items in a form of:

  • HKCU\SOFTWARE\Microsoft\
    Windows\CurrentVersion\
    RunOnce\Application Restart #N
    =<Application Path>

where N is a number (the code is inside the winsrvext.dll).

So, if you come across entries like this, at least we can guess where they come from.

Now, how does the OS actually know which programs to restart?

If you ever used OSX you may be familiar with the a cool feature of re-opening currently opened applications after the reboot. Could that be that Windows 10 is following this path? Turns out that the truth is far more boring. This is actually not a Mac OSX-like feature at all. The OS simply grabs a list of programs that called the RegisterApplicationRestart API during their run-time, and only these will be added to the RunOnce key.

Last, but not least, I have no idea why Regedit calls this API at all…

btw. I am getting old, I covered it in the past here, although in a different context.