Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Windows Microsoft Operating Systems Privacy Programming News Build Technology

Windows UAC Bypass Permits Code Execution (threatpost.com) 79

Posted by BeauHD from the inside-job dept.
msm1267 writes from a report via Threatpost: A Windows UAC bypass has been publicly disclosed that not only bypasses the security feature meant to prevent unauthorized installs, but can be used to run code on compromised machines without leaving a trace on the hard disk. The bypass relies on Event Viewer (eventvwr.exe), a native Windows feature used to view event logs locally or remotely. Researcher Matt Nelson said he figured out a way to use eventvwr to hijack a registry process, start Powershell and execute commands on Windows machines; he collaborated with fellow researcher Matt Graeber on a proof-of-concept exploit, which was tested against Windows 7 and 10. A report published today by Nelson said it would work against any version of the OS that implements UAC. An attacker would already need to be on the machine to use this technique, Nelson said. The attack allows an admin user to execute code in a high-integrity context without requiring the user to approve the administrative action via the UAC pop-up. Microsoft, the researcher said, does not consider UAC bypasses a security boundary worthy of a bulletin and patch. It's unclear how Microsoft will address this issue.
This discussion has been archived. No new comments can be posted.

Windows UAC Bypass Permits Code Execution More

Windows UAC Bypass Permits Code Execution

Comments Filter:

  • Well duh (Score:3)

    by fisted ( 2295862 ) on Tuesday August 16, 2016 @05:31PM (#52716065)

    Easier to just rely on the luser to click "Allow" when the UAC prompt pops up.

  • Am I reading this right? (Score:5, Informative)

    by tomhath ( 637240 ) on Tuesday August 16, 2016 @05:51PM (#52716187)

    An attacker would already need to be on the machine to use this technique, Nelson said. The attack allows an admin user to execute code in a high-integrity context without requiring the user to approve the administrative action

    So the attacker already pwns the machine. This is a threat?

    • Re: (Score:1)

      by Anonymous Coward

      STFU. We're trying to blow shit out of proportion here!

    • Elevation from limited-user access to "root" (Administrators-level access) is definitely a threat. Of course, in this case, it's just enabled by a really moronic default that Microsoft added to UAC in Win7 (and has persisted since), which auto-elevates some "trusted" Windows binaries (like eventvwr.exe). If you remove that particular stupidity (in the UAC control panel, move the slider all the way up to "Always Notify"), this attack (and the long, long list of similar things, many known for years, like it)

      • Elevation from limited-user access to "root" (Administrators-level access) is definitely a threat.

        This doesn't do that. You have to already be already running as an Administrator for this so-called exploit to work. If you are not in the Local Administrators group then you will get the prompt requiring a password.

      • Elevation from limited-user access to "root" (Administrators-level access) is definitely a threat.

        Of course it is, but if you actually read the article - or even the summary - you will see that that is not what is happening here:

        An attacker would already need to be on the machine to use this technique, Nelson said. The attack allows an admin user to execute code

        So without this technique the only difference would be that the attacker would have to click 'Allow' in the UAC prompt.

        • OK, 7-digit ID or not, are you really so new here you think that Slashdot summaries (or even articles) are an always-accurate representation of the world? Out here in the real world, where I've been working in information security longer than you've been on this site (and nearly as long as I have, actually), we understand the difference between "the attacker needs to physically or remotely accessing the machine" and "the attacker needs to have code executing on the machine". It's a very important difference

          • OK, 7-digit ID or not, are you really so new here you think that Slashdot summaries (or even articles) are an always-accurate representation of the world? Out here in the real world, where I've been working in information security longer than you've been on this site

            Yes ok your life revolves significantly around this site, I get that but not everybody's does.

            The fact that the summary implies direct access is required is stupid, but the fact that you (and, apparently, a significant number of other people) took that implication as fact says much more about you all than it does about the exploit.

            I don't think I said or implied "direct access". I quoted "on the machine" which could be remote, it could be by proxy.

            Try reading the actual exploit writeup [enigma0x3.net] rather than dumbed-down ThreatPost article, and you'll see that no such claim is made.

            So the claim I didn't make is also not made by Threatpost, well glad we cleared that up.

            Hell, even in the ThreatPost article, it doesn't say (or even imply) anything about physical access.

            Neither did I.

            You can do this exploit if you get non-elevated arbitrary code execution (via remote compromise, or Trojan download, or anything else of that sort) in the account of a member of the Administrators group. You cannot click "Allow" via non-elevated code execution

            If you have already achieved that you don't really need this exploit.

    • So the attacker already pwns the machine. This is a threat?

      Yes, apparently if you ask an attacker if they are sure they want to run malicious code then 99% of times they will click "no". So not presenting this dialog is a massive security problem...if you're a complete idiot.

  • Doesn't break what UAC is intended for. (Score:5, Insightful)

    by nuckfuts ( 690967 ) on Tuesday August 16, 2016 @05:53PM (#52716201)
    UAC isn't intended to be some kind of inviolable security mechanism. It's more of a simple alert that some process is trying to make changes to your system - a nice thing to know if you weren't expecting it. The fact that you can bypass the UAC prompt when already on the computer with administrative rights is pretty non-consequential.

  • Improving windows! (Score:3, Insightful)

    by jdavidb ( 449077 ) on Tuesday August 16, 2016 @05:53PM (#52716203) Homepage Journal

    The attack allows an admin user to execute code in a high-integrity context without requiring the user to approve the administrative action via the UAC pop-up.

    Thank goodness! I've been looking for a way around those annoying popups ever since they first arrived in Windows, and I know I'm not the only one.

  • UAC has a differnt goal (Score:3, Informative)

    by Anonymous Coward on Tuesday August 16, 2016 @05:57PM (#52716229)

    UAC has a different goal than you think.

    https://channel9.msdn.com/Forums/Coffeehouse/473037-UAC-controversy-the-last-episode/773c9d79f8df4fa8bc489deb00e05c3d

    Its goal is to force us to actually fix our crap. UAC is not a bandaid to fix all security issues. There are many known work arounds to it. Including turning it off.

  • All you folks still running Windows XP and being told it's a pile of insecure horseshit are vindicated!

    • Re: (Score:2)

      by dbIII ( 701233 )
      I've been saying that for ages. Some poor sods still have to run MS WinXP to get legacy software to work and their insecure environment (with Firefox instead of IE of course and Thunderbird instead of MS Outlook) is really not much worse than MS Win10 knee deep in the current malware swamp. The same third party antivirus software runs on both after all and the same real firewall upstream can protect them.
      Treat both like a pile of insecure horseshit and you'll be better off instead of trusting whatever the
  • If your current user isn't an Administrator, this doesn't provide the attacker any additional privileges.

    • It's actually even stupider than that. If you don't have UAC set to automatically elevate system binaries (like eventvwr.exe), this doesn't provide the attacker with anything either. UAC in Win7 introduced the idiotic notion that "trusted" programs would auto-elevate, rather than prompting, by default. There have been UAC bypasses based on this stupidity known for many years, this is just the latest in a long, long list.

      To avert this, on Win7+, set UAC to "Always notify", rather than the default "Notify me

  • Admin privileges?, Physical access?, big meh.

    • No physical access required. Arbitrary code execution in a non-elevated context required, and then it can use that to elevate... if you're a member of the Administrators group, and still have the brain-dead UAC default "don't notify when I make changes to Windows settings" setting selected.

      • No physical access required. Arbitrary code execution in a non-elevated context required, and then it can use that to elevate... if you're a member of the Administrators group, and still have the brain-dead UAC default "don't notify when I make changes to Windows settings" setting selected.

        An attacker would already need to be on the machine to use this technique

        That pretty much is physical access. Not to mention that we're talking about a improperly configured environment. Nevertheless, it is a vulnerability that must be addressed and Microsoft's response is unacceptable. P.S.: I'm pretty sure that UAC doesn't allow you to make changes without being notified by default.

  • Seems newsworthy.

  • No. I hope you do not. I don't run as admin on my Windows machines either. I run as Standard User so even if something bypasses UAC it can't do much because my account simply doesn't have those rights.

    • There's only one known UAC bypass if you switch to "Always Notify" from the brain-dead default setting that auto-elevates many Windows binaries , and there's a work-around for that one (the exploit itself is far more complicated than this one, too). Not arguing that running as not-a-member-of-Administrators isn't a good idea anyhow, because (from a security standpoint) it definitely is, but it's also a *mostly*-needless hassle.

      • If you develop in Windows, you often need to run as a member of Administrators in order to debug services. It's either that or elevating the MSVS at the start (and I am not even sure that would work in allowing you to attach to services). If you do elevate MSVS though, you'll be creating files as a different user, so then you won't be able to edit them as your non-administrators user. So there is quite a bit of incentive to do all development as a member of administrators and have UAC turned on (both for
    • The issue is not that you don't run things as a root user. The issue is that you can limit what processes you run as root on Linux by only using sudo and only having it set to allow a limited set of commands. In Windows, an admin user is not running in a privileged mode by default (so all processes only have regular user privileges). The admin user can elevate to the privileged mode (and needs to answer in the affirmative to that UAC prompt if the policy is set to require UAC). But with this workaround,
  • A security boundary not worth considering? For real? UAC and FS/registry virtualization are the only OS-level security paradigms added to Win 7 over Win XP. Without it, any background process running with administrative privileges can do what a logged-in administrator can do. This includes installing new software and doing essentially anything that a local TrustedInstaller user can do. Worse yet, if this ever happens when an admin user is logged in, the process would not even need to authenticate itsel

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close