Women in Technology

Hear us Roar



Article:
  Windows Server Hacks: Disable "Run As"
Subject:   Doesn't always work
Date:   2004-03-17 11:01:29
From:   nasseam
Software Restriction Policies path rules have good intentions but are a horrible means of file security. I once set path rules on a network to prevent certain chatting and file-sharing programs from running but the rules only worked for a few users. Why? Because path rules check for the exact path and filename so some users just copied the files somewhere else or renamed them.


This brings us to a good point in server lockdown: don't base any security policy on unawareness. These policies are easily recognizable and usually have the phrases "but most users" or "the majority of users won't" in them. These are true hacks in the sense that they don't solve the real problem but just workaround them.


A better means of disabling runas would be to set ACL permissions or to use a hash rule (also available using Software Restriction Policies). A hash rule solves the problem of copying or renaming because it is a hash of the actual bytes.

Full Threads Oldest First

Showing messages 1 through 4 of 4.

  • Mitch Tulloch photo Doesn't always work
    2004-03-17 11:58:22  Mitch Tulloch | O'Reilly Author [View]

    Good suggestion, a hash rule might be better here, thanks! Because of Windows File Protection you can't move runas.exe to another folder but you can still copy it and run the copied version of the command.

    I like the idea of modifying the ACL for runas.exe to remove the Read & Execute permissions for Authenticated Users. How would you deploy this change to a group of XP machines in a domain?
    • Doesn't always work
      2004-03-18 12:48:37  jmbwi [View]

      Use cacls.exe in a batch file that runs during login to change the permissions on each machine when a user logs in.
      • Doesn't always work
        2004-07-22 04:47:45  Mysidia [View]

        So what happens when the user brings in a disk with runas.exe from some other machine or downloads a copy of runas or other program that does what RunAs is doing (with different hash) from some other location?



        It doesn't seem like using software restrictions policies is going to get you very far unless you take a whitelisting or digital signing approach, and block everything else by default.



        You're really better off setting strong password policies about what passwords are set on accounts and when/where they are entered: secondary login isn't going to help a potential hacker much, they can get in with primary login just as easily, right..?


      • Mitch Tulloch photo Doesn't always work
        2004-03-18 13:21:12  Mitch Tulloch | O'Reilly Author [View]

        I think that may be the way to go. I tried changing the ACL on the Runas service under Computer Configuration\Windows Settings\Security Settings\System Services in Group Policy so that the Domain Users group has Deny Full Control permission, but this doesn't prevent an ordinary user from still using Runas...