The irrelevance of Applocker / relevance of SAFE admin tweaks

Why would I want to do that? Tell me.

I wonder what the last 20% did to be left out of the equation.

 

Definitely Although 80% is actually not enough

 

This is great initiative from Sully. It will allow power users running Windows 7 without AppLocker to have a tighter security.

But, I don't see it of any use for the so called Joe/Jane. The same goes for AppLocker/SRP, of course.

Oh, this is not working as it did. What's wrong, son/brother/father/mother/etc? Fix it, please! Why can't I just work the way I did before? Why?! Put it all back!

It's nice for those who have power users who can assist them; but, in this scenario, we're talking about blessed people.

Still, I'll wait to see and test this tool when comes out. It sure is more than welcome as an alternative to AppLocker, for us who know what we're talking about and doing. Not for the masses.

 

Applocker is not available in Windows 7 Profession ?? What the hell ??
Seriously?? Such a basic security feature missing in Professional %$##@*&^%$

Darnit...I installed win7 pro from Technet...Anyone know if I can upgrade to win 7 ultimate via technet?

 

It is early but it looks as though it may be possible to use AppLocker effectively under an administative account (madisonB is the VM's adminitator account), excluding the default "Allow all" rule for the administrators. At least it should stop anything not initiated by the user. The screenshot of my attempt to launch ccsetup233.exe on the desktop was stopped in its tracks - even when I tried to run it with administative credentials. So this latter enforced denial by AppLocker is a slight problem when the administator wants to install a program. It means that rule enforcement for executables will have to be configured from "Enforced" to "Audit only", then put back to "Enforced" once the application has been installed and an AppLocker rule is created for it. A screenshot is also included for this example.

Essentially, the security in this administrative account is being provided by a combination of AppLocker specifically scanned applications (whitelisted applications) in specific directories, with UAC set to to "Maximum". Most of the rules are Automatically generated" with preference given to Publisher rules, followed by Hash rules, then by Path rules. Process Explorer is a strange one, requiring a Path rule because of a Procexplorerx64 executable it genrates when launched.

I've had no problems so far running administative tasks such as changing the time, configuring the firewall, or modifying network settings, to name a few. More on this later, likely tomorrow.

 

Is it necessary to exclude these rules, given that UAC is enabled?

 

I'm only experimenting, looking for a way to run as an administrator more securely than normal, because of acr1965's request, otherwise I don't like it and I would not - and do not - exclude the default "Allow All" rules for administrators. All I'm attempting to achieve here is to setup a whitelist of rules for trusted programs already installed, while denying anything else that attempts to install without initiation from the administrative or standard users. with UAC enabled and set to Maximum (important, I think), maybe this is superfluous? Maybe someone could use this type of combination with UAC set lower to reduce administrative prompts, which some people can't seem to tolerate? Hmmm, interesting.

Time will tell if this is viable and/or overkill

 

If you leave those rules enabled though, you're still protected when running as admin, as long as UAC is enabled. Try enabling them, then try running (without elevation) something from c:\temp, for example. AppLocker should deny the execution.

 

Okay, but sometime tomorrow. This (what you're saying) is leading me to believe there's no need to run as a Standard user

 

See LUA + Applocker: what's the point using both? and max level UAC + SRP/AppLocker.

 

Right, and I'm involved in both those, but what I'm not certain about yet are single file executables, those that install in the user space which could still potentially do considerable harm. Does UAC even on highest setting alert to those? If not, this is where AppLocker will ( or should) provide an undeniable defense against them. I remember a couple malware samples recently provided to me that installed to user space and UAC on maximum did not even alert on them.

 

Those samples probably didn't evoke a UAC prompt because they didn't do any admin stuff. AppLocker would protect against those executing. AppLocker/SRP + UAC max + admin account might be good enough for practical security.

 

Watt,

Thanks for trying. SAFE's idea is based on the same principles.

 

Guys, let me repeat the idea of SAFE is based on the following

UAC is a two sided blade. When Microsoft had determined it would not have a remember function (what I would have preferred), they compensated this UN -userfriendly habit with some feats to soften this aspect.

SAFE's security principles

1. UAC elevation pop-ups should be minimal, to reduce should in the foot errors (a) and social engineering (b)

Explantion for (b)
Because all applications launched from a LUA process run LUA, social engineered installs are always captured in the LUA-box, making them relatively harmless

Explanation for (a)
Credits to Joanna Rutkowska, see http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html

2. Reduce drive by attacks, by removing the execute right from your browser's download directory (a) and transforming the warning windows pops-up when you try to run a downloaded item (b)
- into a download block (IE),
- zero bytes download (FF) and
- allowed download (Chrome), only dubbelclicking it with explorer will show a denied access pop-up

So it is a default deny, which can be overwritten on the fly by the user with right click ease. To me this serves its purpose for drive by protection (and really I tested it, it works real well). Option (c) is only an extra precaution to let your OS ask your AV to allways check objects from the internet/mail.


3 The EMET/SEHOP/DEP hardening
Really SAFE will provide an easy right click, so every one can use these Microsoft engineered hardening options (they advise it them selves to apply this, so what is the fuzz about it )

Round up SAFE
It protects people running admin from
- shoot in the foot errors
- social engineering
- unrequested drive-by downloads
+ some extra hardening options provided by Microsoft

Basically simular protection of AppGuard version 1.3 (old version, newer has more like MBR and process modification protection), only for free

 

So Kees/Sully, any news on when SAFE will become available?

 

I am only writing the lyrics, Sully composes the song. So Sul any timelines?

 

I have all of the registry settings now, and have been working on different mechanisms for any ACL stuff, which I will put the primary focus on because it needs to be easy, but most importantly be done absolutely correct.

The other major obstacle is automating DEP, because to do so you have to throw a switch on the boot loader. In XP it was simple, you just modify your boot.ini. In vista/7, using bcedit, it is still relatively simple, but automation stands the chance of borking the boot process, only rectified by using the install dvd. This one I might lean more towards explaining how to engage it with the built in GUI rather than scripting, but I am looking at a few tricks I found.

I will prefer to make this a standalone executable, with the exception that you have to download and install EMET to use those features. Each feature Kees discusses will be independently toggled on/off.

Then I need to examine how I am going to hook the context menus to the file types. I can simplify it by using * file types, but that would put a context menu option in every file type, and sometimes it can even be listed twice. I am thinking of learning some new material for this, but am planning on getting a simplistic version out first.

Timeline, perhaps a rough version in a week or two. That can be fine tuned, or left rough until I determine just which language I will program it in. I have been looking at perhaps making a dll that you register (shell extension).

I might have already had this done, but the family gives me less time in the summer that the winter.

Sul.

 

Concerning Applocker and being an admin, for myself this isn't what I want. Kees lays out a method of creating a system where you can trust that downloaded executables will not executed without permission (based on type), engaging some features such as SEHOP and DEP that can help in other areas, modify UAC a little to help keep some activities that might "shoot you in the foot" from happening, and in general create a little environment that is part admin/ part lua.

When I think of being an Admin, for whatever reason one has to be admin, I think the reason to be admin is because you want to change what you want when you want. Whether LUA is just a nuisance to you or whether like myself you are always doing admin things so LUA is more than a nuisance is not important. To me, what is important, is that I do something to minimize the "open nature" of admin.

I don't want a pure "deny and block" situation except in a few specific places. I want more of what XP had to offer with the SRP "Basic User" option, where I could state, specifically, which programs I wanted to reduce to User. In this fashion, I know what to expect and can go about business as usual pretty much. There isn't much "right clicking" involved. How close I can get to that on 7 will depend largely on what Kees has dug up and how to combine it.

Using Applocker in Admin, to me, is just too much. If there were someplace specific I wanted to deny, maybe it could be of use. But because it offers only a black/white effect, I need to find that "grey matter" some other way. We shall see.

Sul.

 

You're welcome

Right, and I tend to agree with you on this.

Although I don't really endorse the use of Applocker used in an admin account, I believe it can reduce the open nature of this type account. Still, it will be interesting to see what your SAFE project will achieve towards this goal. I'm looking forward to it.

UAC set to maximum, maybe even default, does reduce programs to a "user mode" since the user token is applied to explorer.exe - the parent process to programs such as iexplore.exe and wmplayer.exe. However, I understand you are looking for something, I believe, that offers a little more diverseness than what's currently offered.

 

Sully, is the tool going to be open source?

 

Open source? It already is open source, all of this really. I am just making a GUI for it instead of you having to merge reg files the tool does it for you.

As well, the tool I make will offer a method for a context menu to change settings rather than you having to click properties, then click unblock. Hopefully a context menu to 'unblock' is easier.

I don't know if it would even be enough of a program to consider for open source, as you could do the same thing with batch files and context menus easily.

Sul.

 

Even a 10 line script can be open source

 

So far no serious issues running AppLocker in the administrator VM account. Screenshot shows current Automatically generated ruleset, minus the default administrator "Allow all" rules. madisonB is the admin account. All applications are trusted, and nothing else not included in the rules can launch, neither in the directories listed nor anywhere else. Same sort of idea used for the installer and script rules. Keep in mind that wherever hash rules are used, occasional maintenance will be necessary whenever files with these type rules associated with them change due to an update, requiring the rule(s) for them to be updated to match the file's new hash value.

I'm thinking so. I'd say it's also possible when using SRP or AppLocker that the UAC slider could be reduced by those who can't tolerate the frequency of alerts on the higher settings, although I don't recommend this approach.

 

The deeper you dig into Integrity Levels, the deeper it gets. There are more ramifications than you can shake a stick at. If I can wrap my feeble mind around this, it seems there are some promising things that might develop from it. Most of it is simple enough.. Admins typically run at High unless stated otherwise, Users usually get Medium. But not all things have to have what is known as a 'label', so some of it depends on inheritance and what is defined by the OS. The level of 'low' is an interesting one, what IE uses as 'protected mode'.

The other thing that I think I am getting is that when a process is at a level, objects that it creates are given a mandatory level of one level lower. So an admin running notepad at High, creating a document, the document would itself be a Medium... but it doesn't say if a document created with a medium label will run at medium if opened or if the parent program running at high level will set it.

Ah, so we set about being a SAFE admin do we? lol, we shall bend it to our will, that we will.

Sul.

 

One argument for SAFE I did not mention: Speed

On my play PC, I run as SAFE admin. It is a Vista x32 business with 2 GB RAM and an E5200 low-end dual core (at 3 Ghz, slighty OC-ed, standard it is 2,5Ghz) with a new fast Samsung 1GB drive.

Iron starts cold (with www.google.nl as starting home page) in less than 2 secs
Iron (chromium clone) starts hot within a second

I use windows FW also as outbound application filter. I have Windows defender monitoring Autostart entries, System configuration, Registration of applications and Windows plug-ins (active X). Besided Norton UAC tool, PrevX safebook free is the only third party security application I use realtime.