I’m posting in this forum because we are already using a file system mini filter driver, but I am open for suggestions outside the file system as well (and assume that this might even by necessary).
We have written a device management solution that enables our customer to define rules for storage devices. The rules control whether files on the device may be read, written, executed or even whether they appear in the directory.
The current solution can forbid all access to exe files in order to stop someone from bringing harmful software into the workplace. It can also forbid all access to zip files (or similar container formats).
The problem here is that if an employee needs to work with zip archives on external storage devices, they can easily use them and extract and execute an exe file.
What can we implement to offer protection for this use case? We are looking for a generic solution that not only works with zip archives, but also rar, … and even Word documents.
The second weakness of our current solution is regarding virtualization. Let’s say that our filter driver doesn’t allow access to exe files, but an employee has access to VMware or similar. He could therefore use device passthrough to attach a storage device directly to a virtual machine where our software is not running. That way, he can access all his forbidden external files, copy them to the virtualization host and execute them there. Our file system filter driver cannot stop him, as device passtrough works on a far lower level.
Is there any hope to interfere here? What kind of filter drivers or kernel hooking techniques might we implement to fix this weakness?
I do not understand the issue with ZIP files, or removable storage. If
it is on the system with the filter, the EXE will still be prevented from
executing; right?
Not much you can do in the VM situation; unless you also prevent the
virtualization software from running.
On Fri, Apr 7, 2017 at 9:40 AM wrote:
> Hello everyone, > > I’m posting in this forum because we are already using a file system mini > filter driver, but I am open for suggestions outside the file system as > well (and assume that this might even by necessary). > > We have written a device management solution that enables our customer to > define rules for storage devices. The rules control whether files on the > device may be read, written, executed or even whether they appear in the > directory. > > The current solution can forbid all access to exe files in order to stop > someone from bringing harmful software into the workplace. It can also > forbid all access to zip files (or similar container formats). > The problem here is that if an employee needs to work with zip archives on > external storage devices, they can easily use them and extract and execute > an exe file. > > What can we implement to offer protection for this use case? We are > looking for a generic solution that not only works with zip archives, but > also rar, … and even Word documents. > > > The second weakness of our current solution is regarding virtualization. > Let’s say that our filter driver doesn’t allow access to exe files, but an > employee has access to VMware or similar. He could therefore use device > passthrough to attach a storage device directly to a virtual machine where > our software is not running. That way, he can access all his forbidden > external files, copy them to the virtualization host and execute them > there. Our file system filter driver cannot stop him, as device passtrough > works on a far lower level. > > Is there any hope to interfere here? What kind of filter drivers or kernel > hooking techniques might we implement to fix this weakness? > > I’m thankful for any insights. > > — > NTFSD is sponsored by OSR > > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:>
You are right, our filter driver could easily prevent the execution of any exe files. The problem here is to decide which files to block.
If we block all exe files without exception, Windows will not function anymore - no surprise here. Even only allowing system exe files is to restricting, the user still must be able to do whatever it is he gets paid for.
We want to stop exe files coming from external devices, but we have a hard time recognizing that an exe file comes from a zip archive on a usb stick.
The best idea we’ve got is to remember whether a process had contact with a file on an external storage. If the same process tries to create an executable file afterwards, we stop it from doing so.
You will find your problem much easier to solve if you focus on blocking the execution of programs based on criteria like the contents of the PE (including digital signatures) rather than preventing users from copying such programs onto their systems.
In addition to the ones you have mentioned, there are numerable additional ways in which a PE image may become present on the local hard drive of a machine. Consider an HTTP put request or TFTP IN. It is impossible for your software to recognize all possible in box and 3rd party software that might allow files from remote locations to enter the system, and thereby differentiate them from other programs that simply read and write local files, and even if you did, you cannot prevent the user from compiling source or entering a binary manually. Even if you attempt to do so by blocking the saving of files with certain extensions, remember that the file extension has no bearing whatsoever on anything except the default actions from the shell. I can perfectly well save or compile my program to the file something.nothing and then readily run this from task manager or a command prompt as long as the file itself contains a valid PE image.
Also, there are many programs that write files in parts and or contain psudo-executable code like PDF automation or office macros.
This I why the best mechanism yet proposed on this list for preventing unauthorized file copies from USB keys is IMHO hot glue in the socket. Low tech, but just as effective as everything else.
From: xxxxx@materna.demailto:xxxxx Sent: April 10, 2017 2:44 AM To: Windows File Systems Devs Interest Listmailto:xxxxx Subject: RE:[ntfsd] Extending reach of file system filter across archives and virtualization
You are right, our filter driver could easily prevent the execution of any exe files. The problem here is to decide which files to block.
If we block all exe files without exception, Windows will not function anymore - no surprise here. Even only allowing system exe files is to restricting, the user still must be able to do whatever it is he gets paid for.
We want to stop exe files coming from external devices, but we have a hard time recognizing that an exe file comes from a zip archive on a usb stick.
The best idea we’ve got is to remember whether a process had contact with a file on an external storage. If the same process tries to create an executable file afterwards, we stop it from doing so.
— NTFSD is sponsored by OSR
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
We know that there will always be possibilities for a user to get and execute their own binaries. But we can happily ignore this as we are selling a device management solution, not a do-it-all security suite
Hot glue in socket is naturally the most reliable solution, but sadly cannot be adjusted to allow specific access while disallowing other.
Which leaves us with your first point: I concur, that would be easier. But again as a device management solution, a natural requirement is to use the origin of the executable file as a blocking criterion.
Given your very narrow scope here, I would say that your task is impossible on account of being fundamentally incompatible with the design of Windows (as well as every other OS I have worked with).
As a ?work around? you can track the ?origin? of all ?interesting? files on the system and recognize common decompression tools (windows explorer, Winzip, winrar etc.) and block the CreateFile calls they issue when extracting .exe files from restricted ?sources?. This would be a huge task to develop even moderate coverage of common tools, and cannot possibly be comprehensive, but it might work for you.
From: xxxxx@materna.demailto:xxxxx Sent: April 11, 2017 2:45 AM To: Windows File Systems Devs Interest Listmailto:xxxxx Subject: RE:[ntfsd] Extending reach of file system filter across archives and virtualization
We know that there will always be possibilities for a user to get and execute their own binaries. But we can happily ignore this as we are selling a device management solution, not a do-it-all security suite
Hot glue in socket is naturally the most reliable solution, but sadly cannot be adjusted to allow specific access while disallowing other.
Which leaves us with your first point: I concur, that would be easier. But again as a device management solution, a natural requirement is to use the origin of the executable file as a blocking criterion.
— NTFSD is sponsored by OSR
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
