Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
Guides - Privacy & Security Tips
How do Software Restriction Policies work (part 2) ?
Message
<blockquote data-quote="Andy Ful" data-source="post: 607440" data-attributes="member: 32260"><p><strong>In the part 1 - <a href="https://malwaretips.com/posts/606523/" target="_blank">Secure Windows - How do Software Restriction Policies work (part 1) ?</a> - the first layer of SRP protection was introduced.</strong></p><p>It is related to <strong>'Designated File Types'</strong> list (DFT) and <strong>ShellExecute()</strong> API function. If the file extension is on DFT list, then ShellExecute() can prevent that file from opening.</p><p>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:</p><p>'mshta.exe %Userprofile%\Desktop\How2BeReach.hta',</p><p>then ShellExecute() will be skipped, and SRP will not know that something is going to be executed.</p><p></p><p>Now, Windows has two possibilities:</p><p>1. Allow to open the file.</p><p>2. Use another mechanism to call into SRP.</p><p></p><p>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.</p><p></p><p>In some special cases Windows will use the 'point 2' solution, anyway. There are some <strong>Privileged Objects</strong>: <strong>'CMD Host', 'Windows Script Host', and 'Windows Installer'</strong>. 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).</p><p></p><p>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().</p><p>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:</p><p>ShellExecute() can block the (A) but cannot block (B).</p><p>Privileged Objects can block both (A) and (B).</p><p>Finally, Privileged Objects can block supported files even when those files have changed extensions.</p><p></p><p>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.</p><p></p><p>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:</p><p><strong>* by extension (DFT list, ShellExecute());</strong></p><p><strong>* by Privileged Objects ('CMD Host', 'Windows Script Host', and 'Windows Installer').</strong></p><p></p><p>The same applies to SCR files that use ShellExecute() to find out, that they are just a special kind of EXE files.</p><p>The native Windows executables: COM and EXE files, are always executed without invoking ShellExecute(). Instead of this, the API function <strong>CreateProcess()</strong> is used, and it can also call into SRP to block COM, EXE (and SCR) files.</p><p></p><p>There's another API function, that can call into SRP. The <strong>LoadLibrary()</strong> 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):</p><p>InstallUtil.exe /logfile= /LogToConsole=false /U malicious.dll</p><p>regsvcs.exe malicious.dll</p><p>regasm.exe /U malicious.dll</p><p>regsvr32 /s /u malicious.dll</p><p>regsvr32 /s malicious.dll</p><p>rundll32 malicious.dll,EntryPoint</p><p></p><p><strong>SRP have three enforcement settings:</strong></p><p>* No Enforcement - ignores 'DFT list + ShellExecute() + CreateProcess() + LoadLibrary()' calls. SRP will only answer the calls from 'CMD Host', 'Windows Script Host' and 'Windows Installer'.</p><p>* 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.</p><p>* All files - activates all SRP security layers.</p><p><strong></strong></p><p><strong>The protection applied by: CreateProcess(), LoadLibrary(), CMD Host, Windows Script Host, and Windows Installer, can work even when files have changed extensions.</strong></p><p></p><p>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.</p><p></p><p><strong>End of part 2.</strong></p></blockquote><p></p>
[QUOTE="Andy Ful, post: 607440, member: 32260"] [B]In the part 1 - [URL='https://malwaretips.com/posts/606523/']Secure Windows - How do Software Restriction Policies work (part 1) ?[/URL] - the first layer of SRP protection was introduced.[/B] It is related to [B]'Designated File Types'[/B] list (DFT) and [B]ShellExecute()[/B] 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 [B]Privileged Objects[/B]: [B]'CMD Host', 'Windows Script Host', and 'Windows Installer'[/B]. 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: [B]* by extension (DFT list, ShellExecute()); * by Privileged Objects ('CMD Host', 'Windows Script Host', and 'Windows Installer').[/B] 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 [B]CreateProcess()[/B] 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 [B]LoadLibrary()[/B] 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 [B]SRP have three enforcement settings:[/B] * 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. [B] The protection applied by: CreateProcess(), LoadLibrary(), CMD Host, Windows Script Host, and Windows Installer, can work even when files have changed extensions.[/B] 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. [B]End of part 2.[/B] [/QUOTE]
Insert quotes…
Verification
Post reply
Top
