Maximising Windows 7 security with SRP under LUA (whatever the win7 version)

This may be a little off the topic since it concerns XP SP3 fully updated, but the XP thread seems dead. When I installed Surun and SRP on my machine yesterday I created a situation where Firefox can't load the Flashgot add-on. The message indicates that SRP has rejected a policy violation. The former administrator account is now a user account under Surun. The other Firefox add-ons loaded normally. How do I work around this?

Thanks

Wuthering

 

If you want to check that your permissions are configured correctly, you may wish to try Windows Permission Identifier (free). Users of LUA should check out example #1 in the aforementioned thread. Users of SRP or AppLocker should check out example #2.

 

I know this topic is old but for 64bit Win 7

you should include this path in the additional rule for exemption

C:\Program Files (x86)

Cheers

 

I have compiled a list of files or folders in the Windows folder or Program Files folder which a standard (i.e. limited) user can write to and execute. These results were compiled on Windows 7 Ultimate x64, but may also apply to other editions and versions of Windows 7.

Update: this list was corrected in the next post.

Files/folders that are both writable and executable by a standard user:
c:\windows\debug\WIA
c:\windows\debug\WIA\wiatrace.log
c:\windows\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
c:\windows\System32\spool\drivers\color
c:\windows\System32\Tasks
c:\windows\System32\Tasks\computername
c:\windows\System32\Tasks\WPD
c:\windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
c:\windows\System32\Tasks\Microsoft\Windows\PLA\System
c:\windows\System32\Tasks\Microsoft\Windows\SideShow\SessionAgent
c:\windows\SysWOW64\Tasks
c:\windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
c:\windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
c:\windows\Tasks
c:\windows\Temp
c:\windows\Temp\MPTelemetrySubmit

Here is the full list of potential writables that I compiled before weeding out items that either couldn't be written to or executed:
ape c:\windows\debug\WIA - execute
ap c:\windows\debug\WIA\wiatrace.log - execute
ape c:\windows\Registration\CRMLog - no execute
ape c:\windows\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} - execute
ape c:\windows\System32\com\dmp - no execute
ape c:\windows\System32\FxsTmp - no execute
ap c:\windows\System32\spool\PRINTERS - no execute
ap c:\windows\System32\spool\drivers\color - execute
ape c:\windows\System32\Tasks - execute
a e c:\windows\System32\Tasks\Microsoft\Windows\SyncCenter - no create
a c:\windows\System32\Tasks\Microsoft\Windows\MemoryDiagnostic\CorruptionDetector - no create
a c:\windows\System32\Tasks\Microsoft\Windows\MemoryDiagnostic\DecompressionFailureDetector - no create
a c:\windows\System32\Tasks\Microsoft\Windows\WindowsColorSystem\Calibration Loader - no execute
a c:\windows\System32\Tasks\computername - execute
a c:\windows\System32\Tasks\WPD - execute
a e c:\windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update - execute
a e c:\windows\System32\Tasks\Microsoft\Windows\PLA\System - execute
a c:\windows\System32\Tasks\Microsoft\Windows\CertificateServicesClient\UserTask-Roam - no execute
a c:\windows\System32\Tasks\Microsoft\Windows\SideShow\SessionAgent - execute
ape c:\windows\SysWOW64\com\dmp - no execute
ape c:\windows\SysWOW64\FxsTmp - no execute
ape c:\windows\SysWOW64\Tasks - execute
a e c:\windows\SysWOW64\Tasks\Microsoft\Windows\SyncCenter - no create
a e c:\windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update - execute
a e c:\windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System - execute
ape c:\windows\Tasks - execute
ape c:\windows\Temp - execute
a c:\windows\Temp\MPTelemetrySubmit - execute
ape c:\windows\tracing - no execute

Legend:
a=found with AccessChk run elevated (run for standard account and separately for each group due to this issue)
p=found with Windows Permission Identifier
e=found with AccessEnum run elevated

Note: no files/folders from Program Files (or Program Files (x86) either) are listed because no issues were found within these folders.

Note: you may have more vulnerable files/folders on your system due to 3rd party programs. For example, on my system, there is another vulnerable file from a 3rd party program which I didn't list here because it's not included in Windows.

 

I didn't take into consideration whether a standard user could change permissions to allow execution. The corrected lists are given below.

Files/folders that are both writable and executable (or can be made executable) by a standard user:
c:\windows\debug\WIA
c:\windows\debug\WIA\wiatrace.log
c:\windows\Registration\CRMLog
c:\windows\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
c:\windows\System32\com\dmp
c:\windows\System32\FxsTmp
c:\windows\System32\spool\PRINTERS
c:\windows\System32\spool\drivers\color
c:\windows\System32\Tasks
c:\windows\System32\Tasks\computername
c:\windows\System32\Tasks\WPD
c:\windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
c:\windows\System32\Tasks\Microsoft\Windows\PLA\System
c:\windows\System32\Tasks\Microsoft\Windows\SideShow\SessionAgent
c:\windows\SysWOW64\com\dmp
c:\windows\SysWOW64\FxsTmp
c:\windows\SysWOW64\Tasks
c:\windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
c:\windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
c:\windows\Tasks
c:\windows\Temp
c:\windows\Temp\MPTelemetrySubmit
c:\windows\tracing

Here is the full list of potential writables that I compiled before weeding out items that either couldn't be written to or executed:
ape c:\windows\debug\WIA - execute
ap c:\windows\debug\WIA\wiatrace.log - execute
ape c:\windows\Registration\CRMLog - execute
ape c:\windows\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} - execute
ape c:\windows\System32\com\dmp - execute
ape c:\windows\System32\FxsTmp - execute
ap c:\windows\System32\spool\PRINTERS - execute
ap c:\windows\System32\spool\drivers\color - execute
ape c:\windows\System32\Tasks - execute
a e c:\windows\System32\Tasks\Microsoft\Windows\SyncCenter - create folder but not file
a c:\windows\System32\Tasks\Microsoft\Windows\MemoryDiagnostic\CorruptionDetector - delete but not write
a c:\windows\System32\Tasks\Microsoft\Windows\MemoryDiagnostic\DecompressionFailureDetector - delete but not write
a c:\windows\System32\Tasks\Microsoft\Windows\WindowsColorSystem\Calibration Loader - no execute
a c:\windows\System32\Tasks\computername - execute
a c:\windows\System32\Tasks\WPD - execute
a e c:\windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update - execute
a e c:\windows\System32\Tasks\Microsoft\Windows\PLA\System - execute
a c:\windows\System32\Tasks\Microsoft\Windows\CertificateServicesClient\UserTask-Roam - no execute
a c:\windows\System32\Tasks\Microsoft\Windows\SideShow\SessionAgent - execute
ape c:\windows\SysWOW64\com\dmp - execute
ape c:\windows\SysWOW64\FxsTmp - execute
ape c:\windows\SysWOW64\Tasks - execute
a e c:\windows\SysWOW64\Tasks\Microsoft\Windows\SyncCenter - create folder but not file
a e c:\windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update - execute
a e c:\windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System - execute
ape c:\windows\Tasks - execute
ape c:\windows\Temp - execute
a c:\windows\Temp\MPTelemetrySubmit - execute
ape c:\windows\tracing - execute

Legend:
a=found with AccessChk run elevated (run for standard account and separately for each group due to this issue)
p=found with Windows Permission Identifier
e=found with AccessEnum run elevated

 

Given the information in my prior post, I made some AppLocker policies. You could instead use SRP, HIPS, or access control entries if you don't or can't use AppLocker.

My AppLocker policies for Executable Rules are as follows:
-Allow Administrators to execute anything
-Allow Everyone to execute in \Program Files
-Allow Everyone to execute in \Windows, with these 14 exceptions:
c:\windows\debug\WIA\*
c:\windows\Registration\CRMLog\*
c:\windows\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\*
c:\windows\System32\com\dmp\*
c:\windows\System32\FxsTmp\*
c:\windows\System32\spool\PRINTERS\*
c:\windows\System32\spool\drivers\color\*
c:\windows\System32\Tasks\*
c:\windows\SysWOW64\com\dmp\*
c:\windows\SysWOW64\FxsTmp\*
c:\windows\SysWOW64\Tasks\*
c:\windows\Tasks\*
c:\windows\Temp\*
c:\windows\tracing\*

I also made similar AppLocker policies for Windows Installer Rules, Script Rules, and DLL Rules. In all cases I generated the default rules and then modified them.

These AppLocker policies have caused me no issues thus far. I anticipate though that blocking execution in c:\windows\Temp to all users except Administrators will cause problems with some 3rd party programs.

 

Thanks for this MrBrian!

 

You're welcome .

These AppLocker policies hasn't blocked anything on my computer thus far, except for when I was testing the rules.

 

Groovy Security in Windows 7 has some interesting information about both AppLocker and SRP in Windows 7:

 

I posted my complete AppLocker ruleset at https://www.wilderssecurity.com/showpost.php?p=1679077&postcount=7.

 

When I created post #30, I noticed that AccessEnum v1.32 missed \windows\System32\spool\drivers\color and \windows\System32\spool\PRINTERS but never bothered to investigate why. I looked into it today, and discovered that file redirection on x64 is the culprit.

Update: supplemental use of the \windows\sysnative folder alias for \windows\system32 works correctly though.

From the aforementioned link: