Is Microsoft joking with us?

Discussion in 'other security issues & news' started by m00nbl00d, Jun 11, 2011.

Thread Status:
Not open for further replies.
  1. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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?
     
  2. adrenaline7

    adrenaline7 Registered Member

    Joined:
    Apr 27, 2011
    Posts:
    128
    why do you want to disable certain applications? why not just avoid installing stuff you don't want on your pc?
     
  3. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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. :mad:
     
  4. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Uh, yeah, of course.
     
  5. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,516
    Which part of Group Policy Editor are you talking about?
     
  6. hpmnick

    hpmnick Registered Member

    Joined:
    Mar 24, 2011
    Posts:
    186
    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.
     
  7. wat0114

    wat0114 Guest

    @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?
     
  8. x942

    x942 Guest

    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.)
     
  9. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    User Configuration -> Administrative Templates -> System -> Don't Run Specified Windows Applications
     
  10. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    I'm not even going to debate eventual holes that probably exist, and allow bypassing it. :p

    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". :isay:

    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.
     
  11. wat0114

    wat0114 Guest

    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.
     
  12. wat0114

    wat0114 Guest

    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.
     

    Attached Files:

    Last edited by a moderator: Jun 12, 2011
  13. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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. ;)
     
    Last edited: Jun 12, 2011
  14. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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.
     
  15. wat0114

    wat0114 Guest

    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 :)
     
  16. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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. :p

    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? :D
     
  17. wat0114

    wat0114 Guest

    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.
     
    Last edited by a moderator: Jun 12, 2011
  18. hpmnick

    hpmnick Registered Member

    Joined:
    Mar 24, 2011
    Posts:
    186
    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.
     
  19. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    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.
     
  20. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,516
    Indeed that is bad, I experience the same behaviour.

    You can also have false positives with this.
     
  21. ParadigmShift

    ParadigmShift Registered Member

    Joined:
    Aug 7, 2008
    Posts:
    203
    Don't bother with it. Just use SRP or AppLocker.
     
  22. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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. :)
     
  23. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
Loading...
Thread Status:
Not open for further replies.