Windows 10 UAC File Protection Loopholes

[Andy Ful]

Windows Default File System Permissions trigger UAC prompt, when the file is copied to 'C:\Windows', 'C:\Program Files', and 'C:\Program Files (x86)' folders. But, there are some well-known exceptions in earlier Windows versions. A few 'C:\Windows' subfolders are writable without UAC prompt, and the files can even be executed from there.
It is not good for the security software, based on file whitelisting. In Windows 10 some writable 'C:\Windows' subfolders are now protected, and deny execution. Anyway, it is not true that the problem is solved.
Below, I sum up tests with Sysinternals AccessEnum utility on Windows 10 Pro (1607):
R = read, W = write, X = execute, O = blocked

Not protected (writable, and allow execution):
RWX C:\Windows\servicing\Packages
RWX C:\WINDOWS\servicing\Sessions
RWX C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
RWX C:\Windows\System32\spool\drivers\color
OWX C:\Windows\System32\Tasks
OWX C:\Windows\SysWOW64\Tasks
RWX C:\Windows\System32\Tasks\Microsoft\Windows\PLA\System
RWX C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
OWX C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
OWX C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
RWX C:\Windows\Tasks
OWX C:\Windows\Temp

Protected (if writable then deny execution):
OOO C:\Windows\PLA\Reports
OOO C:\Windows\PLA\Rules
OOO C:\Windows\PLA\Templates
RWO C:\Windows\Registration\CRMLog
ROX C:\windows\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
OOO C:\Windows\System32\Com\dmp
OOO C:\Windows\SysWOW64\Com\dmp
RWO C:\Windows\System32\FxsTmp
RWO C:\Windows\SysWOW64\FxsTmp
OOO C:\Windows\System32\LogFiles\WMI
OOO C:\Windows\System32\spool\PRINTERS
OOO C:\Windows\System32\spool\SERVERS
ROO C:\Windows\System32\Tasks\Microsoft\Windows\PLA
ROO C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA
RWO C:\Windows\tracing

There are many unprotected folders left.
I am curious if the execution from unprotected folders can be safely blocked with Software Restriction Policies?

 

[509322]

I am curious if the execution from unprotected folders can be safely blocked with Software Restriction Policies?

Yes.

These RWX directories have been known for years - at least since XP.

 

[Andy Ful]

Yes.

These RWX directories have been known for years - at least since XP.

Thanks. I suspect so. In Windows 10 things are slightly different than in prior versions. The Windows updates cannot be simply disabled, and enabled only when the user wants. So, the user in Windows 10 Home cannot disable SRP when updating. Anyway, I think that most updates use Trusted Installer or Administrator, and can easily bypass SRP.
Yet, some Windows scheduled tasks can run with a medium integrity level, and in theory, they can be stopped by SRP. How this was solved in AppGuard?

 

[509322]

Thanks. I suspect so. In Windows 10 things are slightly different than in prior versions. The Windows updates cannot be simply disabled, and enabled only when the user wants. So, the user in Windows 10 Home cannot disable SRP when updating. Anyway, I think that most updates use Trusted Installer or Administrator, and can easily bypass SRP.
Yet, some Windows scheduled tasks can run with a medium integrity level, and in theory, they can be stopped by SRP. How this was solved in AppGuard?

In AppGuard, you can disable it before any Microsoft\Windows update, but you don't have to.

AppGuard incorporates best practice by not interfering with Windows' core functionality - the same as any other security soft - so as not to cause issues for the user.

AppGuard policy is independent of a process' integrity level. It functions on the "What is not allowed by policy, is blocked" principle.

The user can configure all of the directories you mention in your OP within AppGuard for optimal security. Basically, create a generic deny execution policy for the writeable directories that permit execution. All that is involved is adding those directories to a list in AppGuard - and that's it, problem solved.

 

[Andy Ful]

So, for example, 'C:\Windows\Temp' folder is not blocked by default in AppGuard?

 

[509322]

So, for example, 'C:\Windows\Temp' folder is not blocked by default in AppGuard?

You mean totally blocked - R, W, X ? No. It will break updates of many softs.

The default policy is for the widest audience, but an advanced user can make the policy more strict.

The default AppGuard policy has everything needed to protect the system. Out-of-the-box it is already configured to provide extremely high physical system security.

A user can tighten policy by applying a generic deny execution policy to C:\Windows\Temp, and then excluding updater files (e.g. *.tmp) from that generic deny execution policy.

Making these kinds of changes to default AppGuard policy takes about 20 seconds and is simple.

 

[Andy Ful]

Thanks. AppGuard is well thought-out software.
SRP is less restrictive than AppGuard, because it blocks only processes on the medium integrity level or lower. Most Windows tasks can run/install/update in SRP protected C:\Windows\Temp folder. So, some users add C:\Windows\Temp to SRP blacklist. But, there is really a little information how it works in daily life.

 

[509322]

Thanks. AppGuard is well thought-out software.
SRP is less restrictive than AppGuard, because it blocks only processes on the medium integrity level or lower. Most Windows tasks can run/install/update in SRP protected C:\Windows\Temp folder. So, some users add C:\Windows\Temp to SRP blacklist. But, there is really a little information how it works in daily life.

AppGuard dispalys a warning if a user attempts to create block exeuction rules for processes located in C:\Windows\* .

The user can still create the rules.

Programs added to the Guarded Apps list - for example browsers, office suite programs, PDF editors\readers, archivers, etc (commonly exploited programs) - cannot write to System Space - which includes C:\Windows\Temp - unless the user adds the program publisher to the Trusted Publisher List or creates a policy exception for Read\Write access to C:\Windows\Temp\* (explicit file-path).

Also, updaters that launch from User Space (e.g. AppData) cannot write to System Space unless the user adds the updater publisher to the Trusted Publisher List or creates a policy exception for Read\Write access to C:\Windows\Temp\* (explicit file-path).

A user can make C:\Windows\Temp Read\Write-only and deny execution. And based upon execution rights needed by installed programs from C:\Windows\Temp, can make exceptions to the deny execution.

It's pretty simple and works very well.

 

[Andy Ful]

So say AppGuard users.

 

[509322]

@Andy Ful

Note: O = Blocked does not cover scripts !

In other words, despite the added protections in W10, scripts can still execute for the execute = O (blocked) permission.

The implication is that a malicious *.lnk can http\s to one of those directories and run from System Space or if it uses a method to exceed the allowable Target size, it can create a complete script there.

Fewer folders are vulnerable to this attack, but still block execution rules should be created to protect against malicious file writes\executes: CRMLog, FxsTmp, tracing, etc

 

[Deleted member 178]

Thanks. AppGuard is well thought-out software.
SRP is less restrictive than AppGuard, because it blocks only processes on the medium integrity level or lower.

It is why we use Appguard

 

[Andy Ful]

@Andy Ful

Note: O = Blocked does not cover scripts !

Fewer folders are vulnerable to this attack, but still block execution rules should be created to protect against malicious file writes\executes: CRMLog, FxsTmp, tracing, etc

In Hard_Configurator there's an option to block execution of writable Windows subfolders (<Writable Win. Subfolders>). Recently I made some tests, and it seems that this option has no impact on the system.

 

[Andy Ful]

@Andy Ful

Note: O = Blocked does not cover scripts !

In other words, despite the added protections in W10, scripts can still execute for the execute = O (blocked) permission.

I think that this can be covered in Windows 7+ by disabling powershell script execution, and blocking scripts by SRP in the User Space (CMD host and Windows Script Host). Using default deny SRP, with blacklisted writable Windows subfolders, can be OK until the system will not be exploited in some way.

 

[DJ Panda]

Does UAC at max protect itself better? Being seemingly more strict..

 

[cruelsister]

There are a number of tried and true ways around UAC, even at the Max. I'll actually be doing one this weekend.

 

[Handsome Recluse]

There are a number of tried and true ways around UAC, even at the Max. I'll actually be doing one this weekend.

Meaning in a way that allows it to escape its isolation? Also does UAC in admin protection differ from SUA?

 

[Deleted member 178]

Does UAC at max protect itself better? Being seemingly more strict..

yes and especially if you are on SUA. Also to bypass UAC , the malware must be able to bypass Smartscreen and WinDef too.

I'll actually be doing one this weekend.

If you test UAC , just be sure to not disable WD and Smartscreen; if you do your test will be pointless.

Malware must be downloaded on your testing OS , not ported from another source , if not you invalidate Smartscreen effectiveness.

 

[Handsome Recluse]

yes and especially if you are on SUA. Also to bypass UAC , the malware must be able to bypass Smartscreen and WinDef too.


If you test UAC , just be sure to not disable WD and Smartscreen; if you do your test will be pointless.

Malware must be downloaded on your testing OS , not ported from another source , if not you invalidate Smartscreen effectiveness.

She's probably gonna use 7 though since it's more common.
Loophole.

 

[Deleted member 178]

seems probable

 

[shmu26]

The default AppGuard policy has everything needed to protect the system. Out-of-the-box it is already configured to provide extremely high physical system security.

Could you explain how AG default policy stops these writable and executable places in the Windows folder from being abused?