Maximising the power of Windows7 for security when running as ADMIN

Yes correct, but the initial idea was to create a safe-admin. So running as admin is for the same user (unless I am totally messing things up)

 

Just rolled in from a trip out-of-town. Can we decipher the best registry location that would apply to either admin or user? I will be working on that tommorrow, so it is a good time to make the best judgement.

As Kees states, this was intended for an admin in the way back stages. Some of it can be applied to users as well. Actually, I think there should be a distinction between a true user account and and admin account using UAC.

Is the nomenclature of LUA and SUA good enough for User (LUA) vs Admin (SUA)?

With those in mind, does one of these registry locations have a clear advantage in either LUA/SUA over the other?

Sul.

 

LUA and SUA is for the worker mnemonics I guess (limited user account and super user account). USR and ADM are more abbreviation like mnemonics. It is your pick

My preference is for the user. Since this allways leaves the run as admin option open, to work something out (when someone has messed up).

 

What happened to the Safe-Admin thread, deleted already?
I'm just getting used to the eye candy.

Will Safe-Admin incorporate IPv6 blocking rules for the Windows firewall?

 

Kees, you're far from messing things up!

From the perspective of an user making use of an administrator account - SAFE-Admin has/had as a base this - the key you provided makes sense and is the best way for the Administrator account.

But, I was merely seeing it from the perspective of a user making use of a standard user account, and that would like to apply the same principles (Why not? It works. ) to such accounts. In such scenario, there's no way a standard user can modify such Registry part, because he/she will lack permissions. It would need to be done via Group Policy (I haven't bothered to look for it, yet, though. lol), which would then be applied to User Configuration, which in turn would reflect to all HKCU\Software\Policies\, and not just to the HKCU entry of the Admin. account.

-Edit-

I took a look at IE8GPSettings.xlsx file from Microsoft, and the entry corresponds to this User Configuration > Windows Components\Internet Explorer\Internet Control Panel\Security Page\Internet Zone > Launching programs and unsafe files

 

Not likely. I am feeling guilty, since Sully has spend over 320 hours of programming time (mind you it is a hobby) in the last 6 months. So we are scaling things down a bit. No auto config of windows firewall.

What really took a long time is making things fool proof. Since those security mechanismes interact to each other, before applying the settings a screnario builder first generates all actions. Next those actions are checked for simple errors (like setting a deny execute to your windows directory), next the new settings are evaluated agaings existing values. All conflicts are handled as much as possible by the program. After the simulation all settings are applied with a fallback mechanisme (when user wants to revert to ealier security settings).

I guess Sully has to spend an additional 80-100 hours on the GUI program. So when everything works out january/february next year first release will be available.

Regards Kees

 

Is it possible to prevent installation of unsigned drivers in 32 bit vista home premium/basic? I cannot find the registry path to apply the registry tweak given in first post. All I can see is HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows. There is no Windows NT\Driver Signing path

 

Thank you sm1 for bringing back alive this thread as I managed to miss it somehow at time (win7 was not of interest for me by then).

Good read and some nice tips here!

 

Yes, you can just create

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows NT\Driver Signing

Value Name: BehaviorOnFailedVerify
Data Type: REG_DWORD (DWORD Value)
Value Data: (0 = Ignore, 1 = Warn, 2 = Block)

Vista is the OS pf choice of admins
Vista is the best OS around, with the safe-admin tricks
- UAC only elevate signed programs
- UAC disable installer recognition
- Only allow signed drivers to install

Plus
- RUNASINVOKER to virtualise threatgate programs
- EMET2 threatgate programs
- Use PGS (Pretty Good Security) to run threatgate programs as BASIC USER

Protect against downloads/drive by's
- 1806 trick

You really got a strong defense. I even put my wife's laptop (a Vista x32 Business) to silently elevate (= UAC on quiet mode), since nothing can elevate without your explicitely running it as Admin.


Regards Kees

 

Thanks for the explanation Kees

 

In Kees first post I'm trying to understand if you need to make a LUA account before you do this... or is this what the info in post #1 does automatically.

Also, the mentioned 1806 in post#13 I don't see in post#1 or I'm not understanding. Sounds the same as LUA, SRP, EMET.

Will this work on Win 7 64bit?

Can someone help clarify? Thanks.

 

OK... As the title of the thread mentions, the initial idea behind this idea (sorry about this redundancy lol) was to make Windows Vista/7 Admin accounts safer.

But, the same is not to say that the same security measures wouldn't apply to LUAs; they do. But, this won't, by itself, create a LUA account.

The way I see it: these security measures + LUA adds an additional layer VS these security measures + Admin.

Regarding the 1806 trick, such had in mind, initially the admin account. There are only two ways for standard users to have the same:

* Open Group Policy Editor and change the entry needed (I mentioned previously in one of my posts);

* Change the Registry entry; This entry is possible to be modified by standard users, which means it's in HKCU, and also means it's possible for malware/other users to change it back.
The entry edited by Group Policy Editor also adds an entry to HKCU, but this entry is not possible to be modified by standard users; it requires administrator rights to be changed.

 

Okay, understood.

I had to ask cuz when you start talking registry keys that's total chinese to me. It has to be translated into easy english for me to understand

What exactly does the 1806 trick do, sorry I can't see the post as I type?

Thanks MoonBlood for explaining

 

The 1806 trick will apply a "rude" anti-executable. Let me try to explain the best way I can.

The registry key (The one mentioned in the SAFE-Admin project) is the following:

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1806"=dword:00000003

00000003 - Value 3 means that execution will be denied.

This registry key would be the same as the one I mentioned regarding Group Policy Editor; with one difference, though. This key, and if nothing has changed in the SAFE-Admin project... I truly cannot recall right now..., applies only to the Administrator account.

What does this mean?

Well, imagine that you would apply a *.reg file which would create such registry entry...Despite the fact we're dealing with a Registry part where standard users would be the permissions to write, etc., since this is a policy entry, only Administrators are allowed to mess with such registry entries, not standard users (HKCU is what we can call the Registry part where standard users are allowed to mess with... but there are exceptions, just like the one I mentioned...)

The only way, that I'm aware of, standard users could make use of such policy, that standard users and malware executed in user-space would not be able to modify, is through Group Policy Editor, which will allow to have the same entry

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1806"=dword:00000003

applied to all standard users accounts, or to one specific account, if we wish it so... though one would need to start Microsoft Management Console (mmc.exe), then a few other steps, which I won't be mention so that I won't end up confusing more... If something you/other users would like to know, then I'll explain... I just want to keep focus on what is most important to your doubt, I hope.

There's one other Registry entry where you can apply the same effect:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1806"=dword:00000003

But, this one any user can modify... this means malware as well.

I'm not aware if lower Windows Vista/7 versions than Ultimate have Group Policy Editor? This would be/is a problem...

I personally don't have it applied... it would demand me to always have to start Group Policy Editor to change the value 00000003, so that it would be possible to install whatever installer I download.

I find it more appropriate to force Chromium to download every file to a downloads folder, with execution permissions removed.

Again... I do not remember if SAFE-Admin would make this process easier for standard users... And, not sure how it could be done... I do remember, after this post of mine https://www.wilderssecurity.com/showpost.php?p=1784623&postcount=45

Sully asked which option of the two I mentioned would be the preferred one... So, I'm not sure if there's no other way around it. *edit*

*edit*

A way out, I think there would be one... but most likely would demand even more work from Sully's part. It's just something that crossed my mind... which I still don't have all the thoughts in one complete thought.

As I mentioned, using *.reg files won't cut it, because one needs to apply with with Administrator rights, and this would make it only apply to HKCU entries of Administrator, and not HKCU entries of standard users.

-edit-

If this is still a bit confusing... read from this post on https://www.wilderssecurity.com/showpost.php?p=1784425&postcount=43 (a post of mine). I think it will explain better what I mean... I think at the time I wrote such posts, things are more self-explanatory... I hope lol

-edit-

The Group Policy Editor part I talk about is mentioned here: https://www.wilderssecurity.com/showpost.php?p=1790616&postcount=55 (After this post... then only yours and these I wrote yesterday/today are new... )

 

By the way... the 1806 trick will make impossible to even download with IE. With Chromium based browsers you still can download, but execution will be blocked.

I don't remember with Firefox and Opera.

 

yes i always use this trick in my computers to blocks surprice kind of malware

 

Group Policy may change the key you mention but if I'm not mistaken the difference with Group Policy is that it changes more registry locations for that policy than just that one user edited key.

 

I hope I'm not confusing things...

But, recapitulating:

* SAFE-Admin project changes/creates:

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1806"=dword:00000003

This registry entry is for the Administrator account, under which such modification is started. It will not be applied to other accounts.

* Group Policy changes/creates

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1806"=dword:00000003

This is applied here: User Configuration > Windows Components\Internet Explorer\Internet Control Panel\Security Page\Internet Zone > Launching programs and unsafe files

This can either be applied to all accounts or to a specific account. I'm not sure if Windows Vista allows this, though. It's possible with Windows 7. Under Windows 7, one can applies Group Policy either to all accounts or specific accounts.

What do you exactly mean?

 

What path is it denying execution too... the downloads folder in IE? Can you right click to unblock? I understand this is the key you would use with GPE so malware can't change it. Okay, this is only good for LUA accounts right?

Well heck, I wouldn't want to use it either if had to do that everytime.

How can this be done? I'm getting ready to install Chrome for the first time and that would be a good idea.

Right now I'm on Win 7 64bit Home Premium... don't know if it has GPE.

 

I was agreeing with you that it is more secure to have GP set the policy for it.

 

Regarding IE... unfortunately you cannot force it to download to a specific folder... Not that I'm aware of.

Both accounts, actually: LUA and Admin.

But, in both situations, such would be applied to the same key. The problem is that, it's not an easy thing to deal with from a LUA account, because as I mentioned, to prevent malware tampering such policy, the registry entry would need to be

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1806"=dword:00000003

and not

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1806"=dword:00000003

Unfortunately, the only way a standard user (LUA account) would be able to create/change the first one, would be either via GPE, or for SAFE-Project to allow to elevate rights, but still only make the change to the LUA account in question and not to the Administrator account. Something in the line of what SuRun allows users to do. We can elevate an application, but as far as I still remember such changes will only happen in the context of the LUA, and not Admin account.

Yeah...

If one goes to Chrome/Chromium settings (wrench icon) Options > Under the hood > Downloads ... you can change which location you'd like downloads to be transfered into. Just remove the checkmark that selects that option to ask you where to save files when you download them.

I have a folder in Desktop, which I removed execution rights and applied a low integrity level to it.

I also managed to create a similar effect to the 1806 trick regarding IE (which forbids downloads) for Chromium.
I'm running Chromium with an explicit low integrity level. For Chromium to download (as any other browser, I think) it first needs to download a temp file to %UserProfile%\AppData\Local\Temp. It happens this Temp folder has a medium integrity level, by default. A low integrity level object (in this case chrome.exe) cannot write/modify a medium integrity level object (in this case Temp folder).
This kills any problems with malware via Chromium.

When I want to download, I start Chromium under Sandboxie, which does allow the interaction needed.

 

Oh... OK.... lol

It's already late/soon (as you wish lol) here (4 AM)... way sleepy... so I'm not too focus...

 

I'm following you, easy enough to understand.

How did you tweak this to get the low integrity on chrome.exe?

Thanks, you explain things well.

 

While SAFE-Admin doesn't come out, you can make use of two utilities, that I'm aware of, one by Microsoft, already part of Windows, and one other by the name of chml. Either one will do the job to apply a low integrity level to objects (files, folders, processes), but chml is way more advanced than Windows Vista/7 own tool.

I have chml placed under C:\Windows\System32; this way when opening cmd line I can make of chml from any directory without having first to go to chml's own directory.

chml: -http://www.minasi.com/apps/

You can know more of what it does and its commands there, at the page, and by invoking these two commands:

chml -?
and
chml -st (show tutorial)

Then, once chml is placed under C:\Windows\System32, just type:

chml "C:\Program Files\Chromium\chrome.exe" -i:l (Here is just an example of where I could have Chromium saved, of course.)

To be able to save downloads, two things are required also to have a low integrity level applied: Downloads folder (a general folder) and %UserProfile%\AppData\Local\Temp

If you do intend to add a low integrity level to Temp folder, so that you can download via browser (without using Sandboxie like I do, or even a download manager (doesn't always work, if the server where xyz file is hosted doesn't allow such)), it suffices to do it like this:

chml "%UserProfile%\AppData\Local\Temp" -i:l -noinherit (-noinherit makes this low integrity level only apply to Temp folder and not to all sub-folders)

%UserProfile% = name of the account; example: "C:\Users\<accountname>\etc

(cmd line needs to be executed with Administrator rights, unless security policies are changed which would allow standard users to mess with such, if memory still serves me well... something not to be wished, though, IMO)

I did find one "problem" by having things as I have: Extensions. I can install them (If I first add a low integrity level to Temp folder, of course.), but then they won't work, at all. I can live with that scenario... lol
So, if you wish to use extensions, perhaps first you'd need first to install them and configure them without changing Chrome's integrity level.

It could also be because I have Chromium installed like C:\Program Files\Chromium\Profile 1 etc

I have different folders for different profiles... a personal taste So, it could be why extensions go all crazy on my setup. Or, because of the Profiles folders, which are like Chromium\Profile A, B etc.

** By the way, it is also needed to apply low integrity levels to Chrome profile folder(s). I have applied -i:l -nw -nr -nx and I also removed execution rights from it...
I have mine like: C:\Users\<accountname>\AppData\Local\Chromium\Profile A, etc

-edit-

I forgot about the Downloads folder part.

It would be best approach, IMO, to apply like so:

chml "C:\Users\<useraccount>\Desktop\Downloads" -i:l -nw -nr -nx

This command assumes, first, that there is a folder named "Downloads" placed in the Desktop.

-i:l (applies low integrity level to it)

-nw (NoWriteUp - forbids low integrity level objects from writing to areas with medium or superior integrity levels)

-nr (NoReadUp - same principle, but applied to reading from such areas)

-nx (NoExecuteUp - same principle, but applied to executing to such areas)

Whenever you make use of either of the last two, you always need to apply -nw as well, otherwise it will be assumed you only wish the two/either one of the last.

If you wish only to apply a low integrity level to an object (be it a file, folder or process), but no other policy like -nr or -nx, then you only need to apply -i:l (the policy -nw is automatically applied)

-edit 2-

The command chml "C:\Users\<accountname>\Desktop\Downloads\process.exe" -rl will remove the low integrity level to that object and the object will inherit the accounts default one; if standard account, medium level; administrator account, without UAC, high level.

(Just an example)

 

To make things really monkey proof and user friendly about three times more code was needed as Sully initially expected. After having established a stable code set, Sully did a code overhaul to simplify things/increase performance. After this he ran into a Windows surprise which required a re-code. This itself required some changes on the fall back mechanism (Safe-admin administrates all changes made by Safe-Admin to the system in the registry, so a neat roll back by the user is possible).

Safe-Admin will be available end of this quarter is my estimate, but maybe Sully can provide some accurate status info.