PGS - Pretty Good Security

oh, I see now what you mean by loading dlls. Lets see if we can make sense of this, theoretically

First we need to for now disregard UAC, as I have not the time or desire yet to really explore it and its implications, although I believe only 2 possible events happen: either you allow and things are written into ProgramFiles(x86), a sort of protected area, or you say OK and things are elevated to admin. Either way, lets assume that UAC is only asking 'should this action be elevated to admin' for simplicity.

The very first thing to understand of course is what a user can do and what an admin can do. The User has permissions to read and execute pretty much anywhere, but can only create or modify in thier user profile directories, custom made directories or drives other than the system drive. The admin of course has no such limitations.

In considering how SRP does its protections, we need to remember that it is only an allow or restrict approach to monitored executables, which are defined in the executable list. So .lnk and .exe are by default both monitored and treated as applications and therefore will be checked to see if any Software Restricion Policies exist for them.

SRP presents no magic bullet of protection. You can deny a program, restrict a program to 3 different levels of rights or just allow a program unhindered. It is in how you set these parameters that you get results.

In regards to whether a program can write suspicious files to some directory or whether some dll can be loaded and code ran, is in direct regards to SRP settings and the parent processes' rights.

So consider each scenario. First, we want to keep a process such as a browser or email client or even media player from dropping files into sensitive areas. Sensitive areas have been defined by the OS as c:\, c:\windows and c:\program files. These areas for a User are off limits. So what can SRP do? It can start the programs we want restricted as a Basic User. So now when IE starts, even though you are an Admin, SRP will demote IE to being a Basic User. If all things are right in the world, IE will not be able to create or modify in a protected area. If you wish to be able to use the cache and keep bookmarks, download pictures and music etc, then the User account must have access to the profile directories. Since this is usually the case, IE could drop a trojan.exe into My Music directory. But what can it do? In order for trojan.exe to start without you actually starting it, IE would have to start it. And perhaps it could. But even if IE were to start trojan.exe, it will inherit the same rights as its parent has, which in this case since IE is starting trojan.exe, trojan.exe will not be allowed to modify anything in protected areas. You can see that if you were to get a keylogger, it could write to your profile directory and even run, because IE is telling it to, albeit with reduced rights.

But there is a solution if you are so inclined to use it. By setting the default action in SRP to disallow, and only having 2 allow rules (allow in windir and program files), then nothing can run outside of what the OS has or what is already installed into program files. You explicitly create a rule to allow IE to run as Basic User. Now when IE runs, it is still run as a User. When it drops trojan.exe into the My Music directory, it will succeed. But, when IE tries to start trojan.exe, it will fail. Unless you explicitly state that either all of the My Documents can run or a program named trojan.exe can run, it will fail.

Lets say that somehow IE spawns code in a dll (loads it), and that dll lives in sysdir. The dll code says to do something or another in a protected area. When IE starts as a User, this dll code 'should' inherit the rights of the parent, being therefore restricted to User and protected areas are prohibited. But, and I don't know for sure on this, suppose that the dll code was not 'inheriting' the restrictions of IE. The option in SRP to apply to all files INCLUDING dlls should do the trick. While MS does not exactly give all-inclusive information many times, what I have read leads me to believe that when you are including dlls into SRP then any dll not associated with IE will be treated according to your SRP rules. That is, if you are in default deny, a dll code may not be loaded unless you explicity make an exception, and if you are in default allow, but are applying a restriction of Basic User to IE, then any dll loaded by IE or a child process of IE should inherit the same restrictions. This is why some programs don't work with SRP without some exceptions because the libraries it uses need rights or are being blocked from running.

Now maybe someone who knows more about this can test this, as MS does not give clear data that I have seen. But you should see, that SRP can be effective, and depending on how you set its options, can be very loose or very tight.

Hash rules. If I could have made the registry value required (Qword) I would have included it into PGS. I personally would use some hash rules. Any program that I do not feel would update, ever, would get hash rules. That may not be many programs, but it does offer a greater level of protection than simply a name/path.

Sul.

 

Thak you very much Sully!

I will think about all this.


Btw.: Is PGS supporting Windows7 64-bit?

best regards.

 

Bump

+1

Really into it...any update at all? Please please please...

 

Currently busy retooling injection systems at work, lots of hours. Got some honey-dos as well. January/February should bring some free time again. I have a copy of 7 64bit to try it on. There are some other requests I want to look at as well.

Sul.

 

Really and truly glad you did reply, Sul!

7 64bit - same here! looking forward to it!

see you soon with an update

peace

 

Where can I get the latest version of PGS? Thanks.

 

here:

http://mrwoojoo.com/PGS/PGS_index.htm

enjoy

 

I would also like to know if PGS works well on Windows 7 x64. I'm interested in getting it set up as a layer of protection, but the initial link in this thread indicates that it is not yet supported on Win 7. Without any effective Sandboxing or HIPS solution available for x64 Win7, PGS was my next hope for security.

I apologize for this question, but I'm a bit of a layman. Would this kind of SRP implementation prevent programs from auto-updating themselves? There are a few programs I run that download their own updaters, install those updates from a separate executable, kill the original task, and then overwrite and relaunch the original task. I can see that as being easily blocked as the program dropping a file and being prevented from running, or overwriting.

 

PGS is only a front end for windows SRP. SRP is capable of 3 types of restrictions it can impose on an executable it is aware of. You can 1- Allow, 2- Deny or 3- Restrict. The first two are simple, the last one, restrict, essentially means to restrict to User level of rights, just like LUA does or DropMyRights does. It monitors a particular executable, or a place where any executable lives (like a directory) and any executable starting then gets the SRP rule applied to it.

SRP was in XP Home, but not 'engaged'. A simple set of registry files was all that was needed to engage it. In XP Pro it was present already, but the interface left a bit to be desired IMO. In vista it was the same thing basically, lower versions did not have it engaged and the higher versions still have the same interface.

PGS is only creating a new front end to SRP. I designed it to help you if you want to use SRP without having to use .reg files and hopefully in a quicker manner than the in-built front end.

PGS may or may not do what you request in your example. Look at it this way, if you start programX, and use SRP to restrict it to what is called a Basic User, programX can now not write to specific places because it is being ran as a User, NOT as an Admin. If programX tries to go online, it will be allowed. If programX tries to change something in a restricted area, it will NOT be allowed. If programX tries to write in an area that is allowed, it will do so.

So it really depends on just what programX wants to do.

SRP is designed really to deny applications in most respects. You could deny the child program that programX is starting. This might work. On the other hand, many like myself just use it from the admin account so that some programs are denied outright, and some are simply restricted to User level, which helps to contain the threat they might pose.

I suggest you look into SRP a little more to understand its implications. If you choose to use SRP then PGS should be able to make things a little quicker/easier for you.

Sul.

Edit: I have had PGS working on 7 beta, so I know it can work. I have not tried any 64bit yet, but I believe it should not be an issue. I just have to install 7 again and play with the structure of everything a little bit. I initially was messing with it on 7 to see if I could manipulate AppLocker in the registry, which is possible because it looks like .xml code. If you have SRP available in 7 64bit right now, you can use it even if PGS does not support it yet. Remember PGS is only a GUI to SRP.

 

That would be very cool!

If you find a way to enable full Applocker Protection in the professional version of Windows 7 you are my hero Sul!

It would be so nice to work with the publisher rules! That is an awesome feature i think!

 

I'm on the edge of getting Win7, BUT:

I don't believe Sul will be able to activate AppLocker from Family premium or pro...

Don't dream. I hope I am mistaken. I really do.

 

Yeah, I don't know about making AppLocker work in the lower versions. I have not even looked at that yet. What I am talking about is making a tool to create/modify app locker entries, so you don't have to use the MS interface to it.

Time will tell.

Sul.

 

Have there been no updates to v1? So v1 is the latest version of PGS? Thanks.

 

Yes, v1 is the only release version. There were many betas, but no updates since final. This will likely change this winter/spring.


Sul.

 

Alright, Thanks Sul!

 

I have finished playing with Windows 7 32bit and SRP.

SRP no longer is an option for Administrators who wish to tighten things up a bit. The option "Basic User", which could be used in XP to retrict an executable to Users rights is no longer valid in 7. Instead they offer AppLocker.

SRP does appear to work in the same fashion if you are a User, and you wish to create a default deny situation. PGS does seem to work as well, given that you use it as LUA, you can modify the executable extension list and apply path rules to block or allow.

The awesome option to use AppLocker over SRP seriously makes me wonder about just how serious M$ is about this concept at all. They must know that many users simply are administrators, and do not want UAC blaring at them all the time. But, they have taken the road of LUA I suppose to the end.

Suffice to say, that so far from my testing and what tech articles I have seen, if you plan to use Windows 7 and be a full-blown Administrator, SRP won't do much for you other than block specific items/directories.

The 'more better' option to use AppLocker is, well, perhaps better at a core level, but it is really nothing different than SRP on 7 now. Both now only give the option, allow or deny. There is NO MORE BASIC USER OPTION in Windows 7 IF YOU ARE AN ADMIN... that I can find.

So, what shall I do with PGS then? Include an AppLocker area? It is easy enough to do, just some xml type formatting of the registry values. I don't know that it would offer much over the current interface to AppLocker though as it already can import and export, unlike SRP.

It would seem I am starting from scratch now on what to do exactly with 7. Such a shame.

Sul.

 

Hey Sully.

Is it possible to implement the AppLocker Publisher rules into SRP?

And is it possible to accomplish the AppLocker rules on Win7 Professional using SRP? Cause normally you can set up the rules in the Pro version but you cannot activate them at all.

What about x64?

Big thanks so far!

 

Here is what I know so far.

SRP on XP and possibly Vista are triggered by the creation of a process, aka running a program. Each process created looks into the registry @ the SAFER values to see if there is a rule that needs applying.

Home versions which lack the interface to SRP still had the registry keys available. So PGS and reg files simply put the values there manually. There is nothing special in this, as the OS checks those registry keys regardless of the version.

In windows 7 things have changed. The development of AppLocker is designed to be much more robust not in the rules you can make, but in how it activates at a much lower level than SRP did. This is a good thing. This is actually called in the registry srpV2.

7 does not behave as XP did concerning srpV2. You can make a rule easy enough with a .reg file. But so far, I have not been able to get those to work. It seems (and this may or may not be correct) that the only way to get an AppLocker entry to work is to use either the mmc tool, or a cmdlet. The cmdlets are interfaces to AppLocker that you can script with.

SRP offered much the same as AppLocker in the sense of you can create default deny or allow states. AppLocker brings the ability on a per user or per group basis rather than SRPs per machine basis.

My favorite feature of SRP was that you could force specific objects or containers to run with reduced privelages (basic user) very much the same as Drop My Rights. For those that run as an Administrator this was a great tool.

Now Windows 7 has done away with that feature completely. They wish to force the hand into everyone running LUA. That is not a bad thing at all. But some of us simply do too much to be bothered by the RunAs usage, so we wish to be Admin and we take the risks knowingly now in 7.

UAC is a joke in 7. POC attacks show how easy it is to evade it. The only way UAC works in 7 is if you raise it to its highest form, where it asks about everything. This is obviously similar to Vista and can become very annoying.

The other thing about 7 that is a joke, if it is still valid, is that M$ decided to trust thier own applications, such as paint or wordpad, so that UAC does not give a prompt when it needs to. I have read articles on how they use signatures so that it will be safe, but I have also read articles on how easy it is to bypass the default UAC in 7 with something like a dll and rundll32.exe.

This leaves me with the feeling that for windows 7, only the versions that support AppLocker can use it at all, unless the cmdlets will work to create AppLocker rules in the home type versions of 7. I don't have one of those versions so I cannot test. I don't feel that the inclusion of anything for AppLocker into PGS will be of any value.

Indeed, PGS can make values into win 7, but I am not sure they take effect on the home versions either. For sure, it you are not using LUA in win 7, SRP offers you nothing really to speak of.

I find myself looking at 7, and thinking that for all the talk of how much more secure it is, if you are not using LUA, there is no difference between it and win 2000 or xp. I personally think XP is the most secure of the bunch if you wish to run as Admin and use some alternate programs such as Opera.

Everything is shifting to a LUA world now, finally. I am thankful they are doing that. I only wish they had some options for those of us who really are going to stay as Admins.

I am quite sure I will pound this some more. But honestly I cannot find enough data on win 7 yet to really know how to tweak it. Try to find some documentation on AppLocker other than the generic 'how to setup rules' stuff. I am trying to find a white paper on the structure of the registry value, which is a xml type syntax.

So for now, I might take away the warning about windows 7 in PGS, but I don't know that updating it will do much different that it does now.

Ideas though are always welcome.

Sul.

 

I had seen that, thanks for the link though.

I was looking more for some syntax examples of the applocker registry entries. It appears that is a fruitless effort though, as man-made rules, in exact form, don't ever seem to be used. I think perhaps it is buried in the GPO instead of just registry entires. Which makes sense really.

Sul.

 

Say what? It offers the same protection in 7 as it did in XP, does it not? Or am I missing something

 

lol, you are missing only a very small something

To say, if you are Admin, not User, in win 7, SRP offers only allow or deny, which is less than what XP offered.

It does offer the 'same' protection in how it implements denial of process creation. But not the 'same' amount of 'options' in that protection would have been a better way to word it.

Sul.

 

Hi Sully, does this include what I found in my testing - that you cannot exclude local administrators from the SRP policy using PGS? i.e. run PGS with admin rights under LUA, apply SRP to LUA account, select "exclude local administrators", but SRP is applied to both LUA and Admin. Thx

 

It works like this.

You are Admin, you include admins in SRP, and rules effect Admin. Of course this is useful to only deny or restrict as Admin has full rights. In win 7, using SRP does not provide as much benefit because you lose the restrict option and only get deny.

If you are LUA, you exclude admins in SRP. In this manner, when you RunAs an admin, you are sure they have full rights still. In the typical situation you use SRP to deny all but the defualt rules so that the LUA cannot run programs outside the defaults without special SRP rules.

When using the registry variation that PGS uses instead of the Group Policy that the Security Policy uses, the features should still work the same. AFAIK if you are LUA, and you run PGS with admin rights, create a rule such as deny notepad.exe but exclude local admins, it works as expected. However, you must restart the shell or logoff/login for this to take effect. You can also I have found in PGS simply change the setting from "all files including dlls" to "all files excluding dlls", or vice-versa, and apply, and this somehow forces a refresh usually.

I have not seen yet what you speak of, where from LUA you run PGS as Admin, and then have the rules apply to Admins as well as LUA as long as the exclude admins option is checked.

Sul.

 

Ah, so it(SRP) doesn't recognize the reg setting for basic user? Hmm, I just opened up regedit and noticed the key 131072 with a subkey of Paths and both being empty.