LUA + Applocker: what's the point using both?

If Applocker stops any executable file from running in the first place, what's the point of using a standard user account?

A standard user account would stop malware from writing in system folders, but applocker already stop malware from running, so if you have applocker, you don't need to use a LUA, right?

 

Not nessiceraly, but there are other practicalities involved

Compared with running Admin no UAC
With LUA and UAC higher rights objetcs are protected from tampering by lower rights objects. So this reduces intrusion surface of allowed applications

Compared running Admin with UAC default
With Windows7 UAC is less secure than LUA at dfault settings. Set UAC to full (so one click higher than default level), to get same scope of protection as LUA

Compared running Admin with Full UAC
a) LUA Prevents accidental allow of UAC prompt by (other) users on the PC
b) LUA allows security policies to be disabled for admin, this can be a more practical with updates etc

Regards Kees

 

So using UAC on full is practically the same as using LUA in terms of security?

I'm asking this because I have applocker. As I use applocker, malware will not run, so LUA is not necessary, unless other people use my PC, but that's not the case...

 

No. In short: UAC is not reliable. UAC is not a security boundary, but LUA is.

 

Despite's Windchild claim/warning, in your case it does the job (assuming you do not mindlessly click allow).

When you read our signatures, you can guess that WindChild and I have a common view on 90% of the secuirity issues. Due to this 10% difference we seem to disagree a lot

 

Well, 10 % is a lot more than 0 %, at least..

In the right hands, UAC can certainly "do the job", I agree. But, as I always like to say, in the right hands even a superuser account would do the job - that is to say, you can run as root or admin and avoid getting owned, it just takes either lots of luck or skill, or additional software for security. But if we're really going for security, then LUA beats UAC like a red-headed stepchild. LUA is solid, UAC is not - this is as designed by the developers of the operating system.

 

Right, especially when there're exploits that can blow right past UAC.

 

I'll assume in this post that you're running as admin with UAC disabled.

AppLocker doesn't apply to programmable material (such as Microsoft Office macros, PDF JavaScript, or browser JavaScript) that is interpreted by programs, with the exception of those script types blocked by AppLocker. So if you open a malicious Office document with a macro and allow the macro to execute, the Office program running the macro will be running as admin, and thus so will the malicious macro.

AppLocker also doesn't apply to shellcode run as a result of buffer overflow, because the shellcode is running in a program that AppLocker has already allowed to run. Typically though, the shellcode just downloads a file and tries to execute it, which would be blocked by AppLocker in most situations.

The AppLocker rules that you use should not be of the "allow all execution within Windows and Program Files folders" variety, because otherwise if shellcode downloads an executable to, for example, the Windows folder, then your AppLocker rules would allow it to execute.

Another issue to consider is what happens when you install a program - installation programs can use temporary files when installing. I guess you'd have to turn off AppLocker rule enforcement anytime a program is installed?

 

Actually I believe I'm wrong. The malware I tested installed only to user accessible folders without attempting system elevation, so UAC should not alert anyway. At least i think that's why I didn't see UAC alerts when I launched the test malware under my standard account.

An excellent explanation on UAC Processes and interactions with detail and color pics, without getting too technical:

http://technet.microsoft.com/en-us/library/dd835561(WS.10).aspx

Maybe running as administrator is not so bad after all (though clearly standard account is more secure) as long as UAC is set to admin approval mode on the secure desktop.

That's why I use the Autogenerate option and not the path with exceptions option

The admin has file execution rights so Applocker doesn't need to be disabled to facilitate the installation of a program, but if using Autogenerate for rules, then a new rule will need to be created for that new program.

 

Right, but how does one know ahead of time what, if any, temporary files are going to be created and executed by the installer?

 

I don't know. But does it matter as long as one trusts the file they're about to install? What harm are the temporary files?

 

But if one is running as admin with UAC off, and using Autogenerate to create AppLocker rules, neither the installer itself nor any other files the installer creates will be on the AppLocker whitelist, correct (unless they're covered by publisher rules)?

 

Well I'm not sure the installer needs to be on the whitelist. As for "any other" files, they may not need to be on it either. Only whatever's required to get the program to run correctly needs to be in the whitelist. Besides, it's easy to figure out if the program doesn't run properly: Computer Management-> Event Viewer-> Applications and Services logs-> Microsoft-> Windows-> Applocker...and the logs will reveal whatever Applocker blocked, so if it's a legit executable, then it's a simple matter of creating a rule for it.

 

Personally I keep UAC in silent mode, which has no prompts but still automatically limits and "virtualizes" most executables. The little shield icon is fully operational (it flags what needs admin rights), except without the nags.

If a trusted application needs full admin right, I just change its privilege level via compatibility properties.

If that did not exist, I would've certainly disabled the annoying UAC.. It's too troublesome creating rules for it.

 

Some thoughts about AppLocker + UAC enabled + admin UAC approval mode:

• You can use any of the AppLocker techniques described at Anyone running AppLocker?. In particular, you can (and IMHO should) keep the default rules for the Administrators group, since these rules apply only to elevated processes.
• You won't be able to audit permissions for the admin UAC approval mode account using AccessChk or Windows Permission Identifier because these programs assume the full admin token is being used instead of the more restricted admin token. You'll have to use AccessEnum instead.
• Due to the Using UAC elevation in Windows Explorer to view a folder creates access control entry issue, it's easy to allow more access than desired by the admin UAC approval mode account to some folders/files.

Some thoughts about AppLocker + UAC disabled + admin account:

• Using AppLocker path rules in this scenario is dangerous and not recommended. For example, if you use path rules for c:\windows\, and shellcode downloads an executable to the c:\windows folder, then your AppLocker rules would allow it to execute.
• The default AppLocker Administrators rules must not be used, because they allow everything in your admin account to run.
• Because the default AppLocker Administrators rules can't be used, installations can fail due to AppLocker blocking. To overcome this, there are several things you can do. First, you could turn off AppLocker enforcement during installations. Second, you could use a different admin account that's used only for installations, in conjunction with AppLocker rules that allow that admin account to run anything.

 

Consider what could happen if one encountered script shellcode (link courtesy of trismegistos) while running as full admin....