Windows 10 UAC Bypass Uses Backup and Restore Utility (bleepingcomputer.com)

An anonymous reader writes: "A new User Access Control (UAC) bypass technique relies on altering Windows registry app paths and using the Backup and Restore utility to load malicious code without any security warning," reports BleepingComputer. The technique works when an attacker launches the Backup and Restore utility, which loads its control panel settings page. Because the utility doesn't known where this settings page is located, it queries the Windows Registry. The problem is that low-privileged users can modify Windows Registry values and point to malware. Because the Backup and Restore utility is a trusted application, UAC prompts are suppressed. This technique only works in Windows 10 (not earlier OS versions) and was tested with Windows 10 build 15031. A proof-of-concept script is available on GitHub. The same researcher had previously found two other UAC bypass techniques, one that abuses the Windows Event Viewer, and one that relies on the Windows 10 Disk Cleanup utility

Comments

Auto Elevation

[ssufficool]

Problem 1: Why would you use the registry to find an app path? What happened to using the system environment path which is already secured? Registry. Pshhh!

Problem 2: Auto Elevation. Microsoft introduces UAC. People get annoyed with it. Microsoft introduces Auto Elevation. Guess what, still annoying and now possible security hole.

I am fine if Windows asks me to enter a user and password to elevate. It works on my *cough* Linux desktop. Annoying? Yes. Secure? More so. But really, how often does one use admin functions?

Re:Auto Elevation

[slashdot_commentator]

What happened to using the system environment path which is already secured?

Where do you think the system environment path comes from? Why would you include a feature that isn't necessary either for system operation or system security?

Auto Elevation. Microsoft introduces UAC. People get annoyed with it. Microsoft introduces Auto Elevation. Guess what, still annoying and now possible security hole.

Its heartbreaking that Microsoft doesn't have security architects capable of guiding a redesign of their platform to reflect current OS security theory and practices.

I am fine if Windows asks me to enter a user and password to elevate. It works on my *cough* Linux desktop. Annoying? Yes. Secure? More so.

Its also considered a backward practice. Modern authentication systems should not require a "hackable" password. Also, any system administrator using a GUI interface that relies on xwindows (xorg) can be totally vulnerable to hacking. Security design flaws in xwindows were never fully removed, even after twenty years. Everyone is counting on newer graphics architectures (mir, wayland, whatever) to eventually resolve those issues.

Re:Auto Elevation

[cdsparrow]

Well, if it is set to backup everynight, then you'd have to do it then. But yeah, kinda stupid overall.

Easy fix, set perms on that reg entry so you need rights to change it...

Re:Auto Elevation

[TheRealMindChild]

Old windows had a 2047 char limit on the PATH env var. Now it is up to 4095. That sucker can fill up fast, especially if you do development on it

Re:Auto Elevation

[mprindle]

Problem 1: Why would you use the registry to find an app path? What happened to using the system environment path which is already secured? Registry. Pshhh!

Problem 2: Auto Elevation. Microsoft introduces UAC. People get annoyed with it. Microsoft introduces Auto Elevation. Guess what, still annoying and now possible security hole.

I am fine if Windows asks me to enter a user and password to elevate. It works on my *cough* Linux desktop. Annoying? Yes. Secure? More so. But really, how often does one use admin functions?

The way Windows handles stuff I need/user admin features daily. I routinely change my IP address on my interface to work with various systems. I use the task manager to diagnose issues with a system. There are others, but every time I go into the network interface it prompts for the password, I leave the interface for and then go right back into it, I type the password. I understand what the UAC was supposed to accomplish, but in the end it's another layer upon layer of stuff Microsoft has added to attempt to make it more secure.

Re:Auto Elevation

[loonycyborg]

A linker command in larger projects can easily blow over those limits necessitating hacks in buildsystems. To me it's one of most striking examples suggesting just how poorly Microsoft reinvented Unix. Another related issue is that command line is passed as single string in windows api while individual args are sent in separate strings in posix apis. Separate strings make more sense for lowest level api. Parsing command lines and handling escaping to be able to pass arguments with spaces for sure isn't job of a low level api. A shell should handle this since all shells have their own rules for escaping, and conversion layer for this is yet another annoying source of complexity.

Re:Auto Elevation

[t0y]

Actually, he's wrong. The soft limit was 260 and now the OS removing the limit in some builtin applications bringing it back to the native limit which is around 32700 characters (you can test 7-zip, for example, in windows 7: it won't have the soft limit).
The 4095 limit he's talking about is actually linux's.

Re:Auto Elevation

[Opportunist]

Easiest fix would be to move it from HKCU (where it has no reason to be in the first place) to HKLM. Problem solved.

Re:Auto Elevation

[TheRealMindChild]

Wrong. https://support.microsoft.com/...

Re:Registry

[Zero__Kelvin]

Well I actually find this one exceedingly difficult to believe:

"The problem is that low-privileged users can modify Windows Registry values and point to malware."

Back when I was a little boy (Windows User/Admin) you couldn't make changes to the registry as a non-privileged user. Did this actually change? Is it really possible for a low privileged user to modify the registry? Because if so then Windows is beyond fucked in the security department (even more than we all knew they are fscked.)

Just another intentional backdoor

[Anonymous Coward]

Come on, just looking at how hard they're shoving Win10 down everyone's throat, you know the NSA placed a ton of backdoors in Win10 disguised as bugs, enough to last a decade of "bug" discoveries.

Re: Just another intentional backdoor

[Zero__Kelvin]

Why would they do that when they can inject fresh ones at will via Windows Update?

Re:Registry

[Mashiki]

Back when I was a little boy (Windows User/Admin) you couldn't make changes to the registry as a non-privileged user. Did this actually change? Is it really possible for a low privileged user to modify the registry?

It doesn't appear so. I just made a non-privileged user account to see if I could modify the registry. Every time it asked for elevated access and the administrator password. Using their proof-of-concept script, I can't get it to do anything either. Regedit always asks for admin privileges and an administrator password. It appears that this only works if you're using a lower setting of the UAC, have it turned off, or have the notifications disabled for it.

Phony

[duke_cheetah2003]

Come on guys. It even says it right in the script:

if($ConsentPrompt -Eq 2 -And $SecureDesktopPrompt -Eq 1){
                "UAC is set to 'Always Notify'. This module does not bypass this setting."
                exit

Always Notify is the default setting.

Re:Phony

[duke_cheetah2003]

Always Notify is the default setting.

oops i was mistaken, my bad.

Re:Blarney

[Zero__Kelvin]

Yeah. That's pretty strange. The first few times I saw that post there was only a single paragraph, but now it is much larger. I totally understand your comment, as I also observed a much smaller comment at one time, but it now has 50240 characters in it. Perhaps Slashdot is gaslighting us!!!??????

I am not the OP / AC BTW)

Re:Registry

[Mashiki]

Are you using Windows 10? The article said it didn't work in earlier versions of Windows.

No I'm pretty sure it's windows 8.

Exploitable with your normal account, admin group

[raymorris]

> I just made a non-privileged user account to see if I could modify the registry.

Meaning the account you normally use is a member of the Administrators group? According to the article, that's the type of account this targets, a member of the admin group.

Re:Blarney

[Khyber]

Either /. is gaslighting us or the AC has found a way to edit their posts after the fact. Because that is exactly what I saw originally, about ten lines and no "Read the rest of the comment" at the bottom.

Re:Registry

[truedfx]

Admin rights are not needed to modify the registry. Registry keys have ACLs, and many of them under HKEY_LOCAL_MACHINE are set to only allow modification by Administrators, but many of them under HKEY_CURRENT_USER are set to allow modification by that user. The key that this is about can be set by the user.

regedit.exe happens to ask for admin rights when the user is in the Administrators group, but other programs can be used to modify the non-admin bits of the registry.

Re:Exploitable with your normal account, admin gro

[Mashiki]

Meaning the account you normally use is a member of the Administrators group?

Meaning the account I use is a "local power user" account. What? You didn't know you could still make those with a little bit of effort?

More than 20 years but not really vunerable

[dbIII]

Security design flaws in xwindows were never fully removed, even after twenty years

That's because everyone decided to just not use xauth as is and tunnel X via ssh instead to avoid that remote vunerability. If it's not listening (which has been the default everywhere with X since about 1998 when Hummingbird finally fixed their MS Windows version of X) it's not vunerable. You have to work hard and edit odd config files to make it vunerable.

Re:More than 20 years but not really vunerable

[slashdot_commentator]

The point is its a security design flaw to provide an anachronistic feature that no one cares about anymore. (Almost) no one uses ssh to "tunnel" a window for every application that is initiated within their own user session, but that is literally what needs to be done (and a kludge, mind you) to actually have a "secure" xwindow session. While I grasp that xwindow maintainers don't consider it a "compelling" security hole, they should have deprecated the feature decades ago, to resolve the security issue (and implemented an alternative if they thought it was "important" enough to keep).

Re:More than 20 years but not really vunerable

[dbIII]

You do not seem to get it. There is no more secure alternative to a deliberately insecure connection that is only turned on by those who want to use it with legacy systems far too old to have ssh. If it's possible to update the old systems then the problem goes away entirely and you don't have to use the old very open model.
You are doing the equivalent of complaining that an MSDOS prompt does not ask for a login and a password. It's not a problem because it is no longer relevant. Nobody uses that insecure part of X windows anymore apart from with unchanged legacy systems from the early 1990s. If you are doing that then either physical security would be in place or it's an old bit of kit somebody is just playing with.

Re:More than 20 years but not really vunerable

[dbIII]

Almost) no one uses ssh to "tunnel" a window for every application that is initiated within their own user session

With respect, what you are complaining about is an old remote vunerability kept for compatability reasons and has nothing to do with applications run locally so I suggest you go to whoever fed you this talking point and get them to explain it to you a little better.

You are starting to look like you are complaining that the user has the ability to do things with their own application windows. Not a good look. Come back when you have something based on reality when you want to do a little mindless fanboy platform bashing.

Re: Registry

[Zero__Kelvin]

Holy clusterfuck Batman. Microsoft is truly the most incompetent software development company on the planet.

Re: Registry

[Highdude702]

And people defend them at every turn! Im sure you saw some of the posts on the locking of new processors out of anything before win 10. Atrocious.

Microsoft Botnet DOS Attack in Progress

[TheRealHocusLocus]

"You walked away from your machine for ten minutes, ha ha!"
"Windows 10 is updating whether you (the fuck) like it or not."
"This should take a minute (or 20) (or 30)"
"Do not ask why replacing a few signed components takes so long"
"Do not turn off your computer"

Glad I also have an old ATM running XP SP3 to use.

Re:Microsoft Botnet DOS Attack in Progress

[loonycyborg]

Glad I also have an old ATM running XP SP3 to use.

Why not OS/2 Warp? :P

Getting the Blue Signed UAC prompt

[Dwedit]

If you want a Blue UAC prompt that indicates the program being run is signed by Microsoft and everything, you can write a program that invokes privileged parts of Windows.

For example, you can call the DISM package manager of Windows to install or remove components of Windows. And when you call it, you get the Blue "Everything is okay, it's all signed by Microsoft" UAC prompt as opposed to the Yellow "This isn't signed" UAC prompt. But using DISM irresponsibly can break a Windows installation.

Windows 10 is most secure version?

[QuietLagoon]

...This technique only works in Windows 10 (not earlier OS versions)...

Tell me it's not true, Microsoft!

Just don't run as admin

[jader3rd]

It's easy having a separate admin account, which is rarely used.

Re:Registry

[truedfx]

using a non-admin account

This UAC bypass is not supposed to work for that. It only bypasses UAC by exploiting a situation where UAC normally doesn't prompt, which, as far as I know, only happens for admin accounts.

Under an admin account that contained ownership of the key, the script still failed, but I was able to manually change the key only after bypassing the UAC warning to allow Regedit to make changes to the system.

As I posted, that is an artificial restriction on regedit.exe which does not affect other applications. I'd be interested in knowing why the script failed for you. Perhaps you have anti-malware software running which already detects this script specifically. What happens if you use reg.exe to set the key from the command-line? That one does not prompt for admin rights, no matter whether you're logged into an admin account and no matter your UAC setting.

Both of these accounts were local accounts and not Microsoft Accounts

The script works for me with a local account.