Mis-understandings about Software Restriction Policies (SRP)

Page 1 of 4 1, 2, 3, 4  Next

View previous topic View next topic Go down

Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 22/4/2010, 14:24

Taken from this interesting article (I actually agree with a lot of the other stuff there):
http://www.bluepointsecurity.com/forums/showthread.php?t=12 :

Most people configure SRP to allow a list of trusted executable names. The reason most won't go to the trouble of implementing a fingerprint check on each file, is simple; ease of use. The problem is, if a virus exists with the same name as any of your approved exe names, you're vulnerable to it. There are countless viruses with the same name as common windows files such as explorer.exe and svchost.exe, malware writers are unlikely to name their threats virus.exe Locking down your system with SRP to a list of known fingerprints found on your system would be quite cumbersome and unmanageable, certainly from a network administrators point of view with 100's if not 1000's of endpoints. Give SRP a try, you may disagree. I would consider such a system quite secure as SRP operates directly on the application layer on the endpoint which is the sweet spot.

This is something I do not agree with. If the poster is by some miracle reading this post, please read how to setup SRP here (and also read my own full security setup/approach in this forum):
http://www.mechbgon.com/srp/

Don't ever implement your SRP like in the above quote (bolded). Regardless, I disagree that "most" people implement their SRP like that. Instead, I think most people implement their SRP as described here: http://www.mechbgon.com/srp/

Anyway, I'd also recommend using a Limited/Standard Account and combine it with SRP with "path rules". Even the default rules are enough for the vast majority of people, and they may simply add a few executables to the deny list as stated in my security setup/approach post (eg. cmd.exe, wscript.exe). In this way, viruses going by the name of svchost.exe, explorer.exe etc (that is, the same names as genuine windows processes) cannot write to the paths your SRP have allowed (by default, these are C:\Program Files and C:\Windows) and they cannot execute outside of those paths. Bullet proof protection!

Warning: If you allow a separate path rule with SRP in your Limited/Standard Account, please ensure this path cannot be written to or modified by your Limited Account!
Note that the vast majority of users out there will not need to add any more path rules to their SRP, and so they won't need to worry about this warning.

To conclude, SRP is extremely powerful when used in a limited/standard user account, and has NEVER been bypassed by real-world malware (as far as I know), and certainly has never been bypassed by drive-by malware. And when you add block rules to cmd.exe, wscript.exe etc, SRP will even block almost all the POCs out there. In other words, with LUA/SUA + SRP/AppLocker alone, it's likely that you are protected from 99.9999% of all real-world attacks out there. Add in common sense and experience, and you effectively achieve "100%" protection without the use of any third party security software.
And finally, I believe those who tend to shun SRP are generally people who are trying to promote/sell third party security software. Classic stuff!

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by tnegjm on 23/4/2010, 08:07

There was a post recently at Wilders by MrBrian regarding a tool called "Windows Permission Tool" which helps determine your folder/file permissions. It's similar to Accesschk. It seems that in W7 MrBrian found some /Windows folders/files in SUA that were vulnerable and needed some executable rules to fix.

tnegjm
Member
Member

Posts : 37
Join date : 2010-04-20

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 23/4/2010, 08:51

tnegjm wrote:There was a post recently at Wilders by MrBrian regarding a tool called "Windows Permission Tool" which helps determine your folder/file permissions. It's similar to Accesschk. It seems that in W7 MrBrian found some /Windows folders/files in SUA that were vulnerable and needed some executable rules to fix.

Good spotting MrBrian haha. However, I suspect he has mis-understood how Windows' own protective mechanism works.

Certainly even in Windows XP, limited users (LUA) are seemingly allowed to write to certain folders in C:\Windows. However, even with the default SRP rules (which allow execution in C:\Windows and C:\Program Files), you are unable to execute anything from those folders! You can test it yourself. I wonder if MrBrian knows about this.

Anyway, I'll check it out more later.

EDIT: On my system, the following folders appear to allow write access in Windows XP even to a limited user:
C:\Windows\Debug\UserMode
C:\Windows\system32\spool\PRINTERS
C:\Windows\Registration\CRMLog
C:\Windows\Temp

However, on closer inspection, we find the following default security settings for each folder:
C:\Windows\Debug\UserMode
No files in this folder are allowed to be executed. Therefore, an SRP block rule is not required, as Windows' own folder security has already blocked all file execution.

C:\Windows\system32\spool\PRINTERS
Limited users are not allowed to read this folder. Therefore, an SRP block rule is not required when you are a limited user running programs with the default limited rights - you can't even access the folder in order to execute a file!

C:\Windows\Registration\CRMLog
No files can execute here (outside of the SRP allowed list), so an extra SRP block rule for this folder is not required by default.

C:\Windows\Temp
Limited users are not allowed to read this folder. Therefore, an SRP block rule is not required when you are a limited user running programs with the default limited rights - you can't even access the folder in order to execute a file!

So please tell MrBrian this, as I can't be bothered testing Windows 7 haha. I'll be more interested once I am using Windows 7 on my REAL system in a few years time. However, I am fairly certain that you will find the same excellent default policy management in Windows 7 for those folders that apparently allow writing access for limited users.

Anyway, thanks for bringing it up! Seems like another mis-understanding about (LUA/SUA) + SRP/AppLocker to me! Again, I repeat, LUA/SUA + SRP/AppLocker is extremely powerful, even in default configuration!

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 6/5/2010, 10:55

Basically this was a question of whether SRP is really good at protecting your system or not:
http://www.wilderssecurity.com/showpost.php?p=1672668&postcount=1

I implemented Software Rest. Policy in my pc(XP sp2) today. Then i tried to install some softwares. But it restricted. I copied a setup file to Program Files, and tried to install. It worked. Then i realised any EXE placed in Windows and Program Files can execute.
My doubt is , Am i really safe with SRP?
Is there any malware that can escape SRP??

Clearly a complete mis-understanding of SRP. Of course any EXE placed in Windows and Program Files can execute, since the default SRP rules allow that!

Further on in the thread, a poster confuses the issue further (I note it's the same poster who clearly mis-understood default Windows folder/file security settings for limited users, as described in the previous post of this thread: http://ssj100.fullsubject.com/windows-hardening-f5/mis-understandings-about-software-restriction-policies-srp-t22.htm#118):
http://www.wilderssecurity.com/showpost.php?p=1672947&postcount=11

This is really unfortunate. What's described in this link ( http://blogs.technet.com/markrussinovich/archive/2005/12/12/circumventing-group-policy-as-a-limited-user.aspx ) is merely a way to circumvent a poorly configured SRP. Regardless, Mark Russinovich sums up as follows:

The bottom lines is that full control of an end-user environment is possible only with strict lock-down of the programs users run, something that you can accomplish by using SRP in white-list mode, for example. It's also important to note that the ability of limited users to override these settings is not due to a bug in Windows, but rather enabled by design decisions made by the Microsoft Group Policy team.

As you can see, SRP is not "bypassed" at all, and is in "white-list" mode by default.
EDIT: actually I'm wrong here haha, as SRP is not in "white-list" mode by defaut. It's actually in "black-list" mode by default. Regardless, anyone wanting to use LUA + SRP should implement it like this (like I stated in my security setup/approach post):
http://www.mechbgon.com/srp/
When applied like this, the above "circumvention" is blocked with ease, since you would be using SRP in "white-list" mode.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 11/5/2010, 10:09

Received a few PM's about this (in a Limited User Account, Windows XP):

C:\Windows\Debug\UserMode
No files in this folder are allowed to be executed. Therefore, an SRP block rule is not required, as Windows' own folder security has already blocked all file execution.

C:\Windows\system32\spool\PRINTERS
Limited users are not allowed to read this folder. Therefore, an SRP block rule is not required when you are a limited user running programs with the default limited rights - you can't even access the folder in order to execute a file!

C:\Windows\Registration\CRMLog
No files can execute here (outside of the SRP allowed list), so an extra SRP block rule for this folder is not required by default. Note that vbscript executables are allowed to run here, but if you follow my security setup/approach post (under SRP), you will note the additional rules of blocking wscript.exe and vbscript.dll. By blocking (either of) these 2 files, vbscript executables are unable to run from this folder. And I repeat, a separate SRP rule to block execution from this folder is therefore not required!

C:\Windows\Temp
Limited users are not allowed to read this folder. Therefore, an SRP block rule is not required when you are a limited user running programs with the default limited rights - you can't even access the folder in order to execute a file!




I've realised that I missed a couple of folders that allow writing access by default in a LUA. These are as follows:

C:\WINDOWS\pchealth\ERRORREP\QHEADLES
No files in this folder are allowed to be executed. Therefore, an SRP block rule is not required, as Windows' own folder security has already blocked all file execution.

C:\WINDOWS\pchealth\ERRORREP\QSIGNOFF
No files in this folder are allowed to be executed. Therefore, an SRP block rule is not required, as Windows' own folder security has already blocked all file execution.




However, another Wilders post (which I'm always wary about, given the large amounts of mis-information from these forums) reads as follows:
http://www.wilderssecurity.com/showpost.php?p=1605119&postcount=4

"It seems like I do need a deny path rule for c:\windows\temp after all. I can still execute files from a command prompt in that folder, provided I am in another folder and specify the full path to the executable."

I don't understand how to do this. Can anyone instruct me how? I guess the poster is saying that he can still execute files in C:\Windows\temp from a command prompt provided it is done from another folder? I don't quite understand that, because for this to be possible, two things need to occur:
1. The Limited User needs to write executable code to C:\Windows\temp - my question here is how this can be possible given the Limited User can't even Read that folder?
2. The Limited User needs to give the command to execute the code in C:\Windows\temp - again, the similar question is how this can be possible given the Limited User can't even Read that folder?

Regardless, I would recommend that all Limited Users have their Command Prompt blocked from opening with a simple SRP rule (see my security setup/approach post). With this configured, even if it's possible to write and execute code in a folder that you can't even Read (via the command prompt), you can't do so, since the command prompt is blocked from opening.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by wat0114 on 11/5/2010, 11:58

ssj100 wrote:
However, another Wilders post (which I'm always wary about, given the large amounts of mis-information from these forums) reads as follows:
http://www.wilderssecurity.com/showpost.php?p=1605119&postcount=4

"It seems like I do need a deny path rule for c:\windows\temp after all. I can still execute files from a command prompt in that folder, provided I am in another folder and specify the full path to the executable."

I don't understand how to do this. Can anyone instruct me how? I guess the poster is saying that he can still execute files in C:\Windows\temp from a command prompt provided it is done from another folder? I don't quite understand that, because for this to be possible, two things need to occur:
1. The Limited User needs to write executable code to C:\Windows\temp - my question here is how this can be possible given the Limited User can't even Read that folder?
2. The Limited User needs to give the command to execute the code in C:\Windows\temp - again, the similar question is how this can be possible given the Limited User can't even Read that folder?

Hi ssj! Well now I know why you don't post at Wilders anymore Very Happy Congrats on your forum! Anyway, I've tested this quickly. I'm sitting at a laptop with Win 7 HP (will try XP later, sorry), limited account, no srp. I am easily able to write to C:\Windows\temp. I can open a command prompt, change directory to that one, then when I try to launch it. I get a UAC prompt. So, I would say that at the very least under these limited, built-in protection measures, it is not easy for an unauthorized executable to launch in this folder. I had to provide UAC credentials to read the folder in the first place. Of course I don't know about XP yet, but maybe later I'll try. OT, but maybe worth mentioning, Applocker properly setup (easy to do using auto-generate rules) under Win 7 Ultimate makes this concern a complete non-issue.

wat0114
Advanced Member
Advanced Member

Posts : 152
Join date : 2010-05-11

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 11/5/2010, 12:04

Hey mate. Well, this forum has only been up for about 4 weeks. Anyway, good to see you here.

This is exactly the point, as you wrote (sorry the quote function on this forum is down for the moment):
"I had to provide UAC credentials to read the folder in the first place"

That's exactly the point! You had to run with elevated privileges to even READ the folder in the first place. So how can a limited/standard user even write and execute files in C:\Windows\temp when they can't even READ the folder? It's not possible to my knowledge, but someone like you may be able to come up with something...

Whatever AppLocker can do, SRP can also do (but it may take longer haha). Besides, with SRP, you can simply add a deny rule to C:\Windows\temp if you're that worked up about it. However, as I've explained, there isn't a need to, unless you can find a way to write to and execute from C:\Windows\temp without being able to READ the folder.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by wat0114 on 11/5/2010, 12:15

[quote="ssj100"]

That's exactly the point! You had to run with elevated privileges to even READ the folder in the first place. So how can a limited/standard user even write and execute files in C:\Windows\temp when they can't even READ the folder? It's not possible to my knowledge, but someone like you may be able to come up with something...
[quote]

Right, and I tend to agree wholeheartedly with you. More later after I test it under XP with SRP enabled (two comps in the home setup this way).

wat0114
Advanced Member
Advanced Member

Posts : 152
Join date : 2010-05-11

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 11/5/2010, 12:46

Yes, and did you notice the other folders I mentioned above? In a limited account, you either cannot READ the folder (which effectively prevents writing and executing), or the folders are configured to independently prevent execution themselves (therefore rendering SRP/AppLocker redundant). And this is all by default.

Seriously, I don't mean to sound arrogant, but I feel like I'm the only one who seems to know about this haha. Even Windchild's response on the Wilders forum suggested that he doesn't know about this:
http://www.wilderssecurity.com/showpost.php?p=1604349&postcount=2

"In short, it's a good idea to create a SRP disallow rule for Windows\Temp..."

Is it really? Surely not when those folders already have execution prevention independently configured or if those folders cannot even be READ.

"If one doesn't do that, it'll leave easy ways to walk right around the Software Restriction Policy."

What? Those default folders that allow limited users write access either cannot be READ by them, or they are already configured to prevent execution...

"Windows doesn't need limited users to be able to execute files from temp folders to function just fine. What will break is any program that expects to be able to dump executables in temporary folders as a limited user and just execute them from there, which would be blocked by SRP."

I presume he means "dump executables" in C:\Windows\temp. And if he does, how can the limited user "dump executables" in a folder they can't even READ?

Or am I just completely missing something here? Thanks wat0114.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 11/5/2010, 15:26

Wow, just got a PM from someone who doesn't want to be named haha.

Here's how to write and execute files from a folder you can't READ:

open cmd.exe, then use command to copy:
copy "C:\Program Files\Stuff\file.exe" "C:\Windows\Temp\file.exe"

then to execute:
start "testing" "C:\Windows\Temp\file.exe"


I just tested this and it works! Thanks ********* for this information. He/she of course pointed out to me that my security setup/approach involved blocking cmd.exe with SRP, meaning this method would be easily blocked.

Anyway, I knew the command prompt was too powerful for limited users to have access to! No doubt other scripting execution would be dangerous also, and that's why my SRP is configured to block those including vbscripts etc (see my security setup/approach post under SRP).

Just a note to wat0114 of agreement once more - with AppLocker (as opposed to SRP), you won't need to add any more rules like this, since attempted execution of anything new would be blocked. However, I would be tempted to still add cmd.exe etc to my blocked rules in AppLocker, since I believe the command prompt should have no use in a limited user account for the vast majority of people.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by wat0114 on 11/5/2010, 20:35

Interesting to be sure, but I ask: how does the command prompt open in the first place for this to happen. The rogue files doesn't just magically open on its own; a number of processes have to occur (sorry, I don't know what they are, but it has to happen) before the rogue app launches. It has to somehow copy itself to the directory, then some malicious process has to open cmd.exe and launch the entries to launch the malicious file, which then has to somehow complete its maliciousness within a limited account (assuming someone's wise enough to run this way). This is a nice POC but it will, I'm afraid, needlessly scare a number of people into thinking their current limited account setup, perhaps bolstered with SRP or some other 3rd party app, is vulnerable to malware. Very easy to demonstrate by manually entering it all in, but how does this transpire in the real world? Of course nothing's 100% as you've already accurately declared, but ~ 99% along with some common sense (meaning steer clear of the rogue websites (yeah, porn is tempting to us all, but there are safe porn sites and unsafe porn sites; it just means identifying them) and download from the software author's website or some place like Snap files or Beta news. Of course if you want the best Windoze "built-in" safeguard, at least what I've experienced, Applocker in Win 7 Ultimate is the dog's bollocks Very Happy

**EDIT**

please see here: http://www.wilderssecurity.com/showpost.php?p=1675827&postcount=33

wat0114
Advanced Member
Advanced Member

Posts : 152
Join date : 2010-05-11

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 12/5/2010, 02:51

Thanks wat0114! I knew I was missing something. And Windchild is a fountain of knowledge for sure. Sometimes I still feel I owe him for strongly suggesting me to properly try out LUA. Haven't looked back since!

C:\Windows\temp is indeed an issue, even though you can't read/access it. I haven't tried it (not on usual computer) yet, but I'm guessing you can simply drag and drop files into C:\Windows\temp and therefore bypass having to read/access it. A poster on the Wilders thread suggested that the browser (or whatever "threat-gate") would still be restricted from accessing the folder in order to execute the written file.

I think I tend to agree...the browser (or whatever "threat-gate") would need to be exploited specifically to use the same (or similar) commands as what cmd.exe uses to execute a file you don't have read access to. Is this truly possible and are there any examples (POC or real malware) of this? The key aspect is how do you execute a file that you can't even READ without the use of cmd.exe? I think Windchild suggests that eg. a browser exploit would do it, but wouldn't that exploit's code have the same problem of READ access to the executable in C:Windows\temp (since the browser is being run with limited rights)? Hence my question if this is even possible without the use of cmd.exe and if there are even any POCs for this (eg. a POC which exploits the IE browser and somehow creates a file in C:\Windows\temp and also manages to execute it without having READ access).

In any case, adding 2 extra block rules to your SRP for C:\Windows\temp and C:\Windows\system32\spool\PRINTERS (and note this is for a default fresh Windows XP install with no modification from the manufacturer) would solve the issue completely.

And you are of course right in saying that the risk of a malware specifically targeting C:\Windows\temp or C:\Windows\system32\spool\PRINTERS and somehow exploiting your browser (or whatever "threat-gate") to specifically write and execute from these folders (without having read access) is going to be extremely rare. However, thanks to Windchild, I think I'll be adding 2 further block rules to my SRP for the heck of it!

I've been testing AppLocker a lot myself in my Windows 7 VM, and I didn't realise that eg. any new executable written to C:\Windows\temp would be unable to execute AFTER the rules have been set. Look forward to testing AppLocker more, and to use it when I eventually fully move to Windows 7 in a few years time.

Thanks for your valuable contribution wat0114 and for the link to the Wilders thread. Hope to see you around more!

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 12/5/2010, 12:23

By the way, it's all very well talking about C:\Windows\temp, but have a read of what I wrote above here:

"C:\Windows\Registration\CRMLog
No files can execute here (outside of the SRP allowed list), so an extra SRP block rule for this folder is not required by default. Note that vbscript executables are allowed to run here, but if you follow my security setup/approach post (under SRP), you will note the additional rules of blocking wscript.exe and vbscript.dll. By blocking (either of) these 2 files, vbscript executables are unable to run from this folder. And I repeat, a separate SRP rule to block execution from this folder is therefore not required!"

Fact is, the windows file/folder permission rules allow Limited Users to read, write, and also execute vbscript (and who knows what other types of script etc). I've tested .bat files, and the usual binary executables (eg. .exe file types) and execution is denied here. However, the fact that vbscript can be executed here is of concern, given the folder pretty much allows Limited Users to do what they like in it. So in this case, I would agree that an additional SRP deny rule would be required for the folder C:\Windows\Registration\CRMLog.

And in fact, there isn't any harm in adding all of the above folders I mentioned to the SRP deny list. Most of the folders are denied execution anyway via Windows' own file/folder permissions. So adding them to the SRP deny list would perhaps make things more certain haha.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by tnegjm on 12/5/2010, 20:39

In W7 Applocker I used default rules and added a deny rule for wscript.exe, and vbscript.dll (and the others mentioned above). When blocking vbscript.dll it will break desktop gadgets from working properly in LUA/SUA if anyone is concerned. I can keep wscript.exe blocked and allow vbscript.dll and they work again. Maybe setting a security permission to deny read/write in LUA/SUA on this one folder/file (C:\Windows\Registration\CRMLog) to block vbscript.dll would be better if someone wants to use desktop gadgets?

I haven’t noticed any other problems when adding the other deny rules mentioned in your setup thread here: http://ssj100.fullsubject.com/free-for-all-f4/ssj100-s-security-setup-t4.htm.

Another thing in W7 I noticed is when creating deny rules “everyone” will also block Admin. I know Applocker is default deny but In Admin I’d like to still use cmd and regedit among others. For now I just set deny to my LUA/SUA account since it’s the only other account besides Admin that I have active. Is there a user group for everyone besides Admin that I could use here instead for better protection?

tnegjm
Member
Member

Posts : 37
Join date : 2010-04-20

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 13/5/2010, 00:20

For me, I would be glad that desktop gadgets are broken haha.

However, why do you need to add extra rules if you are using AppLocker? I've been told that AppLocker doesn't allow any newly written/created executables to run once you've applied the default rules on the relevant folders. I'll install Windows 7 Ultimate into my VM soon and test it out.

And why would you be applying rules to "everyone"? There's no need to apply rules to the Admin account if you use your SUA predominantly, and only use your Admin account for installing/updating applications.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by tnegjm on 13/5/2010, 00:45

I don't really care about desktop gadgets working or not either. I was saying for those that do care what broke for me when testing.

I guess I don't need any other rules if using Applocker. Thanks ahead for testing that.

"Everyone" is the group that Applocker defaults to. I agree in that I don't want to use "everyone" but do want to use a group (any ideas which one?) for everyone except Admins. I'm looking for another group that includes everyone but Admins to set to deny those other rules. That way I can use SUA predominately and only use my Admin account for installing/updating applications as you said. Right now I'm setting my SUA account for the deny rules which is good but to be more secure shouldn't I set a more encompassing group? One that includes everyone BUT Admins.

tnegjm
Member
Member

Posts : 37
Join date : 2010-04-20

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 13/5/2010, 08:14

I see what you're saying. I'll have to look at AppLocker again myself to see what other options there are. With SRP, you can simply set the option to apply SRP to "everyone but admins".

I have a feeling that AppLocker can be easily configured the same way. Cheers.

EDIT: just tested AppLocker - using default rules for each category will still allow files to be written to and executed from certain folders. Using automatically generated file rules takes a longer time for the folder C:\Windows, but I think this turns out to be more secure. However, I don't think it's very practical if you haven't installed everything you need to on your system or if you like installing new programs frequently - they will be unable to run without the updating of the AppLocker rules!

Therefore, in my opinion, it might be better to just apply the default rules and then add further rules to deny execution from the 14 folders as described by MrBrian. It's a bit galling that Windows 7 has so many more folders than XP that allow writing and execution to, even in a Standard User Account! Makes me feel that Windows 7 is less secure than XP in this sense! MrBrian suggests there are 14 folders that allow writing and execution in C:\Windows, even with SUA. In Windows XP, there're really only three or four (four if you count the folder C:\Windows\Registration\CRMLog, simply because it allows Vbscript execution).

So to summarise, in Windows XP Professional default installation, only four folders allow writing and execution in Limited User Accounts. In Windows 7 Ultimate default installation, at least 14 folders allow this! Why Microsoft why!


Last edited by ssj100 on 13/5/2010, 13:39; edited 1 time in total

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by tnegjm on 13/5/2010, 19:30

Did you find out how to set "apply everyone but Admins" in Applocker? If not how did you set your Applocker rules? Thanks again for testing W7.

To be clear, you set these extra 7 rules for each Applocker section of "Executable", "Windows Installer", "Script", and "DLL" rules correct? Or just in the "Executable Rules" section?

tnegjm
Member
Member

Posts : 37
Join date : 2010-04-20

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by wat0114 on 13/5/2010, 20:55

tnegjm wrote:

"In W7 Applocker I used default rules and added a deny rule for wscript.exe, and vbscript.dll (and the others mentioned above). When blocking vbscript.dll it will break desktop gadgets from working properly in LUA/SUA if anyone is concerned. I can keep wscript.exe blocked and allow vbscript.dll and they work again. Maybe setting a security permission to deny read/write in LUA/SUA on this one folder/file (C:\Windows\Registration\CRMLog) to block vbscript.dll would be better if someone wants to use desktop gadgets?

I haven’t noticed any other problems when adding the other deny rules mentioned in your setup thread here: http://ssj100.fullsubject.com/free-for-all-f4/ssj100-s-security-setup-t4.htm.

Another thing in W7 I noticed is when creating deny rules “everyone” will also block Admin. I know Applocker is default deny but In Admin I’d like to still use cmd and regedit among others. For now I just set deny to my LUA/SUA account since it’s the only other account besides Admin that I have active. Is there a user group for everyone besides Admin that I could use here instead for better protection?"

tnegjm (maybe you are timestand at Wilders?), You really should try to focus on whitelisting rules only with Applocker. You will only create possible security holes, while adding innefficiencies to your ruleset when you try to combine allow and deny rules. I highly recommend you read through: How Applocker Works from this link:

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

ssj100 wrote:

"EDIT: just tested AppLocker - using default rules for each category will still allow files to be written to and executed from certain folders. Using automatically generated file rules takes a longer time for the folder C:\Windows, but I think this turns out to be more secure. However, I don't think it's very practical if you haven't installed everything you need to on your system or if you like installing new programs frequently - they will be unable to run without the updating of the AppLocker rules!

Therefore, in my opinion, it might be better to just apply the default rules and then add further rules to deny execution from the 14 folders as described by MrBrian."

Hi again, ssj! sorry to disagree, but there is simply no way once the whitelist rules are created, that a new file should be able to execute from any folder at all, including the temp folders and those others that mrbrian points out. Also it does not take that long to autogenerate a rule for a new program, then simply export the config for safe keeping.

wat0114
Advanced Member
Advanced Member

Posts : 152
Join date : 2010-05-11

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by tnegjm on 13/5/2010, 21:32

Thanks wat0114. I did read that Microsoft and realize Applocker is default deny and to try and only set allow rules. I guess this can't be done with default rules. I can't allow everyone to execute in C:\Windows (one default rule) and then try to allow everyone to execute in C:\Windows except for the 7 folders listed above. All folders in C:Windows will still be allowed to everyone. Are you saying to automatically generate the file rules to whitelist instead of manually trying to?

I'm not timestand at Wilders but whoever it is rings very familiar. I have a guess though.

tnegjm
Member
Member

Posts : 37
Join date : 2010-04-20

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by wat0114 on 14/5/2010, 00:27

Sorry, tnegjm, I thought you might be the Wilders member because he referenced me to this forum/topic.

You could create whitelist path rules for C:\windows, where one is allow for everyone with an exception to :C\windows\system32\com\dmp\*, and another one with full access to a selected user member.

However, this should still be unnecessary, because the idea with Applocker is to create the rules, preferably using the Auto-generate feature, on a system that is fully setup with all the software installed. As I've mentioned before, even if somehow a malicious files were to download to one of those 7 folders you listed, it can't possibly execute because the file will not be in Applocker's whitelist of previously generated rules. The machine is essentially "locked down" with a default deny policy in place. Only an individual with admin rights can install new software, then of course create a rule(s) for it to allow everyone to launch it or only selected users. Allow rules with exceptions are generally best used for when you might want to deny limited users to certain applications such as games, for example. this is usually done in an enterprise environment.

wat0114
Advanced Member
Advanced Member

Posts : 152
Join date : 2010-05-11

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 14/5/2010, 00:30

tnegjm wrote:
"To be clear, you set these extra 7 rules for each Applocker section of "Executable", "Windows Installer", "Script", and "DLL" rules correct? Or just in the "Executable Rules" section?"

Yes, I think generally you should use a white-listing approach, with further deny rules for the folders that allow standard users to write to, like the 7 folders stated above.

wat0114 wrote:
Hi again, ssj! sorry to disagree, but there is simply no way once the whitelist rules are created, that a new file should be able to execute from any folder at all, including the temp folders and those others that mrbrian points out. Also it does not take that long to autogenerate a rule for a new program, then simply export the config for safe keeping.

No, there is a way for sure. If you've only used the "create default rules" for each category, then Standard users can still write and execute from those 7 folders as stated above. Instead, you need to automatically generate rules for each category (and if the file isn't digitally signed, use file hash rules). This is obviously a problem as described by timestand in that Wilders thread, as it means you'll need to potentially keep updating your AppLocker rules every time you update a program. If you used path rules instead of file hash rules for non-digitally signed objects (via the automatic generator), then I think those 7 folders described above will be allowed write and execution privileges.

In saying that, I'm not sure if third party programs would require writing and execution from those 7 folders anyway, so you should be able to get away with using file hash rules instead of publisher rules on C:\Windows directory.

However, with Windows XP, you'll need to add those four (or seven) folders that I described earlier to your SRP deny list...there's no AppLocker in XP haha.

Would that sound about right wat0114? Thanks.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by wat0114 on 14/5/2010, 02:17

Yes, sorry not to clarify earlier that just using default rules does, indeed, allow users to write/execute from those directories. Auto-generating rules, as many Publisher as possible, followed by hash then path is certainly the best way to "lock down" those directories, since it's because the current applications are scanned and accounted for, so anything else added later and attempting to execute will be stopped. However, the defaults could be used with "Exceptions" to those other directories. I wish I could post a screenshot or two to clarify, but it can be done Smile Of course under XP extra rules for those folders are necessary.

wat0114
Advanced Member
Advanced Member

Posts : 152
Join date : 2010-05-11

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by ssj100 on 14/5/2010, 03:45

wat0114 wrote:
However, the defaults could be used with "Exceptions" to those other directories. I wish I could post a screenshot or two to clarify, but it can be done

Yes, that's a good idea - it would simplify the number of rules down a lot.

Anyway, I think either way would work fine, although I'm liking the "create default rules with exceptions or extra deny rules" better than the "auto-generate rules for each folder with publisher or hash or path rules".

I guess I'll decide for myself when I eventually use Windows 7 Ultimate on my REAL system. I'm thinking that maybe I don't really need AppLocker (and therefore don't need Windows 7 Ultimate edition), and could get away with just Windows 7's SRP. It's my understanding that Windows 7's SRP has "improved" over Windows XP's SRP, in that it is kernel-based rather than user space-based. If I'm simply using AppLocker like SRP (default rules with exceptions or extra deny rules), I don't see any advantage of using AppLocker over SRP on Windows 7. Any thoughts wat0114?

And yes, I think I've finally sorted out which folders can write and execute on a default Windows XP Pro install. AccessEnum seems to work really well on XP to tell me which folders can write and execute as a limited user. I didn't think the C:\Windows\Tasks folder could be written to and executed from as a limited user, but soon tested it via cmd.exe and realised it is true. The only reason why I missed it on AccessEnum was because it classified that "Authenticated Users" could write to C:\Windows\Tasks. I didn't realise "Authenticated Users" included Limited Users.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by wat0114 on 14/5/2010, 04:38

In truth, at least imo, run Win 7 (esp x64), SRP with a few extra rules for those other folders, limited account, use common sense, and this alone already provides near-impenetrable defenses - without the aid of any 3rd party apps. Throw in something like Sandboxie for Internet facing apps with some additional restrictions to the defaults, and now you've got a malware's worst nightmare come true Very Happy

Just to add something I found in the MS Technet Applocker articles regarding the use of deny rules:

Deny rule considerations
Although you can use AppLocker to create a rule to allow all files to run and then use rules to deny specific files, this configuration is not recommended. The deny action is generally less secure than the allow action because a malicious user could modify the file to invalidate the rule. Deny actions can also be circumvented. For example, if you configure a deny action for a file or folder path, the user can still run the file from any other path.

wat0114
Advanced Member
Advanced Member

Posts : 152
Join date : 2010-05-11

View user profile

Back to top Go down

Re: Mis-understandings about Software Restriction Policies (SRP)

Post by Sponsored content


Sponsored content


Back to top Go down

Page 1 of 4 1, 2, 3, 4  Next

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum