SRP: Protecting Windows Folder in Win 10

[softie15]

This is a spin-off from this more general thread. Since I plan to go into a lot of detail here that may need discussion, I did not want to pollute and side-track the original thread that's already growing.

This thread is specific to Win 10 Software Restriction Policies (SRP) Deny-all setup where some writable folders under C:\Windows are still writable by non-Admins and thus should be blacklisted explicitly.

Following instruction from the mechbgon article, I identified the following locations on my Win 10 Pro (1709) setup using accesscheck for Users, Everyone, Authenticated Users, and Interactive groups:
C:\Windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp

Here is the list of locations listed by @Andy Ful in the awesome Hard Configurator manual. For some reason, it does not match what I observe - perhaps because it's system specific? My comments are inline for each difference

c:\windows\servicing\Packages - not writable by Users, Everyone, Authenticated Users, and Interactive groups
c:\windows\servicing\Sessions - not writable by Users, Everyone, Authenticated Users, and Interactive groups
c:\windows\System32\Microsoft\Crypto\RSA\MachineKeys - did not find in my setup
c:\windows\System32\spool\drivers\color - matches one of mine
c:\windows\System32\Tasks - matches one of mine
c:\windows\SysWOW64\Tasks - matches one of mine
c:\windows\Tasks - matches one of mine
c:\windows\Temp - matches one of mine
c:\Windows\debug\WIA - did not find in my setup
c:\Windows\System32\Tasks_Migrated - did not find in my setup

Hard Configurator does not mention these 8 directories for Win 10 that I found have writable privs, (though I believe they might be included among the many other optional block-sponsor items due to being part of excubits.com list used by Hard Configurator):
C:\Windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp

Questions for @Andy Ful (and anyone else who might know):

(1) Is the approach (from the mechbgon article) I am using for identifying directories to blacklist correct?

(2) Should c:\windows\servicing\Packages and c:\windows\servicing\Sessions still be blacklisted?

(3) Do you see issues with blacklisting additional directories I found? Aside from the time I install print drivers, do you foresee something I should watch out for when adding those additional 8 directories that are not on the Hard Configurator list.

(4) Hard Configurator indicates it blacklists using the registry key. Is there any downside to instead adding explicit rules under SRP policies (like described in the mechbgon article)? I am guessing not, but does not hurt to check...

Thanks!

 

[MITKH]

hi
A good description
regurds

 

[shmu26]

Just wanted to make a general comment: The Windows folder is already protected quite well by Windows itself. Malware cannot install itself into the Windows folder without express permission from the user, unless it succeeds in escalating privileges (which is anyways pretty hard to do on Windows 10).
So the main effort in security should be placed in protecting user space, not system space. Because if you don't let malware run in user space, where it starts, it won't be able to escalate privileges and get into system space.

 

[Andy Ful]

The Windows folder is already protected quite well by Windows itself. Malware cannot install itself into the Windows folder without express permission from the user, unless it succeeds in escalating privileges (which is anyways pretty hard to do on Windows 10).
...

That is not true.
Windows 10 UAC file protection loopholes
.
@softie15
The article How to make a disallowed-by-default Software Restriction Policy (the mechbgon article) applies to Windows 8 and prior versions. My thread (look above) applies to Windows 10 1607. Some Windows folders may be absent on computers when they were not upgraded from the prior versions.

 

[shmu26]

That is not true.
SRP: Protecting Windows Folder in Win 10
.

Could you please explain a little, or maybe link me to an article or post? I must be missing a basic point. The link you provided just brought me back to this thread.
Appguard doesn't do much for protecting system space, and neither does NVT ERP at default settings. And Voodooshield leaves key areas of Windows folder alone.
The assumption is that malware starts in user space, is this not so?

EDIT: Regarding Appguard and the other security softs I mentioned, of course it protects system space, but not by blocking executions in system space. That is the point I was trying to make.

 

[Andy Ful]

Could you please explain a little, or maybe link me to an article or post? I must be missing a basic point. The link you provided just brought me back to this thread.
Appguard doesn't do much for protecting system space, and neither does NVT ERP at default settings. And Voodooshield leaves key areas of Windows folder alone.
The assumption is that malware starts in user space, is this not so?

EDIT: Perhaps we mean two different things? If you are talking about protecting vulnerable processes such as script interpreters, which reside in System32 and SYSWOW64 and other places in Windows folder, then yeah, they definitely need protection.

Ooops! Post edited. Thanks.
The right link:
Windows 10 UAC file protection loopholes
There are some folders in Windows (tested by me up to Windows 10 1607) that are writable and executable (admin rights not required). If I will have some time I repeat the test for Windows 10 1709. That is why there is an option <Protect Windows Folder> in Hard_Configurator.

 

[Andy Ful]

I made a quick test. The folders mentioned by @softie15 are still not protected in Windows 10 FCU, and the two folders:
c:\windows\servicing\Packages
c:\windows\servicing\Sessions
are indeed protected now (were not protected in Windows 10 v.1607).
.
Some folders mentioned by @softie15 are writable but anyway protected (not executable as standard user).

 

[shmu26]

Ooops! Post edited. Thanks.
The right link:
Windows 10 UAC file protection loopholes
There are some folders in Windows (tested by me up to Windows 10 1607) that are writable and executable (admin rights not required). If I will have some time I repeat the test for Windows 10 1709. That is why there is an option <Protect Windows Folder> in Hard_Configurator.

Thanks for link. Absolutely fascinating discussion. I didn't know about all that. So SRP can block more areas by default, because high integrity processes will be allowed. But Appguard doesn't look at integrity level, so by default it blocks less areas.

 

[Andy Ful]

Thanks for link. Absolutely fascinating discussion. I didn't know about all that. So SRP can block more areas by default, because high integrity processes will be allowed. But Appguard doesn't look at integrity level, so by default it blocks less areas.

Most software (Excubits drivers, AppGuard, etc.) block processes without looking at their rights. That can sometimes block a few Windows processes or scheduled tasks, so one can be very careful with blocking rules and some processes cannot be blocked safely. SRP can be set to block only processes run as standard user, so one can block safely more processes. For example, blocking the cmd.exe via SRP is rather safe, but not recommended via other programs.
.
I like SRP way of blocking, because it can hardly block something important for system maintenance and system stability, especially when applied via Hard_Configurator, because it allows blacklisting only predefined processes and locations.
Of course, SRP can be set to block processes as other programs do, but I could not recommend this for home users on Windows 10. I do not think, that blocking processes run as administrator is much safer on Windows Vista+. It assumes, that some malware/exploit is already running with admin rights and trying to run the payload. SRP (as standard user) cannot stop such payload and other programs (Excubits drivers, etc.) can. But, when the initial malware/exploit got the admin rights, the system is already compromised and can do much harm without the payload.
.
Summing up. SRP (block as standard user) + some Windows hardening can be more preventive (larger blocking area) but other programs (block also as admin) can have larger mitigation area.
The first is (in my opinion) better suited for home users, and the second is better in Enterprises (or maybe for advanced users). Here is a simple example:
When the user is going to open the downloaded CHM file it will be immediately blocked by SRP (the first scenario). In the second scenario, Windows will try to execute the sponsor hh.exe and this can be allowed/mitigated/blocked by the security program (Excubits drivers, AppGuard).

 

[Deleted member 178]

Appguard doesn't do much for protecting system space
The assumption is that malware starts in user space, is this not so?

Appguard is all about protecting System Space, even if a malware is already on the system. There is a test made by CS showing AG blocking malicious attempt.
Video Review - AppGuard on Windows 10- An Unconventional Use

So SRP can block more areas by default, because high integrity processes will be allowed. But Appguard doesn't look at integrity level, so by default it blocks less areas.

AG doesn't care of IL, it only cares about if the exe/dll/drivers is launched in System-Space or not (based on policy).

 

[shmu26]

Appguard is all about protecting System Space, even if a malware is already on the system. There is a test made by CS showing AG blocking malicious attempt.
Video Review - AppGuard on Windows 10- An Unconventional Use


AG doesn't care of IL, it only cares about if the exe/dll/drivers is launched in System-Space or not (based on policy).

Thanks for correction. I did not word my post clearly, because of course Appguard "protects" System Space, that's obvious. I meant to say that the way it protects system space is not by blocking executions in system space, but rather in user space.
Is that better?

 

[Deleted member 178]

Thanks for correction. I did not word my post clearly, because of course Appguard "protects" System Space, that's obvious. I meant to say that the way it protects system space is not by blocking executions in system space, but rather in user space.
Is that better?

Yes, be careful of your wordings, it can mislead readers.
small precision, C: is not fully in system-space, some areas in C are considered user-space.

 

[shmu26]

Yes, be careful of your wordings, it can mislead readers.
small precision, C: is not fully in system-space, some areas in C are considered user-space.

Umbra, you would make a good editor!

 

[softie15]

I made a quick test. The folders mentioned by @softie15 are still not protected in Windows 10 FCU, and the two folders:
c:\windows\servicing\Packages
c:\windows\servicing\Sessions
are indeed protected now (were not protected in Windows 10 v.1607).
.
Some folders mentioned by @softie15 are writable but anyway protected (not executable as standard user).

@Andy Ful ,
(1) do you mind letting us know which ones are writable but anyway protected in 1709?

(2) (learning to fish) how do you find (1)?
(2a) Your post said you ran AccessEnum but when I run it, it gives the UI without the clear RWXO setings. I did not find docs for this utility to indicate how to find RWXO list that you nicely summarized in your thread.
(2b) I think you are saying WO or OX are OK and belong to (1)?

(3) do you think it's safe to remove (1) from the explicit SRP Disallowed rules then? On further reading of posts like this one, seems like O setting is still vulnerable to script execution and thus, even "protected" folders are not really protected if writable by non-admins; and thus, should have corresponding SRP Disallowed rules... :-( Am I missing something?

 

[Andy Ful]

@Andy Ful ,
(1) do you mind letting me know which ones are writable but anyway protected in 1709

You can do it by yourself. Make the batch file that copies the executable to the tested path and next tries to execute this file. Run this batch as standard user. I think that the result will be like in Windows 10 UAC file protection loopholes
See also SRP: Protecting Windows Folder in Win 10
.

(2a) Your post said you ran AccessEnum but when I run it, it gives the UI without the clear RWXO setings. I did not find docs for this utility to indicate how to find RWXO list that you nicely summarized in your thread.

.
The RWXO are just the deduction based on the results of the executed batch and additionally the first 'O' is when the folder cannot be accessed from the Explorer.
.

(2b) I think you are saying WO or OX are OK and belong to (1)?

.
I found only OOO, RWO, ROX, ROO among protected folders and only RWO among writable but protected. There are more possibilities for protected folders, forbidden are only entries having both W and X (writable and executable).
.

(3) do you think it's safe to remove (1) from the explicit SRP blacklist then?

Adding them to the blacklist makes them double not executable (two protections). So, it won't hurt but won't help much, too.

 

[Andy Ful]

... seems like O setting is still vulnerable to script execution and thus, even "protected" folders are not really protected if writable by non-admins; and thus, should have corresponding SRP Disallowed rules... :-( Am I missing something?[/USER]

Windows Folder protection is prepared only for the native Windows executables: EXE, COM (SCR) files.
Double protection would be important only when the user could open such protected folder and tried executing the script by himself, then indeed in double protected folder the script will be blocked immediately via SRP DFT list. But, the malware/exploit can open the scripts via command line from everywhere - DFT list does not block this.
DFT list was made by Microsoft to protect the system from user's mistakes like trying to open the fake DOC file IloveYou.doc.exe . When you want to block command lines, then generally you have to block the sponsors or apply the concrete Windows policies.
The known exception is SRP Default Security Level = Disallowed, when the scripts hosted by CMD and Windows ScriptHost are blocked also when executed via command line (extended protection mentioned in Hard_Configurator manual). But in our case, SRP Default Security Level = "Basic User" + cmd.exe can be already blocked via SRP (blocked sponsor) + Windows ScriptHost can be blocked via policy, and you will get the same protection.
One could apply SRP Default Security Level = Disallowed, as well, but this would introduce some problems with shortcuts in the Userspace.

 

[shmu26]

This is a spin-off from this more general thread. Since I plan to go into a lot of detail here that may need discussion, I did not want to pollute and side-track the original thread that's already growing.

This thread is specific to Win 10 Software Restriction Policies (SRP) Deny-all setup where some writable folders under C:\Windows are still writable by non-Admins and thus should be blacklisted explicitly.

Following instruction from the mechbgon article, I identified the following locations on my Win 10 Pro (1709) setup using accesscheck for Users, Everyone, Authenticated Users, and Interactive groups:
C:\Windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp

Here is the list of locations listed by @Andy Ful in the awesome Hard Configurator manual. For some reason, it does not match what I observe - perhaps because it's system specific? My comments are inline for each difference

c:\windows\servicing\Packages - not writable by Users, Everyone, Authenticated Users, and Interactive groups
c:\windows\servicing\Sessions - not writable by Users, Everyone, Authenticated Users, and Interactive groups
c:\windows\System32\Microsoft\Crypto\RSA\MachineKeys - did not find in my setup
c:\windows\System32\spool\drivers\color - matches one of mine
c:\windows\System32\Tasks - matches one of mine
c:\windows\SysWOW64\Tasks - matches one of mine
c:\windows\Tasks - matches one of mine
c:\windows\Temp - matches one of mine
c:\Windows\debug\WIA - did not find in my setup
c:\Windows\System32\Tasks_Migrated - did not find in my setup

Hard Configurator does not mention these 8 directories for Win 10 that I found have writable privs, (though I believe they might be included among the many other optional block-sponsor items due to being part of excubits.com list used by Hard Configurator):
C:\Windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp

Questions for @Andy Ful (and anyone else who might know):

(1) Is the approach (from the mechbgon article) I am using for identifying directories to blacklist correct?

(2) Should c:\windows\servicing\Packages and c:\windows\servicing\Sessions still be blacklisted?

(3) Do you see issues with blacklisting additional directories I found? Aside from the time I install print drivers, do you foresee something I should watch out for when adding those additional 8 directories that are not on the Hard Configurator list.

(4) Hard Configurator indicates it blacklists using the registry key. Is there any downside to instead adding explicit rules under SRP policies (like described in the mechbgon article)? I am guessing not, but does not hurt to check...

Thanks!

Still scratching my head here and trying to understand.
In my Windows 10 Standard User Account, I tried to create a doc in Windows/temp, but I did not have permission even to access it. So why is it on the "writable" list?

 

[Andy Ful]

Still scratching my head here and trying to understand.
In my Windows 10 Standard User Account, I tried to create a doc in Windows/temp, but I did not have permission even to access it. So why is it on the "writable" list?

It has OWX = blocked access from Explorer + Writable + Executable.
Use command prompt as standard user to copy the EXE file to 'C:\Windows\Temp' and execute it also from the command prompt.

 

[Andy Ful]

Here is another way without using command prompt:

1. Copy/paste the executable myprog.exe to C:\Windows\Temp, via right click Explorer context menu (do not open the folder).
2. Use the command line: C:\Windows\Temp\myprog.exe in Explorer window to execute the myprog.exe

 

[softie15]

You can do it by yourself. Make the batch file that copies the executable to the tested path and next tries to execute this file. Run this batch as standard user. I think that the result will be like in Windows 10 UAC file protection loopholes

I tried the following: Default-Deny SRP without Windows Subdirectories rules (actually they are there Unrestricted), removed BAT from DFT.

As standard user, from command prompt, I was able to copy and execute a simple .bat script into each of the directories I identified in the OP. But I could not write to C:\Windows itself for example (as expected). Specifically, I could write and run in all these directories:
C:\Windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp

Now, I readded back BAT to DFT and tried same experiment with copying notepad.exe. In this case, I could copy it to all locations but not execute from most (again, from standard user command prompt). Following dirs are the only ones that executed it:

C:\Windows\System32\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp

(Minor note: for some reason notepad.exe did not pop up a window from these directories. It seems to have ran but did not do much. I think it might relate to some other protection I have perhaps - it just paused for a while and quit without any logs in Event Viewer. Only when I call notepad.exe from C:\Windows it actually pops up a window.)

So options appear to be:

- blacklist explicitly all 13 dirs from the OP (and implicitly all their subdirs) - this will make sure that if some file extension is missing from DFT, malware still cannot write it under Windows dir. I guess SRP would be useless against such extension anyway though - they could just write it to some User-Space directory and run it then. So, perhaps this option is uselesst then...?

- blacklist (i.e. SRP disallow rules) explicitly just the 5 directories from the second experiment, not all 13 - that's what you recommend, right? This one will protect DFT extensions (only)

- maybe even blacklist less locations by only blacklisting DIRECT members in the 5 locations (possible in gpedit?) and then figure out other subdirectories of them where direct files but not subdir need to be blacklisted. Your original post for example examined subdirectories even if their higher-up directories were already listed as not-protected. For example, only DIRECT members of
C:\Windows\SysWOW64\Tasks
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
need to be blacklisted, but not other subdirs of SysWOW64\Tasks.