The irrelevance of Applocker / relevance of SAFE admin tweaks

Hi all,

Some statements to spice up the launch of SAFE admin

Applocker is the improved implementation of Software Restriction Policies, since it is based on white listing and security wise ends the weak path based rules setup of SRP.
Because Applocker can be tricky to setup, in every tutorial you get a warning in capitals to NOT remove the grant Admin/System full rights. So for every day Joe/Jane Applocker makes only sense when when you are running LUA.


When people are running LUA on company PC's without problems, why can't they run as LUA on their private PC also?
Rationally this is true, because of the lousy marketing of the LUA concept most PC owners run Admin, half of them switch UAC off. When I ask a friend/relative whether he/she want to be the driver or the mechanic of their PC they all choose driver. Nobody wants to be limited on the things they OWN, so the same question for Admin and Limited User, gets a 80% response in favour of Admin (after clarification what is admin). Microsoft disencouraged home users also, with their pricing scheme of the different Vista/Windows 7 versions. As a result, 80 percent of the Windows versions sold are home versions, so Applocker is really something for the priveledge ultimate owners.


So what is left for the rest of us?
SAFE admin, coming soon by Sully is based on the following principles

1. Reduce UAC elevation prompts to reduce user errors
a) Tweaking registry to disable UAC's ability to recognise installlers outside Windows and Program Files directories (the established 'safe' area). To install something a right click 'run as admin' is nessecary.
b) Giving internet facing applications Medium level rights (=LUA), when integrity level is set to medium, UAC won't auto elevate these aps. Ergo reducing unintentional allows on elevation prompts. Microsoft Update will still update Windows and other Microsoft application (windows update uses the browser, so you have to upgrade your updating mechansime).

2. Reduce the risk of drive by through selective deny-execute
a) Apply the 1806 trick through registry tweak. Establisk a deny execute/download of external code. Depending on your browser (IE disables download of executables, FF downloads a null file, Chrome downloads the file, but explorer blocks execution). With right click on properties this block can be removed before installing a program.
b) Remove the right to execute in specific user folders like the download folder of your browser and the folders where your e-mail is stored. Nice thing of Chrome is that you force it to download to a specific directory, so you are encapsulating the sandbox of Chrome in a second deny-execute folder.
c) b) Applying a registry tweak to allways check executables downloaded by browser or e-mail

3. Harden Windows to mitigate threats
a) Applying a registry tweak to prompt for non-signed driver install
b) Apply DEP for all programs
c) Apply SEHOP for all programs
d) Applying EMET on internet facing aps. EMET will provide more mitigation in the future
e) remove Autostart of USB


Watch for the announcement of SULLY when he launches SAFE admin
SAFE admin = enjoy LUA/ACL deny execute protection with ADMIN priviledges = Best Of Both worlds

SAFE versus Applocker
= will be free/cheaper
= uses less CPU cycles than Applocker (internally Applocker uses simular principles as certificates of SRP, just try using SRP certificates and see what warning you are faced "Are you sure, it will reduce performance")
= has on the fly switch ON/OFF flexibility

 

I am really at a loss with this one Kees. So are you saying the "every day Joe/Jane" should ignore a built in applocker and instead start hacking away at the registry? That's bound to cause some borked systems.

 

Sounds like a rational explanation to me!

I've never understood why you need to be prompted for elevation. Because if your Deny-Execute is Default-Deny and inclusive rather than selective, nothing will attempt to elevate without your permission because nothing can execute without your permission.

Once you have eliminated the drive-by threat through inclusive Default Deny (which includes proper browser configuration), the only other threat is when you are tricked (social engineering) and you grant installation (elevation) privileges for the download/install.

And for good reason, for SRP and AppLocker are beyond the ability of the average user to understand and configure, in my view

Heaven help us if this is all that is left:

This is certainly beyond the comprehension of the average user, and totally unnecessary, in my view.

I confess to much of this being beyond my comprehension, since I do not know what these mean:

1806 trick, DEP, SEHOP, EMET

If you are in a position to help a home user, rather than such a complicated tutorial, why not just install a good Default-Deny product and spend the rest of your time instructing them on safe computing habits and the like?

Computing security need not be so complicated!

regards,

rich

 

Not really

My wife is a happy LUA/SRP user on het Windows7 ultimate laptop. I choose SRP over AppLocker for performance reason on her 3 year old laptop, otherwise it would have been Applocker.

Most people do not want to run LUA (at least the ones who asked me to help). For most people HIPS or simular security programs are a bridge to far in terms of responding correctly to pop-ups (with the exception of DefenseWall problably).

For software implementation this formula is a golden rule: Result = Quality x Acceptance. Since acceptance is low on LUA and three layer security setups are rarely used by common PC users, SAFE can achieve better protection within the bounderies of common accepted PC usage:
a) Is possible with just a home version (majority of Windows7 sales)
b) Provides LUA/SRP protection while enjoying Admin authority (majority of the home usage installations)
c) Is free, light and automated/monkey proof

Regards Kees

 

It's not that simple. The kernel enforces privileges and the default/deny policy you have set. If an attacker can get a code path to a kernel process he can override the security policy and you're pwned. It all just depends on how low of a level the attacker is compared to your security policies. Moreover, all of the applications on your white list are still susceptible to exploits themselves, and since you run everything from an admin account, if one of these apps gets attacked, your entire machine is pwned. If you were running the app from a LUA, this wouldn't happen.

DEP = Data Execution Prevention. This is Microsoft's way of describing the NX (No Execute) instruction set that is present in all modern x86_64 processors. This can greatly enhance the security of the system because it marks data regions of memory as non-executable.

SEHOP = Structured Exception Handling Overwrite Protection. This stops exploits that use the structured exception overwrite technique. A structured exception is basically a way for the CPU or the software to handle an exception within a program (i.e., a try/except block of code). Some exploits take advantage of exceptions and overwrite them with their own malicious code. Since all security vulns are a result of badly written code, this, like DEP, can help a lot.

Because ultimately, and despite all the security software, they are still running as admin which is dangerous.

 

That is exactly what it achieves Rich. It implements a default deny for downloaded objects or objects received throug mail. Simular as when you okay a AntiExecutable pop-up.

See for explanation: https://www.wilderssecurity.com/showthread.php?t=278014 this explains it all.

The user does not need to know this just simply remember: when I want to install something
a) move it to my desktop
b) remove the block with right click
c) run it as administrator

 

Do you know of current exploits in the wild that can do this?

This doesn't necessarily have to apply to everyone.

----
rich

 

I've not argued otherwise. It just seems to me that all of these tweaks are just too difficult for the average person to understand.

Please give me an example where you would OK such a pop-up.

In a Default-Deny set up, there should be no opportunity to permit. I'm referring to remote code execution exploits.

----
rich

 

With UAC or with SuRun you aren't limited even in a user account.

You really regard that as an easier solution? I seriously doubt that. People who can't handle UAC won't be able to manage what you're suggesting as an alternative.

SRP certificates? I've never been bothered with certificates after applying an SRP strategy as suggested on http://www.mechbgon.com/srp/ and I've never experienced any performance penalty.

 

I would suggest that your wife, with a security expert in the home, is not your average user! (which was the point of my post!)

----
rich

 

Yes, but in the end the user can decide to allow some of them and he/she might be tempted to do so because of inexperience or of being tricked by social engineering.

You don't have this problem with SRP: All executables that are not explicitly allowed by the policy are blocked. Period. No second guess and therefore fool-proof.

 

Exactly.

I'll stick with my AppLocker setup, Windows firewall, and continue running in LUA, rather than hack the registry, thank you. As for UAC, it isn't just a simple matter of allowing/denying any old process that pops up. Once again I'll post a very informative link on UAC and how it works, particularly "UAC elevation prompts":

-http://technet.microsoft.com/en-us/library/dd835561%28WS.10%29.aspx

 

A look at this thread alone should explain why most people run Admin (myself included) and don't have their systems on lockdown, lol. As much as I respect Kees and the rest of you in this thread, I swear if I had a choice of either shutting off my system or dealing with everything you guys just spoke of in this thread, the plug would come out of the wall! Who on earth wants to go through all this just to surf around a bit and enjoy what little creativity there is left on today's internet?

I run admin on Win 7 64. I have UAC on full, DEP and SEHOP enabled (don't have a clue what they are in tech terms, and I don't care. If they work and keep their mouths shut, I'm alright with them), a good, free AV, a couple of good secondary opinions in the form of paid Hitman Pro and free MBAM, and I use an alternate browser that isn't allowed to open PDF files. I get the occasional infected file, but my AV catches them all, tosses them in the virus chest, and I delete them.

I'm coming from a general user perspective, I know nothing about all this SRP/LUA junk, well, I shouldn't call it "junk", but yet I stay safe, through all my surfing and P2P. I guess my long winded point is, as much as the things you guys talk about may help security, I'm afraid that anything that is going to "limit" a user in any way, is never going to catch on.

 

Tell me how many of your friends and releatives run LUA?

Agree on that one, that is why Sully is making SAFE

The link explains SRP usage with path rules (which I also use) that is WITHOUT using certificates. Try adding a certificate rule, you will understand what I mean. I compared SAFE against Applocker which is the same as SRP with path rules against SRP with certificate rules in processing power.

 

OK, but SAFE will be as easy to use

 

That's also the way it is with the product I use (Anti-Executable)

All others, except for GesWall, unless I've missed something, are not Default-Deny, and require the user to make a decision. Here are tests Aigle and others ran for me some years ago:

http://www.urs2.net/rsj/computing/tests/remote


----
rich

 

Thanks, that is my point. Safe will automate these settings, meaning you do not need to know how the TV works, you only need to know how the remote control works. With SAFE you won't be limited, only you have to give explicit ALLOW to prevent accidentals installs and drive by's. It is no difference with your current situation as Windows gives you a pop-up with a warning only when you try to execute a downloaded program.

 

Not many (e.g., my kids do). But surely more than the ones applying your rules or Sully's SAFE

I have no need to do that. I've been running SRP with path rules for years, and it has worked well (and no infections although I don't use an AV). And BTW: I think I haven't used my admin account for years. So much for limitations under a user account. (Granted, I've been using Linux most of the time in the past years.)

I don't have Windows 7 but AFAIK Applocker can also be configured to use path rules. So certificates should not be necessary. But again, I don't use Win7.

 

Applocker can be configured to use path rules but it can also be configured to use Publisher or Hash rules, or a combination of all three. Publisher and Hash are the most secure, but hash rules are a bit less convenient because the rule needs updating whenever a hash-governed application is updated.

No it isn't tricky to set up. Lucy explains here just how easy it is to simply go with the defaults.

AppLocker can use the very secure Publisher rules. There is no warning about performance impact and I've never noticed issues with performance when using this approach. I will admit AppLocker it's not for most because of the price point of going with the Ultimate version of Win7.

 

So you actually do NOT run admin but standard user. Good! Many don't. A good start!

Ah, you need additional tools to make you feel safe. And your AV catches infected files - hopefully all of them. I simply don't care about them - if I get some, e.g., via email they can't execute. It's that simple.

You have to learn to operate the tools you mentioned, you have to learn to interpret their messages and their (false) positives, and you are confronted with frequent updates for them. A LUA/SRP approach, on the other had, has to be setup once and it works. Yes, it takes some time in the beginning to understand its logic but the same is probably true for the tools you're using.

You're using at least 3 security tools if I got you right. No hard feelings - but I think that's an example of occupying oneself instead of applying a simple yet sound security strategy. Calling LUA/SRP "junk" although you admittedly "know nothing about" it speaks for itself.

 

The publisher and hash rules are the improvements over SRP

For your convieniance the same in English http://www.windowsnetworking.com/articles_tutorials/Introduction-AppLocker-Part1.html

Thanks for hitting the nail on its head, you go with the deault allowing Admin/System all rights, so AppLocker works best with a LUA user

I am not saying people have issues with performance, just telling that SRP with path rules is faster than SRP with Certificates or AppLocker with Publisher rules. SAFE works with ACL which is simular performance impact as SRP with (few) path rules.

 

I must have missed something judging from the reactions here. Lets get the few points in the open: ** after previewing this, I think it comes off a little strong -- NOT my intention at all, but I am not about to type it over lol -- so don't take it as it sounds, just voicing my confusion over why the responses here are so different from his other threads on the same topic **

This is the main point to make -- most people don't have AppLocker available.

Here we have the ability to modify UAC to ones liking. As well, setting the integrity level for specific programs to a level that fits your needs.

And here we speak of putting enforcement on a directory meant for downloads/email.

And this just adds some finishing touches.

So, what is the big deal really? We might modify the UAC, which you could do with a GUI if you wanted. We might modify the integrity level of "specific" files, most likely browsers and thier kin.
We apply a reg tweak that adds execution protection to a directory. We apply DEP/SEHOP/ETC and fix AutoStart.

What I do not understand is, how is any of this different that what we have applied in the past. How many here have applied DEP? Not hard to do, is it? How many used the reg tweak for XP to disable autoruns? How hard was that? Was it an awful reg "hack" that borked your system? Were you afraid to apply it?

I just don't see why this is causing such a stink. It is not a full blown application, only some settings you can put in place to change specific behaviours, some of them easily set via a GUI somewhere, some of them only through a registry setting.

I am not a User, but an Admin. I look for things such as this, tools/options to keep the edge over possible problems, while still allowing me to be an admin. Nowhere is it stated that this is a replacement for LUA, as good as LUA, or a fabulous new tool that will be the end of your security problems. I think we can all agree that LUA would be the best method for most people. We can all agree that M$ should include AppLocker and SRP into all versions, since only those who wish to learn something can really use it anyway.

I like this approach because it is simplistic and only requires minimal user interface. You set the options, you go about life. Maybe you only want to use the IntegrityLevel option on your browsers, or maybe you only want to apply DEP. So be it.

It is a methodology - find the areas that you can protect and decide to protect them. Do that with LUA, do that with AppLocker/SRP, do that with HIPS, do that with Norton, do that by checking this option or that option, do that by applying this reg tweak or that reg tweak, do that by using Linux -- the point is, who cares how you do it, if it works for you.

Kees has already implemented these features and has multiple posts about what he found. In those threads people said things like "how does this work", "why do you set that to X" and "I didn't know you could do that". In this thread, which is only re-capping what he has already put forth elsewhere, it is suddenly "why?". The radical change in attitude because his little system might have a front end to it rather than a bunch of settings located hither-thither-and-yon?

I struggle to grasp it - so, I must be missing something...

Sul.

 

This is just another default deny strategy? .....

I understand what you are saying about the security issues at stake and that people should be more responsible, etc. But the average user already hates default deny. Making another default deny strategy that is more secure probably will not mean much in the big picture of things. Most people will still hate it.

Don't get me wrong Kees, I read pretty much all your posts and respect your opinions. But there is a reason why social engineering works for malware writers and why computer geeks don't have an antidote as popular as what the social engineers use.

Besides all that there will still be a need for a scanner of some sort to help determine if some download is malicious or not prior to install. It seems there will always be an opening to circumvent this type of security strategy. Especially when the security strategy proposed is to spend more time and effort tightening up a computer than actually using one. People generally just want to get on Facebook, play games or download music. But doing that sort of activity is met with default deny policies and registry tweaks. I think internet security analysts just don't get it.

 

It's a shame, really, that MS gears AppLocker toward enterprises, thus the need to purchase the very expensive Ultimate (in my case the full disk @ >$300). They really should include it in standard versions because it's a superb way of incorporating default-deny with what's already built in to the O/S. However, if Sully's SAFE project can work the way Kees describes, it will be an excellent alternative. I would like to take a look in my vm (hope it works in a vm and Sul doesn't make it vm-aware ) when it's hot off the development table

If your SAFE admin can apply these reg tweaks safely, then I see no problems. The problem I do see is getting inexperienced users to apply them manually.

BTW, my reaction was based mainly on some comments made about AppLocker being tricky to setup and getting warnings about the need to grant Admins fulll access, as well as UAC prompts needing to be minimized, when in fact it's not tricky to setup, nor do even Admins have to be granted full access to every program; selected programs can be restricted from Admins, although I see no point in this at all. As for UAC prompts, please keep in mind they are not that simplistic. UAC prompts are color coded with four possible type prompts, as detailed in the link I posted above. admin-approval mode also puts the admin in a "standard user-like" situation with the standard user token on explorer.exe, the parent process when launching applications. It really is quite safe, as I've recently learned, to run as admin with UAC on default or better yet (thanks to MrBrian for pointing this out) on highest setting.

 

I don't know if this is something novice users will really adopt, it might be. If it does, great, but some of it I plan on giving a good test run, so a front end is needed. Not to mention since most of it is registry or can be done with built-in tools (like icacls) it is not re-inventing the wheel.

I have a hunch that there will be many people who do know a little something that will only use certain aspects of it (if they are admins). It all depends on if they are wishing to have a default-deny scenario, which I am not. I just want to shore up the defenses if possible.

Sul.