Is Microsoft joking with us?

I think they are!

It's possible to restrict applications from running in Windows, via Group Policy Editor (or via Registry, for those who know how). To block the applications we type the name of the processes.

Somehow, I thought that it would also block such processes by checking the hash values of those processes. Apparently, it does not. So, if I block application A, by entering the process name, then all a user has got to do is to rename the processes names, and that's it, free pass.

Yes, I'm aware that there are other ways (better ways) but Microsoft does provide this feature, and it's flawed to the core. This begs the question: WTF? Why does such feature exist, if it's 100% useless?

 

why do you want to disable certain applications? why not just avoid installing stuff you don't want on your pc?

 

First of all, my restrictions are done using other measures. So, I got no issues. Secondly, I'm just wondering why such feature would exist, if it's 100% flawed, and therefore useless?

We're talking about a security policy, and therefore it should be effective, and it is not.

But, I'm starting to get used to stupid Microsoft choices.

 

Uh, yeah, of course.

 

Which part of Group Policy Editor are you talking about?

 

Are we talking about SRP/Applocker?

You can block by hash, filename and some very fine grained publisher details (in Applocker only).

Typically, if you want to use SRP effectively, you have to allow everything in protected / admin-only write areas (Program files & Windows). Then you have to disallow everything else. Anything you want to let them run, you must manually allow. Doing it the other way around (blacklisting specific files) is literally impossible.

Since a regular user doesn't have rights to these folders (like the windows directory), it can't write anything or rename anything. Without this separation, you can't effectively use the rules. Its very easy for a person to change both the hash of the file (think resource hacker) or the file name... but you can definitely disallow by hash.

The primary strategy is to completely disallow the user from writing anywhere except where it absolutely needs to. That is basically done for you if you operate as a standard user. All of the files you may need to disallow should be in the windows directory, or in the program files folder. If you want to allow processes to run in user land, you must manually allow them.

 

@m00nBl00d,

how does a user with standard or limited rights change the name of a program in the first place, without "Full Control" "Modify" or "Write" privileges?

 

Couldn't you just copy the program (IE CMD.exe) from another computer you have control over to the desktop of the victims and then rename it to notepad.exe and run it? As it is now in your desktop you can modify it.

(not that it is a challenge to subdue those flags anyways. MS's permission system is complete fail and can be bypassed with insane ease.)

 

User Configuration -> Administrative Templates -> System -> Don't Run Specified Windows Applications

 

I'm not even going to debate eventual holes that probably exist, and allow bypassing it.

I'm going to stick with a simple example.

Imagine I have three users. I want two of them to be able to run an application, say a stand-alone executable that's placed in a folder outside Program Files and Windows containers.

Windows 7 allows to (Not sure about Vista, etc.) use GPO so that I can allow some and restrict some.

Hey, nice. Microsoft also allows me to make use of User Configuration -> Administrative Templates -> System -> Don't Run Specified Windows Applications to restrict the application I want, to that specific user, by entering the process name. Unfortunately, it only works with names. It does not work with hashes. So, all the restricted user has got to do is a very simple thing -> Rename it, and free pass.

If we're dealing with a security policy, then it should act as such. It doesn't, at all.

It's a very lame "security policy".

P.S: Tweakings aside (that is, ACLs), this "security policy" should act as security policy. That's basically my point. Maybe you won't agree, but that's my point of view.

 

Sure, this probably works, but now you're citing an example of someone having physical access to another's pc, which, of course, evades any security in place anyway. it's game over.

Can you give an example? I'm not doubting you, only rather fascinated by this type of subject matter, and I'm a huge fan of using what's already built-in to the O/S for security purposes, so I really would like to know of both strengths and weaknesses of this approach. Also, I hope some other experts jump in this thread (Sully, MrBrian, Lucy, for example )

But those are programs installed and run in user space you are talking about. The so called "single file" executables. It's a bit trickier for sure to restrict those, unless a default-deny policy is in place like SRP, AppLocker or 3rd party anti-executable, for example.

 

Testing m00nbl00d's example in Win7x64 vm with Applocker policy cleared, I placed iexplore.exe in the list of not allowed to run programs, and in my user account, copied iexplore.exe to my Documents folder, re-named it to iexplored.exe and tried to launch it, but it does not. in fact, even after disabling the policy, I still can't run the renamed iexplore.exe. Only when it's the original name will it run. Am I missing something? Any thoughts on this?

Another example re-naming firefox to firebox. Attached screenshot as well.

 

It shouldn't matter where they are installed. From the moment you a security policy allows to block a process, by adding its name, then it should block it by hash value.

Why should it be trickier to block them? If User Configuration -> Administrative Templates -> System -> Don't Run Specified Windows Applications had been properly designed, it would block by hash value; that is, it would calculate the hash value. The admin should need to browse for the process.

If it worked that way, it wouldn't matter whether or not an user changes the name of that process or even moves it, because it would still be blocked.

See it this way: Policies (Group Policy Editor policies) are mean't to be applied by administrators. Users should "follow" them, and not be able to go around them. If users are able to go around those policies, what good are they?

Then again, not even AppLocker is fully operational... We both know about its weird behaviors.

 

It's clear why both fail. iexplore.exe and firefox.exe weren't programmed to work alone. And, when you move the main process to another place, they won't work. Those processes wouldn't know where to look for what they need to function.

Just rename iexplore.exe within Program Files/Internet Explorer folder itself, not outside.

 

But they both worked when I renamed them back to their original names.

Ahhh, but isn't this the crux of the whole matter, as when I mentioned earlier this is not possible for standard or limited users who don't have full control, write or modify rights

 

Then it means that they're coded not to function, if with a different name. I couldn't say more as I'm not a programmer, though.

You're right about that, and I never said otherwise. But, I never looked at it (the flaw) from your perspective. I looked/look at it from outside Program Files and Windir.

Or did Microsoft consider that apps are only placed in Program Files?

 

You could be right, especially going by the screenshot where it can't find the dll. Interesting subject matter this. I'm glad you brought it up, because I've never really understood this how it works. Hopefully some others will comment on this as well.

EDIT

btw, I tried another one, wwdc.exe (the old Windows worm door cleaner), and it worked when I renamed it. I copied it into the Documents folder first. This must be one of those single file type executables designed to run from anywhere.

 

Well, SRP does exactly this, and I was never aware of the entry in administrative templates. The entry in Administrative templates probably meant to be used for very simple cases, like disallowing executables from non-writable / non-modifyable location.

Why did they put this here? I'm guessing its a dumbed down version of SRP meant for people who couldn't quite handle or understand SRP.

If you want full featured protection, SRP or Applocker is the way to go. Of course, there is a steeper learning curve associated with SRP... this is why Applocker has default rules - too many people locked themselves out of their own system with SRP.

 

Don't forget that starting with winNT, rights and permissions started playing the important role they do now. But NT was not for home use at all. And you note how all versions now come in Home and Business and Pro etc, each getting more and more of the business side of things, yes? Much of what you play with today was originally meant for use in an environment where a set group of admins declared for the users what they could do. In those situations where you as a user were controlled by the admins, they could use features you find flaws in with great success.

Sul.

 

Indeed that is bad, I experience the same behaviour.

You can also have false positives with this.

 

Don't bother with it. Just use SRP or AppLocker.

 

I don't bother with it, at all. I just stepped upon it, and found it to be a lame security policy. No reason to exist in today's context, IMHO. That's all.

 

That flaw has existed since Win 98. The layout and features have changed some, but it's still the same nearly worthless joke. In Win 98, the system policy editor could be used as a primitive whitelisting tool where you specified what was allowed instead of what was blocked. As far as I can tell, the only purpose it serves is to keep the typical, unknowledgeable user honest. Seems little has changed. Any other tool is preferable.