SuRun elevations can allow malware to elevate in a standard account

Discussion in 'other security issues & news' started by MrBrian, Feb 14, 2011.

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

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    Upon reading about the weaknesses of UAC-protected admin accounts (see https://www.wilderssecurity.com/showpost.php?p=1825648&postcount=10), it dawned on me that SuRun in a standard account might have the same weaknesses, since SuRun-elevated processes run in the same standard account.

    Consider this hypothesis (adapted from Mark Russinovich's quote):
    SuRun-elevated processes are susceptible to compromise because they run in the same user account as the standard user's standard-rights processes and share the user’s profile. Many applications read settings and load extensions registered in a user’s profile, offering opportunities for malware to elevate. For example, the common control dialogs load Shell extensions configured in a user’s registry key (under HKEY_CURRENT_USER), so malware can add itself as an extension to load into any SuRun-elevated process that uses those dialogs.

    To test this hypothesis, I tried the following (adapted from https://www.wilderssecurity.com/showpost.php?p=1827210&postcount=35):
    In a standard account that you're using for SuRun, start a non-elevated command prompt and enter:

    reg add "HKCU\Software\Microsoft\Command Processor" /v AutoRun /d "regedit" /f

    This creates a registry entry. Then launch a SuRun-elevated command prompt. Notice that regedit also starts elevated. You can confirm that regedit is running elevated by creating a new key under HKEY_LOCAL_MACHINE\Hardware, which can't be done using regedit non-elevated.

    Reflect upon what just happened. Instead of regedit, this could have been a rootkit installer. Malware was able to elevate when you SuRun-elevated the command prompt.

    Then please read https://www.wilderssecurity.com/showpost.php?p=1827214&postcount=37. Although that quote references UAC, the same seems to be true of SuRun in a standard account.

    I believe that the above hypothesis is accurate.

    Related reading: Windows 7 standard user vs admin.

    Edit: changed "HKEY_LOCAL_MACHINE" to "HKEY_LOCAL_MACHINE\Hardware".
     
    Last edited: Feb 14, 2011
  2. redgrum

    redgrum Registered Member

    Joined:
    Nov 16, 2010
    Posts:
    50
    Would this type of attack be mitigated by simply denying User accounts write access to their usual autostart locations, or just restricting cmd/regedit etc with SRP or similar techniques?
     
  3. ParadigmShift

    ParadigmShift Registered Member

    Joined:
    Aug 7, 2008
    Posts:
    241
    That's why it's important to create and enable various policies beforehand. Standard accounts alone are not enough.
     
  4. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    Using anti-execution technology (SRP, EMET, etc.) is helpful in stopping unintended code execution.

    Software that denies (or at least warns about) user-specific autostart locations could be useful because an autostart might be stopped before the elevation occurs.

    Another suggestion is to avoid SuRun-elevating any executable that ships with the operating system, on the theory that malware would be more likely to target these.

    You may also consider using alternatives to SuRun that elevate processes to a different account than your standard account, because these types of attacks are less likely then. Solutions include UAC elevation and elevated program launcher.

    PowerBroker Desktops Free Edition is an alternate to SuRun that, like SuRun, elevates within the same account, but has security-related features that may reduce the likelihood of malware elevation.
     
  5. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    Two comments. First, I seem to recall examining something of this nature, and I believe if you use RunAs it is different results vs. SuRun?

    Second, is there a difference if you set the option that Admin group is owner of new files rather than user? That too I believe changes things, but it has been some time since I was digging into this sort of thing.

    Sul.
     
  6. redgrum

    redgrum Registered Member

    Joined:
    Nov 16, 2010
    Posts:
    50

    I was thinking more of using NTFS Permissions, so the standard user cannot write to that location, but A SuRun elevated request can? I can't be having any software adding autostart entries without my express consent anyways!

    Is there any obvious weakness in this method that I'm not seeing?
     
  7. kbruns

    kbruns Developer

    Joined:
    Feb 15, 2011
    Posts:
    5
    Hi,

    I'm the author of SuRun. (TLU pointed me to this thread)

    I just fixed SuRun (1.2.1.0b2) so that %windir%\system32\cmd.exe is always started with a "/D" on the command line. This (hopefully) disables cmd's AutoRun nonsense. I really can't believe that MS kept this in Windows Vista and 7. At least I would expect that the HKCU AutoRun would not be executed from an elevated process... anyway this effects Windows XP too, so I should have closed this hole way earlier.

    For all users that use SuRun's release versions:
    I think the best way to keep malware from using this security hole is to disable write access to all known AutoRun locations (KAfU), nearly as redgrum proposed, but not using NTFS permissions, using the registry key ACL's instead.
    Using SuRun's "/RunAs" feature would also work in XP and on non UAC systems, but in Windows Vista/7 with UAC activated, "SuRun /RunAs" will result in starting any program non elevated. I've got plans (but no time) for a "run elevated" checkbox for UAC admins in the RunAs dialog.

    Cheers,

    Kay
     
  8. redgrum

    redgrum Registered Member

    Joined:
    Nov 16, 2010
    Posts:
    50
    Fantastic, an author response - Cheers kbruns, an excellent tool and a very speedy fix!

    Does this KAfU (program/script/list?) stop every User autostart location from being written to, or just the most common ones?
     
  9. wat0114

    wat0114 Guest

    Ageed! Nothing else I've ever tried seems to work at elevating either manually or auto"magically" as effectively as SuRun does. It's a terrific little utility :)

    Thank you for your post Kay, and also thank you to tlu for drawing your attention to it.
     
  10. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    RunAs elevates to a different account, so RunAs is free from this class of issues. Malware could possibly steal credentials from RunAs though.

    Regarding your second question, I didn't test that, but I believe it wouldn't make a difference.

    @kbruns
    Thank you for the fix :).
     
  11. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
  12. kbruns

    kbruns Developer

    Joined:
    Feb 15, 2011
    Posts:
    5
    Thanks for the hugs :)

    Regarding KAfU:
    TLU posted about that here
    The Tool is in German. It sets the ACL for some (but not all) AutoRun locations so that the limited account can't write to them.
    Unfortunately KAfU does not set the ACL for "HKCU\Software\Microsoft\Command Processor", so you'd have to do that manually. (RegEdit, SubInACL, ...)

    Regarding the "privilege escalation vulnerability":
    BeyondTrust just write that there is a vulnerability, but they do not tell it. So I can't say if SuRun is affected.
     
  13. tlu

    tlu Guest

    Thanks a lot, Kay, for joining Wilders, participating in this thread and provding the fix for your excellent SuRun :thumb:
    The steps how to do this are mentioned here.
     
  14. Stephen2

    Stephen2 Registered Member

    Joined:
    Feb 11, 2007
    Posts:
    12
    Some help from the registry experts:

    I can't remove inherited permissions from this registry key:
    HKCU\Software\Microsoft\Command Processor

    Hence, I can't remove "EDIT" permission for my account.

    I have tried using an elevated RegEdit, and also while logged on as ADMIN, neither works.

    Any ideas?
     
  15. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    @Stephen2

    Use the "advanced" tab to modify those. You cannot do it from the first screen because it was inherited. Be sure to make the owner admin, not the user.

    Sul.
     
  16. ParadigmShift

    ParadigmShift Registered Member

    Joined:
    Aug 7, 2008
    Posts:
    241
    Beautifully said.

    And thank you Kay for your wonderful tool, SuRun.
     
  17. tlu

    tlu Guest

    Just saw that Kay has a new 1.2.1.0 beta 3.

    Changelog:
    This would replace UAC!
     
  18. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    @kbruns

    Do you have any plans on including an "automagic" option for elevating processes/apps to the default Admin account (not the standard user account)? I'm looking forward to such a feature if possible...

    Anyway, you might want to look at these:
    More info here: Quickpost: “It Does No Harm…” or Does It?

    Source

    I'm guessing that this may help:

    setdllcharacteristics
     
  19. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    From Do you want competitors telling the world what’s wrong with your product?:
     
  20. kbruns

    kbruns Developer

    Joined:
    Feb 15, 2011
    Posts:
    5
    I'm planning such a feature since late 2008 but I did not find the Time to implement this. (Because SuRun is no commercial product but a spare time project of mine I can only work on it as my time allows.)

    SuRun's dialog on the safe desktop that asks to grant or to deny your permission to start a program with elevated rights will include an option to chose a different user (and eventually elevate this user if it is an UAC Admin or a non restricted SuRunner).
    SuRunExt(32).dll doesn't include any security relevant component or function. So using ASLR would not gain any security.
    [EDIT:] After reading. Not using ASLR makes SuRunExt.dll a possible target for hijacking Explorer. I'll turn ASLR on.[/EDIT]

    SuRun.exe is both, the client and service.
    To get elevated rights, SuRun.exe writes a fixed size data structure (g_RunData) to a pipe that the service owns. The service reads the structure, verifies that it comes from the same executable file as the service, and eventually launches a third SuRun.exe with local service rights inside the user's WindowStation, that creates/uses the safe Desktop to interact with the user.
    IMHO the only chance to exploit SuRun is to use g_RunData to generate a buffer overflow inside the service. So DEP could be useful for SuRun.exe if g_RunData could be used to generate a buffer overflow. I'll check if I can enable DEP by default in the Service.

    If someone wants to help improving SuRun: SuRun is hosted at SourceForge (surun.sf.net).
     
    Last edited: Feb 20, 2011
  21. kbruns

    kbruns Developer

    Joined:
    Feb 15, 2011
    Posts:
    5
  22. tlu

    tlu Guest

    Thanks a lot, Kay :thumb:
     
  23. wat0114

    wat0114 Guest

    Kay you are awesome :thumb: Thank you!
     
  24. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    I can understand that and I truly admire that you put in effort to release a program like this for free...without asking for anything in return. Anyway, I am still hoping that you can re-consider and add this feature in future builds (if you have the time) since I am desperately seeking for it and not to mention that it would prevent the problem mentioned on the 1st post and discussed on this thread itself.

    I was just wondering if adding explorer.exe into SuRun black-list would prevent this if one uses an older build without ASLR (or maybe those who use XP), especially if he/she only uses SuRun to elevate certain programs and has no need to elevate Explorer itself.

    Great!
     
  25. kbruns

    kbruns Developer

    Joined:
    Feb 15, 2011
    Posts:
    5
    I'll do for sure.
    This is one big feature that I'd like to add to SuRun for myself ;-)

    Adding Explorer.exe to SuRun's blacklist would not help.
    SuRun's Blacklist is just a policy for SuRun to keep off special processes.

    SuRunExt.dll is injected into most processes, no matter what's in the blacklist. Windows itself injects SuRun's "(Re-)Start as Administrator" Shell extension into every GUI Process. If SuRunExt is injected into a process that is part of the blacklist, SuRunExt will not modify any memory to set it's hooks but all code is there, sleeping inside the process and could be abused.

    So if Malware would exploit SuRunExt.dll with ROP and ASLR disabled, this would effect all GUI Processes, no matter what's in SuRun's blacklist.

    If Malware uses ROP. It needs a fixed address that it can return to. That's why ASLR needs to be ON for all DLLs that implement hooks.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.