August 19, 2016
enSilo senior security researcher Yotam Gottesman has discovered a simple method of bypassing the Windows User Account Control (UAC) mechanism that affects all supported Windows versions, which in some exploitation scenarios leads to attackers executing commands with elevated privileges.
The technique Gottesman discovered relies on the methods used to interact and control environment variables.
Windows environment variables are a set of temporary settings that are specific to each Windows process and are inherited by their child processes, which can read and write their values.
Windows-level environment variables and their capabilities
Unknown to the vast majority of users is that there are a class of system-wide environment variables that apply to the entire Windows operating system.
These include details like the user’s current username, the PC’s domain, and file paths for various folders such as the Windows OS, AppData, user profile, and so on.
This set of environment variables are stored in the Windows Registry, hence they are automatically persistent across reboots and can also be modified by any user via “set” or “setx” commands.
UAC bypasses get worse when combined high-privileged applications
But there is more. Because of the way Windows is built, there are special apps that, when launched by regular users, execute processes with higher privileges (Task Manager, Disk Cleanup – known UAC bypass, Event Viewer – known UAC bypass, more).
When a user launches one of these apps, Windows UAC trusts its execution by default and does not show a warning.
Crooks can use modified environment variables to spawn malicious child processes under the legitimate app and execute an attack. Windows UAC will stay quiet while the attack runs with elevated privileges because UAC trusts the parent process.
Proof-of-concept attacks that work
Gottesman described five types of attacks, which can be combined, in a technical write-up for enSilo.
In one example, an attacker can create a copy of the C:/Windows folder and modify the system-wide environment variable to point to the wrong Windows OS folder. This setting activates after a system reboot and allows the attacker to load malicious DLLs on the system.
This doesn’t mean the attacker has hijacked the OS, but when other legitimate apps need to load a system DLL, they’ll be pointed to the wrong location, where the attacker can easily modify and replace files without security products warning the user.
In another similar attack, he tricked Windows into loading the same C:/Windows folder from a local network folder, meaning the malicious DLLs don’t even have to be stored on the same filesystem.