Do you disable UAC?

Yes, I know M$ won't change this, but a bit of brainstorming doesn't hurt.

 

@Martin_C
Yes I know that it won't give much protection to Admin user. I just wanted to help @Hiltihome with his question. It would be much safer if user that can't be trusted is set as Standard user.

 

BTW, something that I still don't fully understand is what triggers a UAC alert. With that I mean, do apps always need to ask for elevation? Let's say some app wants to load a service or driver, but doesn't ask for elevation. Then I suppose it won't trigger a UAC alert, but it will fail to perform the action, is this correct? It's perhaps a bit of a silly question, but I can't fully visualize it. I have read about malware like ransomware, banking trojans and keyloggers that don't need admin rights, but I guess they are designed not to ask for elevation?

 

@Martin_C @minimalist13 :
I know about the limitations of UAC and the risks of letting users run a admin account.

Anyway, I want to lock the UAC setting to default, or hide the slider from UI, without hacking a dll, or so.
As there is no pre-built GPO template for it, I'm looking for a reg file, to do it.

 

I have the same impression...

 

no they don't , the problem are the devs who designed their softs to ask for it (bad habits induced by MS in the pre-vista world.)

However those tasks inherently will trigger UAC:

Code:

Tasks that require administrator privileges will trigger a UAC prompt (if UAC is enabled); they are typically marked by a security shield icon with the 4 colors of the Windows logo (in Vista and Windows Server 2008) or with two panels yellow and two blue (Windows 7, Windows Server 2008 R2 and later). In the case of executable files, the icon will have a security shield overlay. The following tasks require administrator privileges:[9][10]

-Running an Application as an Administrator
-Changes to system-wide settings or to files in %SystemRoot% or %ProgramFiles%
-Installing and uninstalling applications
-Installing device drivers
-Installing ActiveX controls
-Changing settings for Windows Firewall
-Changing UAC settings
-Configuring Windows Update
-Adding or removing user accounts
-Changing a user’s account type
-Configuring Parental Controls
-Running Task Scheduler
-Restoring backed-up system files
-Viewing or changing another user’s folders and files
-Running Disk Defragmenter
-Running Registry Editor
-Running the Windows Experience Index assessment

Common tasks, such as changing the time zone, do not require administrator privileges[11] (although changing the system time itself does, since the system time is commonly used in security protocols such as Kerberos). A number of tasks that required administrator privileges in earlier versions of Windows, such as installing critical Windows updates, no longer do so in Vista.[12] Any program can be run as administrator by right-clicking its icon and clicking "Run as administrator", except MSI or MSU packages as, due to their nature, if administrator rights will be required a prompt will usually be shown. Should this fail, the only workaround is to run a Command Prompt as an administrator and launch the MSI or MSP package from there.

If UAC is disabled, it will install, hence why UAC is important. reason why advanced malwares (rootkits, etc...) always look for a way to bypass/disable UAC.

if they change nothings in the areas mentioned above , they won't ask admin rights, so no UAC prompts.

those that needs admin right may not ask elevation because they exploit a legit process to avoid prompts; UAC on vista was the strongest UAC but people were annoyed by those perpetual prompts and complained , then MS "solved" the problem on Win7 by "whitelisting" more processes; hence making it more vulnerable.

 

I think you didn't fully understand my question. But I already answered my own question a few pages back, and I have found some more info. Because UAC is pre-execution based, it will never know why some app needs admin access, it only sees the request to elevate.

I just did some testing, I tried to install an app that doesn't ask for elevation, and it failed to install, plus UAC didn't alert me. So in other words, apps need to ask for elevation because UAC can't automatically detect if some app needs write access to system folders, or wants to perform other privileged stuff. If apps don't ask, they will simply fail to work correctly when UAC is enabled. If UAC is disabled, they will be able to auto-elevate.

 

BTW, this is what I mean, let's say that the Petya ransomware is delivered via exploit or attachment. There is always a 50% chance that a user will allow it to run. But if you use AE or sandboxing, it wouldn't run at all or remain contained in the virtual container. Of course, in theory these type of security tools can get bypassed, but it's not likely.

https://blog.malwarebytes.org/threat-analysis/2016/04/petya-ransomware/

Well, it's a little bit late to worry about trollers and spammers in this thread, but look at it from the bright side, after we're done with this topic, we will not discuss this subject in the coming 5 years or so.

 

Basically, if malware wants to remain stealth, it should be designed in a way that it doesn't need admin rights. Or it should either hope that UAC is disabled, or try to bypass it. Or they can gamble, because there is always a chance that users will click on yes, because most people don't know the risks of admin rights. That's why reducing UAC alerts is crucial, because currently people will most likely let apps elevate without thinking twice, because those alerts are frequent and expected. So they are not trained to be cautious.

 

It is what i told you since the very beginning UAC isn't a Behavior Blocker , just an elevation blocker. So an attempt to access to the area above , generate an UAC alert (or not depending the settings), that is it.

your test's description can't tell me much; which apps, what kind or user account , what level of UAC?

Exactly , you sum up the issue : "people just don't care" , UAC , in term of "security" isn't flawed by design , it is just annoying. I prioritize my security over annoyance, others don't...

if i could use a real life analogy to describe UAC:

i have a house with 3 floors (OS) , the 3rd floor is the place i gather my precious values (system area, registry, etc...), this 3rd floor is separated by an armored door with a digital lock; to access this floor , i have to get the authorization (admin rights) that is requested by the lock (UAC ).

UAC doesn't protect the whole house (security products does it), it hampers processes to reach the sensitive areas of the system.

 

@Martin_C @minimalist13 :

Eureka, I found out:

How to block UAC Control (slider) from user access:

1. Prevent UserAccountControlSettings.exe from running, using GPO.
2. Prevent UserAccountControlSettings.exe from running, using regedit.

Both approaches work. Registry key works on both, WIN-home and -pro.
Here is an example for current user:

Code:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"DisallowRun"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun]
"1"="useraccountcontrolsettings.exe"


#by Hiltihome#

A restart is required to make settings work.

 

Great! Thanks for sharing this solution.

 

Amen!

 

Explain what is the benefit of this? Just asking

 

That's very easy to explain:

I wanted to stop lazy users from changing the UAC settings.

You and others may agree, or not..., discuss all day and night,
but I insist in UAC settings to stay default.

That's why I asked "How to" and as I got no solution, I made one.

 

Very nice. I understand also

 

@Hiltihome :

The problem with your "solution" is that it is a pseudo-solution.

Blocking UserAccountControlSettings.exe from running will not lock the UAC level.

The set UAC level are not a single setting, but 10 settings.
The UserAccountControlSettings.exe will just present a user with a easy to handle slider in a nice UI.
What actually happens when the user moves the UAC slider, is that UserAccountControlSettings.exe will change the combination of those 10 settings.

The levels on the slider represents the standard levels and predefined combinations of the 10 underlying settings, but these can be made either more or less strict by changing the 10 settings either directly in registry or through GPO.

Since the user you have in mind are on an admin account, then the user can change these registry settings directly or through GPO.
And also anything that this user grants Admin privileges to later on, can do it for him/her.

By blocking UserAccountControlSettings.exe and thereby not having the UAC slider accessible to that admin user, you are not locking anything or making anything safer.

The OS does not care about the visual UAC slider. The OS only looks at the registry settings and if any policies are applied through GPOs.

Blocking UserAccountControlSettings.exe on an Admin account is like having a burglar in your home, throwing a blanket over him and then claim he's gone and the house is secure.

I do not post this to start an argument with you, but to make it clear for users who might find these posts through a search at a later time.

 

Yes, I know, but the confusion was about whether UAC knows it when apps are trying to modify system settings that require admin rights. The answer is: no it doesn't, it's a "dumb" elevated execution blocker. So I believe the Wikipedia article is a bit misleading or at least confusing. Instead of saying "Tasks that trigger a UAC prompt", it should have been "Tasks that require admin rights", because there is a difference.

It was tested with UAC on Max and I was running as protected admin. It seems that the app developer simply forgot to ask for elevation, so that's why it couldn't install. On the other hand, I just noticed that even with UAC disabled it can't install either, so there must be something weird going on. Because for some reason it doesn't auto-elevate with UAC turned off.

Yes, it's security versus convenience. This applies to other things as well, for example certain HIPS are way too noisy so I prefer not to use them. And I've also switched from online broker, because their "Two-factor authentication" system was too annoying, even though it was good for security.

 

@Martin_C :

Once again, this thread is causing controversy arguments, although you stated not to start an argument with me.

My solution does exactly what I was asking for.
It does block access to UAC settings for average users.
That is what I was asking for.
So it wouldn't call it a "pseudo-solution"

As for your warning to users, that come later here:
It's already to late....!

I

 

@Hiltihome i think you tagged the wrong person in your post above

 

THX, guest.

corrected it

 

@Hiltihome :

There's no reason for you to become upset, just because I make you and future readers of thread aware, that your "solution" does not do what you think it does.

Please reread what I posted a page back.

You are not locking UAC level for that Admin user you have in mind, by blocking UserAccountControlSettings.exe from running.

Again - UAC level are not a single setting, but 10 settings.
When moving UAC slider, UserAccountControlSettings.exe will change the combination of these 10 settings.

UserAccountControlSettings.exe are not enforcing anything.

UserAccountControlSettings.exe presents the user with a visual and if user changes UAC slider position, then UserAccountControlSettings.exe will alter the combination of the 10 settings that together represents the effective UAC level.

That is the sole purpose of UserAccountControlSettings.exe.

OS only cares about the 10 registry settings and if any policies are applied through GPOs.

You state that your target user is an average user and by removing a visual you think they can't change UAC level.

This is incorrect.

It does not matter if user is average, rocket scientist or anything in between.

Your target user are using an Admin account.

This means that whenever that Admin user runs anything, then that application can request elevated privileges.

The user are prompted with the UAC prompt.

When user clicks yes, then that application can change settings if it wants.
According to how it's done, your user might see another UAC prompt which he/she can just approve.

Nothing is locked to an Admin user or an application granted elevated privileges.

The UAC prompts are from Consent.exe, not from UserAccountControlSettings.exe

And a big warning in case you are now thinking - "Hey, then we just block both".

If you block Consent.exe from running, then your users will become very, very unhappy when updates malfunctions and when Admin duties will fail or loop.

On top of that, as already said, your user in mind with his/her Admin account and access to a Bing/Google search can learn in two minutes how to change the registry/GPO settings required to alter UAC level and has full access to do so since they are Admin.

Average or rocket scientist - anyone can do a search online.

And if you can't trust the user to not go into Control Panel and change UAC settings, then you can't trust the user not to do a online search.

Finally there's the UAC bypasses that are sadly possible if on an Admin account with UAC on default.

Long post short - you are not locking anything on that users Admin account by hiding a visual, no matter what. It's a smokescreen with zero effect.

Admin user can still change it, elevated applications can change it, bypasses fly by on default UAC level.

The correct approach are to make a Standard User Account for that user you have in mind, UAC on max and then inform the user about using the Standard User Account for all daily chores and only use Admin account for Admin duties.