Windows 7 standard user vs admin

Discussion in 'other security issues & news' started by vincenzo, Feb 9, 2011.

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

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
  2. vincenzo

    vincenzo Registered Member

    Joined:
    Nov 28, 2005
    Posts:
    151
    Thanks, those were interesting reads.

    But it seems that a large number of the advantages cited would be in reference to a standard user account that is never elevated, such as in a corporate environment where the does not have the password.

    What I've been trying to assess is the added benefits of a standard account in an environment where the user is also the administrator, yet is careful to only allow the elevations when they seem to be necessary for a task that is being carried out. And the points you've made and links you've supplied do address that, and the answer seems to be that the benefit does exist, but it is somewhat marginal. And that a standard user account is not a panacea, it is still susceptible to malware, especially when Over The Shoulder elevations are allowed.

    But it is enough of a benefit that I will continue running our computers here a standard user, despite the occasional annoyances.
     
    Last edited: Feb 12, 2011
  3. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    If you haven't disabled UAC, User Interface Privilege Isolation provides protection in either a protected admin account or a standard account that doesn't exist in Windows XP, but it's not a security boundary, as Joanna Rutkowska noted:
    I don't know what percentage of malware takes advantage of the issues noted by Mark Russinovich in order to elevate itself, in either a protected admin account or a standard account. I don't recall seeing any threads at Wilders referencing that aspect.
     
  4. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    OK,there are 2 parts to this post:

    1. A question that has been lurking on my mind
    2. My POV on the matter that MrBrian brought up in regards to SuRun....

    1. My Question:

    In Windows 7, the default account with UAC in AAM behavior is to "Prompt for consent for non-Windows binaries". Although it's in an admin account (as seen in the User Accounts option in Control Panel), it logs on with both standard user and admin access tokens. The admin can set the behavior to "Prompt for credentials on the secure desktop" instead either through Local Security Policy or the registry. When this is done, anything that needs elevation would invoke UAC prompt with credentials (including Windows binaries). This is pretty much similar to how a separate SUA account works (unless one changes the behavior to let's say"Automatically deny elevation requests")

    Assuming one changes the behavior of the former (default account), is there any other difference from running a separate SUA account with no changes made? IOTW, is there any other security aspects or issues that I miss or need to be aware of? Assuming there do exist, would it have much of an impact if I'm using a default-deny SRP/Applocker?

    The main reason for asking this is if there's not much of a security gain, I would choose to use the default account (with credentials) in order to minimize user profile/path/context differences when I'm running or installing programs.

    2. My POV on the matter that MrBrian brought up in regards to SuRun

    I do think the "malware running in a standard account can write to locations that an elevated process can later read from" issue exist with SuRun but to be fair, it exist with the UAC in AAM too as stated.

    1 added possible 'danger' that SuRun brings into the picture and that comes to my mind is one where malware has targeted a program that has been configured to 'automatically' elevate by SuRun. But then again, a malware author would be more likely to target the Windows binaries that are elevated in the default UAC settings in Windows 7, isn't it?

    In order to reduce the likelihood of this issue, one may choose to run as standard users who can't elevate programs in the SUA account (set ConsentPromptBehaviorUser in Local Security Policy or registry to "Automatically deny elevation requests"so that SUA in Vista/7 behaves similar to how it does in XP without SuRun). However, this reduces convenience for many I believe...

    And let's assume that one is running as a standard user without SuRun on Vista/7. I don't think there is much to stop the loading of the executable written in step a) .....IF the user knows the credentials. The key differences are:

    i) it requires a manual input of credentials when prompted by UAC (unless one uses elevated program launcher method)
    ii) the program would be running under the Admin account context .

    Regardless of which account it uses (SUA or Admin), and regardless of the elevation method used, an elevated program would still most likely be able to load executable written in step a), isn't it? The malware might fail if it works like the example stated by Mark Russinovich but what about the one stated by Joanna Rutkowska? I'm thinking that determined malware authors are able to find more ways that 1 to circumvent these...

    I am of the opinion that the best thing in this case is to use to prevent or lessen the chances of step a) from occurring in the 1st place. Maybe through the use of SRP/Applocker or 3rd-party execution-control programs. Not to mention, one might be better off being picky/fussy when choosing which programs are allowed to be 'auto' elevated, be it with SuRun or elevated program launcher or any other methods.

    We all know that there's always a trade-off between security and convenience. SuRun is a tool of convenience that includes a white-list manager. This is something that UAC lacks (which is both a good and bad thing...depending on how you view it)

    FAQ: Why can’t I bypass the UAC prompt?

    If a whitelist makes sense then it must be user-configurable

     
  5. wat0114

    wat0114 Guest

    I don't understand why the use of SuRun to auto-elevate selected known, legitimate and safe programs or Windows tasks such as Windows firewall, Event viewer or security policy, to name a few, is even called into question as a security risk. If I'm going to use it to elevate malware, then it means I've already chosen to deliberately install said malware in the first place, so SuRun-elevating it doesn't increase the damage that's already going to have been done when it was already installed. IOW, what difference does SuRun make in the picture here when the user has already induced damage upon the machine by deliberately downloading the malware (of course not yet knowing it's malware), then deliberately installed it with the intent on running it as a program to be trusted?

    In my setup, it is only my user account that belongs in the Surunner's group, along with, of course, the administrator (me as well), so I use it to elevate such functions as Windows firewall w/advanced security, event viewer, computer management, local security policy and a few other already installed, completely verified clean and trusted and AppLocker-accounted-for programs such as Snagit (for taking scrolling screenshots because it does it poorly launched as user) and MBAM when I need updates. It is simply for the convenience of running these Windows functions or programs from my user account because I do this so often that without Surun I would either be consrtantly logging in and out between my user and admin accounts or running full time as admin. This way I get the best of both worlds - running programs such as my browser and email, MS Office and so forth with user privileges, while other admin stuff already mentioned using Surun without the need to provide the password, only consent, to save myself tons of time.
     
  6. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    @safeguy
    Regarding your first question, I believe your security is the same when the admin is prompted for credentials as when UAC is set to its highest setting with prompting by consent, with the exception that malware could grab credentials. Prompting for credentials could be a good idea for those who might otherwise mindlessly give consent without much thought, and also in situations where other people may use your account when you've stepped away from the computer. The issues that Russinovich mentioned are still present. If you're using a good anti-executable solution then I think that using just a UAC-protected admin account might be considered reasonable, either with prompting by consent or for credentials.

    When elevating from a standard account using UAC (or with the elevated program launcher method), the Russinovich scenario would fail because the executable written in step a) wouldn't be read by the elevated program because the elevated program is using a different account. The Rutkowska scenario with the elevated command prompt would succeed in either a standard account or admin account, I believe.

    A potential problem with using a protected admin account is how does one audit permissions? The permission auditing programs that I've tried assume the full token is being used, not the filtered token.

    @wat0114
    Let's use a more detailed example.
    a) In a standard account, you open a malicious pdf and it launches malware that writes a shell extension executable for the standard user. The malware has no admin permissions yet.
    b) User elevates a backup program with SuRun because the backup program needs it.
    c) When using SuRun-elevated backup program, user encounters a File Open dialog box, which loads the shell extension written in step a), but now with admin permissions.
     
  7. wat0114

    wat0114 Guest

    Well, okay, good point and no arguments here, but then I'd have to open the malicious pdf in the first place just to get the ball rolling for this scenario. It comes down to the balance between security and convenience, and I believe I've got as close to perfect for my needs and abilities as I'll ever get. The best security approach is the one that is most suitable at providing the requisite protection while maintaining reasonably efficient usability for the individual(s) it's meant for. Mine is without real time system-dragging fluff like antivirus (MBAM is free on-demand) - so many of these products are a virus unto themselves - annoying HIPS, or any other system-hooking 3rd party products. Only the very lightweight SuRun is introduced into the system used strictly for convenience. Until and unless I see otherwise in my own experience, I do not need to worry about unlikely "what if" scenarios. Even if I manage to let my guard down just enough to incur infection, I can easily fall back upon a very recent image and be done with it.

    FWIW, I am still intrigued by the possibility of substituting SuRun for Powerbroker, because I like the granularity of integrity levels and other mitigating factors it could provide for selected apps, but I need to see it work in Win7 before I will consider it. It caused really strange problems for me last night when testing in the vm, including a BSOD when I applied one of the settings. That all said, I really lke the way SuRun works; Simple. Predictably. Conveniently.

    BTW, I'm not disregarding your security-related feedback; in fact, I appreciate your expert feedback and help in this forum :) It's just that I feel the need to temper, for my own purposes and partly in an effort to persuade others to step back and refocus, some of the cautionary postings because getting too carried away with attempting to plug every possible security hole, no matter how trivial some of them might be, is going to be an exercise in futility. The scenario you just presented is for me, trivial, because, although it can't be completely ruled out, I really don't see it happening very easily to me at all.

    Too often the individual using the computer is overlooked as a key component of a security setup :) so too much emphasis gets placed on applications and other built-in vehicles to provide the "hand holding" battery of protection for us, when in reality it's probably, or at least should be, only a small fraction of the total effort. Your emphasis on "Least privilege" is excellent, but I'm not sure if taking it to such an extreme extent will work for many of us. Sorry for the long-winded post ;)
     
  8. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    @wat0114
    You use AppLocker anyway, so you likely wouldn't have been affected in my last scenario.

    I'm not trying to make people paranoid. Rather, I was just trying to address vincenzo's question. If I were using a good anti-executable solution, I wouldn't lose sleep over the prospect of using just a protected admin account (or SuRun either), other than the fact that I don't know how to audit the permissions in a protected admin account (but most even here probably don't audit permissions anyway).
     
  9. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Please, don't see this as a way of saying you're wrong, because you're 100% right, in your vision.

    What I learn from what you write there is that, unless something bad happens, you won't change the security-convenience method you have in place. And, in the possibility of such happening, you'll restore a clean image and you're done with it.

    I totally get it, but how will you know you're infected? How will you know something misbehaved? You mentioned Malwarebytes Anti-Malware free version for on-demand scans. OK, fair enough. But, the chances of catching malicious code on the act will be 0%. And, if Malwarebytes Anti-Malware detects something, when was it introduced in the system?

    This is where the line gets drawn. For some, just like yourself, it's acceptable for such to happen and then just go back in time and restore a clean image. For others, the slightest chance of an infection is totally unacceptable, so they analyze every single possibility and rule them out.

    Anyway, it's already 3 AM and I'm sleepy, so I may have not written all as I wanted. lol
     
  10. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    Enough of theory. Here's a concrete example:
    From http://arstechnica.com/phpbb/viewtopic.php?f=2&t=9910&start=40:
    Try this in a protected admin account, and then try it in a standard account. The payload (regedit in this case) runs elevated only in the protected admin account.

    The point is that if malware runs in a protected admin account, it's not hard for it to get admin rights without any suspicious UAC prompts.
     
    Last edited: Feb 12, 2011
  11. wat0114

    wat0114 Guest

    Of course, but then there are those new and somewhat obscure applocker-defeating malware these days :D

    For sure, and you present valuable information and concerns many of us, myself included, are not even aware of, so it gives us something to think about, especially when you offer "least privileged" "already-built-in" ways of addressing them.

    Odd and unexpected behavior. If in doubt, wipe and restore :)

    It's only used sometimes for downloads from untrusted (rare in my case) sources.

    Unfortunately for some, cleaning up the malware-induced mess after the fact gets far more attention than the more efficient method of "wipe and restore". Better yet, prevent the malware in the first place.
     
  12. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    Great quote from the same person in the thread mentioned in my last post:
     
  13. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    I knew I forgot to mention something. :D

    My post didn't mention whether or not people should use the image backup approach. Obviously, they should; but, not to prevent infections. The way I see it, image backup strategy should exist to safeguard the system against data corruption provoked by malfunction software upgrades, for example. If, at some point, this very same strategy can be used to clean an infection, so be it, it's a plus.

    But, my point was that some people rather deploy preventive mechanisms, rather than just cure mechanisms.
     
  14. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    That's nothing new. It was already known that UAC is no security tool. This is something that I've actually mentioned a few times already. People should not use an administrative account and expect UAC to protect them; it simply is unrealistic.

    And, even recently a security vulnerability was found, allowing privilege escalation from a standard user account. All the user had to do was to open some crafted file in user-space. It has been patched by Microsoft this last week. But, who knows what else in lurking, right?
     
    Last edited: Feb 13, 2011
  15. tlu

    tlu Guest

    Hm, I might be naive but I'm not getting it (possibly due to the fact that I moved to LInux a long time ago ;) ). Why would in step c) the user in a File Open Box open the malicious shell extension of all the thousands of other files on his computer? Isn't this example a bit contrived? Besides, the same would happen if you execute the program in step b) with runas rather than with SuRun. That's why I don't consider this a weakness of SuRun.
     
  16. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    I tested this scenario:
    except that I assumed the malicious program is running non-elevated with medium integrity level.

    Four tests were done:
    1. Windows 7 x64 with protected admin account; result: elevated command prompt did not receive keystrokes
    2. Windows 7 x64 with standard user account; result: elevated command prompt did not receive keystrokes
    3. Vista SP2 x86 with protected admin account; result: elevated command prompt received keystrokes
    4. Vista SP2 x86 with standard user account; result: elevated command prompt received keystrokes

    I used AutoHotkey non-elevated to try to send keystrokes to the elevated command prompt, using this AutoHotkey script:
    Var_WinHwnd=0x30174 ; replace this number with desired window handle
    PostMessage, 0x100, 0x52,,, ahk_ID %Var_WinHwnd%
    PostMessage, 0x102, 0x53,,, ahk_ID %Var_WinHwnd%


    I used Winspector to get the window handle to use in the AutoHotkey script.

    It would be nice if somebody could test Windows 7 x86 and Vista x64.
     
    Last edited: Feb 13, 2011
  17. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    I didn't test this scenario, but Mark Russinovich mentioned it. You can substitute the "reg add..." example from a prior post if you wish. If an elevated program runs in a different account (whether it's by Runas or UAC elevation), it should not read the file created in step a because it's in a different account. SuRun, on the other hand, runs the elevated program in the same account.
     
  18. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    I tested the "reg add" scenario with SuRun in a standard account. As I expected, the payload (regedit in this case, but could have been malware) runs elevated when SuRun is used to launch the command prompt elevated, but the payload doesn't run at all when elevating the command prompt via UAC.
     
  19. wat0114

    wat0114 Guest

    Thank you for testing this and sharing your results MrBrian. It looks as though with SuRun, there is a tradeoff losing some security for the gain of convenience, although the elevated shell extension looks to have not worked under Win x64? Was this the same results in your last test with the Reg add? The common denominator I see in this scenario, however, whether one uses UAC or SuRun, is that a malicious file is opened in the first place. It seems the end user has already created a problem for themselves, although it gets compounded when using SuRun to elevate a program.
     
  20. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    You're welcome :).

    I didn't test the Russinovich elevated shell extension scenario.

    I tested the Rutkowska elevated command prompt scenario; Windows 7 x64 seems to be safe under this scenario, but Vista x86 isn't.

    Remember that malware can be run unintentionally. If that weren't true, then there would be no need for EMET.

    PowerBroker Desktops has features that may make it better suited than SuRun from a security perspective. I haven't looked at either enough yet though to comment more. I'm going to check the English SuRun forums to see if this has been discussed before; I don't know German though.

    The bottom line is that if you elevate a program with SuRun that can be used to run arbitrary code, malware can take advantage of it to run elevated. The same is true with a protected admin account. UAC elevation doesn't have these problems, because the UAC-elevated program runs in a different account. Remember though that malware could snatch credentials entered in fake a UAC prompt, or read them from real a UAC prompt if the secure desktop is not used.
     
  21. wat0114

    wat0114 Guest

    I'm using EMET configured (hopefully properly :) ) on all machines in the household. My main security tools on those other machines (one is Win7x64 Home Premium and two are XP Pro) are combinations of lua, SRP and Sandboxie, depending on the machine. So far no problems.

    I agree with your assessment of Powerbroker, and I'd sure like to see it work properly, but it doesn't seem to in either Win7x64 or XPx86 VM's :( About German, me neither, and the English translation seems a bit muddled.

    You uncovered a weakness in SuRun to be sure. You have some very impressive expertise. SuRun would be perfect if it could do what it does without elevating arbitrary code without malware potentially taking advantage of it with admin privileges.
     
  22. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
  23. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    I tested this UAC attack scenaro on Windows 7; Windows 7 remains vulnerable in this scenario.

    Recommendations:
    1. Don't elevate (whether by UAC, SuRun, or any other solution) shortcuts in accounts that malware may have affected.
    2. The particular program launcher that I use with the elevated program launcher method doesn't launch programs via shortcuts, so it's immune to this issue.
     
    Last edited: Feb 15, 2011
  24. wat0114

    wat0114 Guest

    You have definitely found a weakness in SuRun and now UAC, but isn't it basically already "game over" at this point with "accounts that may be running malware"? The point I'm trying to make is that even though said malware may not get elevated by not using SuRun or UAC, it's already running and more than likely wreaking havoc within user space, so it's already time to resolve the issue either by cleansing or restoring an image. That said, I'm not trying to minimize the impact of your discovery - it's certainly significant in nature - except I would conclude the mistake of already allowing malware to get its foothold in the user space has already been made, the point of "no return" so to speak :) I really don't want to stop using the convenience of UAC or especially SuRun simply because of "just in case malware is present and active" in my user account. I've enough confidence in my abilities to prevent it in the first place.
     
  25. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    I share your opinion. Once malware gets its way to the system, even if only at user-space level, damage has been done already, and most likely the purpose of the attacker achieved - steal bank account credentials, for example.

    As I mentioned before, if they can't get full privilege access, they'll be happy with just accessing limited accounts. Either way, in case of stealing bank account credentials, they can do it for user-space, and even without touching the hard disk, only memory.
     
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.