Windows hardening (part 2)

Double-clicking on a file from Explorer has different effects that depend on the file extension. There are different file types, like .bat, .cmd, .js, and .reg and a double-click does not open those files in a text editor, but their content gets parsed and executed.

From a usability perspective, it’s not so good, as a single action (double-clicking on an icon), it has a different effect depending on the file type, even for text files (and most people do not know by heart the whole list of file extensions that get executed, myself included). From a security perspective, it’s also not so good, as, accustomed to double-clicking a file to see its content, a user might execute something by accident.

Some file managers, like caja (a file manager mainly for non-Windows systems), makes it possible to change the default behavior. Unfortunately, Windows Explorer does not have such an option.

It is possible to change the default file association for all those file types, for example with

After applying those changes, double-clicking on foo.bat will open the file with the text editor, and not execute the content. Also from the right-click menu, the open option, will invoke the editor, while Run as administrator will execute the file as it used to.

For example, from powershell, it is possible to execute the file as earlier: & .\foo.bat, but & .\foo.reg will open it with the associated editor. It’s unclear to me why such a difference exists and how to make the behavior consistent, but it might not be that important.

If we want to execute somehow those file types from Explorer (instead of opening a command or PowerShell prompt), it might be better to rename the default open key and add a new one

And an even better approach might be to reuse the possibly already existing "edit" option from the context menu instead of using the same editor for everything

This way, the default action to execute the file is saved in the context menu entry Run, while double-clicking on the file will open it with notepad++, or the default program for editing those files.

Similar changes can be made for other file types like .exe, .com, .msi, and so on.

Unfortunately, these settings do not control only the behavior of the file manager, but also the default behavior in many more contexts.

If a program tries to execute, for example, foo.cmd, it will now open it with the chosen editor, which is not the intended action.

It is possible to fix those issues by declaring with which program the script needs to be executed, for example, cmd /c myscript.cmd. As such commands might be buried inside programs, where the user has no chance to adapt them, it is not always possible to revert the unintended side effects.

Therefore, on a system where there is not much control over which software gets installed, changing default file associations might not be a good idea.

On the other hand, from a security perspective, it would be a big win if the user must make a distinct action to execute some code. It would not be possible anymore to execute some code accidentally while thinking to open a file.

Unfortunately, I do not use Windows as my primary system, and even if, my usage is hardly comparable to the usage of most Windows users, as I tend to disable some programs, I avoid installing a lot of software, and I hardly use an office suite, because I prefer simple text files.

The biggest advantage of this approach is that it can help a lot with social engineering attacks.

With those settings applied, instead of teaching people not to open anything they do not know, an attacker needs to convince someone to "execute", and not simply "open" a file. This is not impossible, but harder to exploit. And it is also easier to teach as a possible security issue: "Do not execute an unknown program."/"Do not execute programs not approved by the administration."

In scripting languages, like a .bat, .cmd or .ps1 file, instead of opening the file, you should invoke explicitly with what you want to execute it:

In C (and languages that can interoperate with C), it is possible to open and execute external files and programs through a function, and they will behave like double-clicking in explorer.exe.

The functions are ShellExecute* ^🗄️.

so if you are executing a .bat file from C with (just using ShellExecuteW as an example, similar adaptations need to be done for the other variants)

or

then the behavior of these programs depends on how the users open by default a .bat file and will break with this hardening settings.

The correct approach would be to state that we want to execute the .bat file, and not do what the user normally does:

The solution is indeed similar to script files, but without source code, it’s hard to impossible to change a broken program.

At least requesting a fix, if the program is still maintained, should be easy.

For testing purposes, it is possible to create a simple wrapper around ShellExecute. (NOTE: For simplicity and brevity, I used the ANSI version to avoid compiler flags fiddling between the Microsoft compiler and GCC, using the WIDE version is left as an exercise for the reader.)

Currently a CMakeLists.txt like

is sufficient.

Notice that this is not production-ready code, as at least the parameter handling has known bugs, and if ShellExecuteA fails, some information except the error code could be provided to stderr.

and try to see the difference between shellexecute foo.bat and shellexecute -parameters "/C foo.bat" cmd.exe.

Without those hardening settings, both commands should behave the same. With the hardening policy, the first should open the text editor, while the second will still parse and execute the script.

The same holds for shellexecute foo.reg and shellexecute -parameters "foo.reg" regedit.exe.

This, of course, works as long as the registry key open for exefile is unchanged. If this gets changed to showing some information about the executable instead of executing it, invoking ShellExecute* will show the information about the executable file.

There is no way about it, except for using another API.

The CreateProcess* ^🗄️ family functions are those responsible for creating processes, and they do not depend on file types and program associations.

A simple wrapper, again, for simplicity and brevity, around the ANSI API, and again, without proper error handling:

An example usage would be createprocess "cmd /c foo.cmd" or createprocess "regedit foo.reg", and it will execute the binary, regardless of what the user preference is.

This is a bold move as if some internal component of Windows uses the default file association for executing files, it might make the system unstable.

Of course, this is a limited issue if we change the file associations for single users, but I’m changing the default file association system-wide.

For simplicity, I’ve associated notepad.exe as the default program, but it would make sense to associate another program that explains how to execute the binary file, or why the file does not get executed with a double-click.

To understand if such an approach can help, or is just a theoretical improvement from the security perspective, I’ve looked at how the most famous viruses spread.

As I do not have so many first-hand experiences with viruses, I searched for "famous" computer viruses.

The analysis is simple, as it is obvious that those mitigations will only help against specific threats: when the user thinks to open a file, but instead executes an executable.

Some of the described attacks could have been mitigated by blacklisting common double extensions or by showing file extensions.

Preventing an attack might not be entirely possible, as the attacker can always convince, through social engineering, the user to rename the file.

For example, supposing file extensions are hidden but we have deployed the double-extension blacklist the attacker could claim that some Windows version has problems visualizing the attachment, and the user should rename it without the file extension. Thus, if the attached file is foo.doc.exe Windows would display an error, but if the user renames it to foo.exe (the .exe is not shown in the File Manager), it gets executed without issues.

Also notice that instead of opening Notepad, as I did for testing, it is possible to execute another program that shows some information about the executable, a help message that explains how to execute the file, provides an option to call the IT department, something like Windows SmartScreen but without sending executables to Microsoft, etc.

With these settings, the attacker needs to convince the user to left-click the executable and click on run to view the file. This is a much higher bar than simply double-clicking (and eventually renaming) a file looking like a PDF and claiming that it is a very important document.

Of course if, for example, the mail client or a web browser provides the option to open directly files, and uses internally Createprocess* instead of ShellExecute, these changes won’t help much. (and since both Firefox and Thunderbird open a downloaded executable with Notepad, I’m happy that they do not blindly call Createprocess*).

Nevertheless, it reduces the attack surface, and it might be possible to convince the authors of those programs, if they exist, that executing files from unknown sources is a security hazard, and that in this context, CreateProcess is normally not what the user wants.

It seems that this approach would have avoided the diffusion of different worldwide viruses in their current form.

Other attacks would have come through unchanged, those that relied on

This journey began because I dislike the default behavior of the file manager, which does not provide the option not to execute programs on a double-click, while another file manager (mainly in the GNU/Linux World) permits it.

There are alternative file managers, like explorer++, which do not permit (yet) to change this particular behavior.

I did not like this approach for the same reason I do not like the approaches to replace notepad.exe.

It has consequences that are not always easy to foresee.

Just look at all the issues changing the default file association for .exe has.

I guess that replacing explorer.exe with something else will probably have all the same issues. And what if a future Windows update breaks the program? Granted, most of those problems are also present when changing the file association, but at least it’s easy to oversee the necessary changes.

Those are the same reasons I’ve never tried Open Shell before, but being unable to start a program from the start menu makes this hardening configuration a no-go for most use cases.

I hope that changing file association is seen as a configuration that should be supported, and as it should be "easy" to fix most programs, it does not encounter much resistance.

Arguing that third-party programs break other programs tends to give a response that the fault is on the other side, and it might not always be wrong.

Another option might be that Microsoft realizes the potential benefit of such a configuration for the file manager without affecting (for the sake of compatibility) other programs. This would be a win-win situation, as most viruses rely on social engineering and will have a much harder time, and nearly no program needs any update or hack to continue to work.

Maybe changing the default file association is not the right way to go, even if the system seems usable.

Programs that rely on starting automatically might have a hard time (like the guest additions of VirtualBox), so it might not be a viable approach unless the end-user has some time to fiddle with single program settings.

Replacing the file manager, just like using open-shell for having a working start menu, is probably a more stable approach. But it won’t save all those attacks that manage to convince the end-user to open an attachment where the mail client (or browser) gives the possibility to open a file directly, which most do.

I was also hoping for a solution that does not require installing any additional software, as I did not want to add new functionalities.

I would thus not recommend that less tech-savvy people change the association of .exefile as it has some issues (most notably startup programs).

Changing file associations for scripts is as problematic, but there are fewer programs (and most importantly, fewer internal Windows programs) that rely on scripts.

After all, I’m glad that everything nearly worked, I’m going to see what happens and how projects react to such bug reports.