back to article White hat pops Windows User Account Control with log viewer data

The User Account Control feature in Windows has been popped by researcher Matt Nelson, without even having to plant a .DLL on the target machine. In this post (warning, it's pretty dense going), Nelson finds that the Windows Event Viewer (a local/remote event log viewer) can be exploited to hijack registry processes; start …

  1. DryBones
    FAIL

    Stopped reading at

    "Nelson told ThreatPost the attack would need a victim's machine to be already compromised for the bypass to work."

    1. Hans 1 Silver badge
      Facepalm

      Re: Stopped reading at

      >"Nelson told ThreatPost the attack would need a victim's machine to be already compromised for the bypass to work."

      Should I add, compromised "with admin rights". Fail^2

    2. david 12 Bronze badge

      Re: Stopped reading at

      It's an elevation attack. That's what "elevation" means -- you already have access. Perhaps "compromised" was the wrong word.

      Interesting that this two-part attack relies on design features, not programming errors.

      1. Pascal Monett Silver badge

        Re: It's an elevation attack.

        Yeah, I get it. But still, if the machine is compromised, then it doesn't really matter what happens after, the result is still your data is screwed, and maybe your bank account as well.

        I worry about keeping my machine uncompromised. Once it becomes compromised, the details are unimportant to me. That machine is toast, period.

        1. Ragarath

          Re: It's an elevation attack.

          Think of this more in this scenario.

          Your employees have certain access to the system. One of them has had something happen they did not like and decide they want revenge. They use this process escalation attack to give them access they should not have.

          (I've not had time to read the actual process yet but I assume this is what is meant. By compromised they mean access is available.)

        2. Chris Harden

          Re: It's an elevation attack.

          Then please don't ever get a job as a Sys Admin.

          Defense in depth is key to security, UAC prevents people running bad software that compromise the machine because the easiest, simplest way to hack a computer nowadays is to get a user to run your evil code. If that user is running your evil code as an admin UAC goes a little way to protecting your machine outside of your user profile.

          Easy example:

          A low-level user who demands to run as a local admin (because, users) runs something, it pops their UAC and infects the machine.

          User then calls front line support guy, who has networking privileges but nothing scary, he cant see anything so calls the 'big sysadmin' down to fix the problem. He logs on to the machine, you just lost your network.

          1. Dan Wilkie

            Re: It's an elevation attack.

            Except that if you're already a local admin, which is required for this exploit, then you can just disable UAC...

            Or use your admin credentials to accept the UAC prompt. Which you'd have to do to launch the registry editor in the first place...

      2. Hans 1 Silver badge
        Boffin

        Re: Stopped reading at

        >It's an elevation attack.

        NO, it is not ... you need local admin rights to pull this one off, to get elevated process without UAC ... This circumvents UAC, that is it ... why anybody would be interested in circumventing UAC while having local admin access is beyond me ... but hey ...

        I do not care about down-votes, maybe, just maybe, I was misunderstood up there ... I was pointing out that you need local admin rights, as written at the bottom of the blog post this article is linking to ... yes, I did read and understand the whole thing, it is not as technical as one would think, or the article warns ... he is just using a registry key, abusing the fact that you have user and system hives, that user hives are tried first.

        I did reproduce it on my windows 10 box, it is easy to pull off: create registry key, open event viewer ... with a non-privileged account, the process runs as the actual user, is NOT elevated, exactly as I had expected. It is weird to see a black powershell window (ala CMD.exe), I expected it to be blue. Also, seeing a shell with Event Viewer on the title bar looks weird, yet, as I would expect.

      3. FlamingDeath Bronze badge

        Re: Stopped reading at

        It's Microsoft, these kind of bugs / features are hard baked into the product from the word go

  2. amacater

    Windows 10 with WSL enabled - use Linux binaries - which aren't sandboxed and have access to the lowest level of kernel / hardware because of he translating layer - to do this sort of thing?

    [There's absolutely no problem with the Ubuntu binaries, BTW, it's the fact that they run on a translating layer that has no obvious protection/hypervisor/sandboxing Windows - insecure by design since NT 4.0 or so]

    1. Anonymous Coward
      Anonymous Coward

      Windows - insecure by design since NT 4.0 or so

      Lol, no, the problems go back quite a bit further. Windows 1.0, I'd say, when it was still a GUI on top of DOS. To paraphrase John Lewis, Windows has never knowingly been secure..

      1. Anonymous Coward
        Anonymous Coward

        Judging by the downvotes appearing everywhere, the Microsoft marketing department is back from holiday. Let's see if they can keep up..

  3. Dick Knuckle

    This seems

    Similar to the old SYSTEM account flaw. Where you could spawn a shell with SYSTEM privileges. Albeit without getting SYSTEM privileges.

    I used to use that a lot to fix stuck services.

  4. Aodhhan Bronze badge

    Can you all quit spewing out the obvious?

    We get it... to those who don't work in the seemingly unexcited world of computer science, this seems like a pretty idiotic thing... bypassing UAC while already having the keys to the kingdom.

    To computer engineers and scientists, this represents a very large hole in the processes of the operating system, and also displays being able to do a few things out of the ordinary while bypassing UAC. In simpler terms, while digging in the sand a buried chest was found. Now someone needs to be able to work a little harder to get it out and see what is inside.

  5. FlamingDeath Bronze badge

    Already compromised...

    I'm failing to see the significance of this, sure it's interesting and academic, but what purpose does it serve?

    You're on a system already authenticated as an administrator, you can pretty much do whatever you want to the computer. So what if you can bypass some shonky UAC "protection" (lol) that is effectively a window that asks if you're sure, AGAIN!

    I just don't get it, this article seems to be a waste of time

  6. Christian Berger Silver badge

    Wait? Windows merges registry branches?

    I mean that whole problem seems to exist only because Microsoft decided to merge one registry branch with another one the unprivileged user can change.Why would you do such a thing? I mean the idea of a registry is bad enough already, but somebody must have noticed that merging branches is a logic nightmare at best, and likely a security problem at worst

    1. david 12 Bronze badge

      Re: Wait? Windows merges registry branches?

      >Why would you do such a thing?

      This is the Win3.x compatibility layer. Win3.x / MSDOS was fundamentally a single user / single process unsecured system. So this layer represents the user context and the machine context as a single shared context. It's a perfectly safe representation as long as only user-level applications (like Win3.x compatiblity applications, or random internet viruses) use it. That part of it is not a problem.

      Except --- MS cheated on that and included a legacy system-level process that used the Win3.x compatibility layer. And not just once: it's a systematic problem. The second half of the exploit relies on more of the same kind of cheating, where the pre-UAC legacy process is allowed to ignore UAC because it's an authenticated/signed MS OS component that MS didn't see a problem with.

      It's not the merged registry which was the bad idea. You use both the machine and any personal documents and the internet: you don't stop and login seperately for the machine, and the documents and the internet. The error would be letting the internet impersonate the machine because "it won't matter, just this once, because we know what we are doing"

  7. PeteA
    Windows

    Analogous to suid

    Not identical, as suid actually changes the euid, but conceptually similar - the OS has been "told" to always launch a particular binary in an elevated context, and someone's found a way to exploit the binary. Not as bad as setting vim to suid, but the same basic idea. Interesting to see Microsoft re-using design flaws from Unix (and for those who'd like to play the "secure by design" card, whilst I'd generally agree it doesn't apply in this particular case).

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019