Stopped reading at
"Nelson told ThreatPost the attack would need a victim's machine to be already compromised for the bypass to work."
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 …
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.
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.)
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.
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.
>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.
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]
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.
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
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
>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"
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).
Biting the hand that feeds IT © 1998–2019