Andy Ful

Level 40
Content Creator
Trusted
Verified
In the part 1 - Secure Windows - How do Software Restriction Policies work (part 1) ? - the first layer of SRP protection was introduced.
It is related to 'Designated File Types' list (DFT) and ShellExecute() API function. If the file extension is on DFT list, then ShellExecute() can prevent that file from opening.
Blocking files by ShellExecute() prevents users from unknowingly or accidentally executing malicious code, but files still can be opened by the system when using commands. If you choose to open HTA file directly, using the command:
'mshta.exe %Userprofile%\Desktop\How2BeReach.hta',
then ShellExecute() will be skipped, and SRP will not know that something is going to be executed.

Now, Windows has two possibilities:
1. Allow to open the file.
2. Use another mechanism to call into SRP.

In most cases Windows will follow the 'point 1'. So, users cannot open the files from DFT list by clicking the file icon on the Desktop, pressing Enter, choosing 'Open' or 'Open with ...' from Explorer context menu. This prevents fooling users to open double extension malware files like IamInnocentFile.pdf.exe (with PDF icon). The user can still try to open the file using the application that support opening it (sponsor). In the case of the above malware, the PDF viewer will run (with file opening error), and IamInnocentFile.pdf.exe will not be executed, at all. Yet, the files can be opened, when using commands.

In some special cases Windows will use the 'point 2' solution, anyway. There are some Privileged Objects: 'CMD Host', 'Windows Script Host', and 'Windows Installer'. They are prepared to call into SRP about supported files. So, in the case of the 'How2BeReach.vbs' file, it can be blocked, because 'Windows Script Host' can call into SRP about VBS files (even when VBS is not on DFT list).

It is worth mentioning, that above privileged objects can control file execution independely of ShellExecute() and DFT list. File blocking by 'Script Hosts' or 'Windows Installer' is also more comprehensive as compared to ShellExecute().
For example, the How2BeReach.vbs can be run by (A) double click from the Desktop or by (B) executing the command: 'wscript.exe %Userprofile%\How2BeReach.vbs'. If we add VBS extension to DFT list, then:
ShellExecute() can block the (A) but cannot block (B).
Privileged Objects can block both (A) and (B).
Finally, Privileged Objects can block supported files even when those files have changed extensions.

One can ask a question: what is the (B) protection for? Users, mostly run files by clicking, not by executing commands. That is true, but the autorun.inf on the pen drive or DVD disk, can execute commands. The same is true when the system or application is exploited, etc. So, the (B) protection is essential against many 'Drive By' attacks.

From the above considerations, we can conclude, that scripts: BAT, CMD, JS, JSE, VBS, VBS, WSF, WSH, and MSI files can be blocked in two independent ways:
* by extension (DFT list, ShellExecute());
* by Privileged Objects ('CMD Host', 'Windows Script Host', and 'Windows Installer').


The same applies to SCR files that use ShellExecute() to find out, that they are just a special kind of EXE files.
The native Windows executables: COM and EXE files, are always executed without invoking ShellExecute(). Instead of this, the API function CreateProcess() is used, and it can also call into SRP to block COM, EXE (and SCR) files.

There's another API function, that can call into SRP. The LoadLibrary() is invoked when EXE file is executed, and tries to load binary libraries (DLL and OCX files). SRP can be configured, either to allow or block loading libraries from specified locations. This layer of protection can stop many DLL attacks, when system files are used to load malicious libraries from the User Space (paths ommittet for simplicity):
InstallUtil.exe /logfile= /LogToConsole=false /U malicious.dll
regsvcs.exe malicious.dll
regasm.exe /U malicious.dll
regsvr32 /s /u malicious.dll
regsvr32 /s malicious.dll
rundll32 malicious.dll,EntryPoint

SRP have three enforcement settings:
* No Enforcement - ignores 'DFT list + ShellExecute() + CreateProcess() + LoadLibrary()' calls. SRP will only answer the calls from 'CMD Host', 'Windows Script Host' and 'Windows Installer'.
* Skip DLLs - ignores only LoadLibrary() calls - other security layers: 'DFT list + ShellExecute() + CreateProcess() + LoadLibrary()' + 'CMD Host' + 'Windows Script Host' + 'Windows Installer' calls are not ignored.
* All files - activates all SRP security layers.

The protection applied by: CreateProcess(), LoadLibrary(), CMD Host, Windows Script Host, and Windows Installer, can work even when files have changed extensions.


We see that 'All files' enforcement setting is the most powerful, but one should remember, that programs which use binary libraries located in the User Space, will not run properly. So, all those libraries have to be whitelisted.

End of part 2.
 
Last edited:

Andy Ful

Level 40
Content Creator
Trusted
Verified
I noticed a simple mistake in my tutorial. :oops:
I wrote:
SRP have three enforcement settings:
...
* Skip DLLs - ignores only LoadLibrary() calls - other security layers: 'DFT list + ShellExecute() + CreateProcess() + LoadLibrary() + 'CMD Host' + 'Windows Script Host' + 'Windows Installer' calls are not ignored.
...
Of course LoadLibrary() should be skipped!

I have to add the correction note according to COM files. There are two kinds of COM files in Windows XP+. The old type, 16Bit COM files, that can be are run in an MS-DOS-emulating subsystem NTVDM, which is present only in 32Bit Windows systems.
There are also 32Bit COM files, which are simply a special type of EXE files. So in fact, ShellExecute() is invoked when running COM files, and they are monitored by SRP when COM extension is on DFT list. Of course, all EXE like file types (32Bit COM, EXE, SCR) are also protected by CreateProcess().

The last thing to test: are 16Bit EXE and COM files also protected by SRP? I have to install 32 Bit virtual machine and find 16Bit program to check this. :(
 
Last edited by a moderator:
5

509322

The last thing to test: are 16Bit EXE and COM files also protected by SRP? I have to install 32 Bit virtual machine and find 16Bit program to check this. :(
Corner case. Relevant only to 32 bit systems - which are quite uncommon nowadays. Really only matters to those running on obsolete 32 bit systems. I haven't come across any 16 bit malware in a long time, but I'm sure its out there somewhere.
 

Danielx64

Level 10
Verified
At work, some computer accounts are configured so that programs can only be ran from the program files folder and windows folder. What would you have to say about that configuration? There are also other settings in place to stop the run option and command line from showing up.
 
  • Like
Reactions: Andy Ful
5

509322

Standard user accounts. Those computers are domain joined.
If they are using Pro or Education\Enterprise with properly configured Group Policy and\or AppLocker - along with the SUA, then that is fairly high physical system protection.
 
  • Like
Reactions: Andy Ful

Andy Ful

Level 40
Content Creator
Trusted
Verified
Finally, I tested 16 Bit COM, EXE files (in Vista Ultimate). SRP can block them as in the case of 32Bits, even when COM, EXE extensions are removed from 'Designated File Types' list . But, there is a strange behavior of ntvdm.exe - it can be partially blocked by SRP, so cannot be run from Explorer or from Command Prompt. Yet, when whitelisted EXE(COM) file has been executed, then ntvdm.exe proces is created, anyway. The system can run ntvdm.exe indirectly (with medium integrity level), bypassing SRP. I found out, that NTVDM subsystem can still be disrupted by SRP, when blocking ntvdmd.dll library - ntvdm.exe is started, but COM, EXE file is not executed.
 
Last edited:
  • Like
Reactions: Av Gurus