With the welcome shift of companies revoking local-administrator permissions from standard users, came the challenge of how to allow users to perform administrative actions on their machines — such as installing approved software — without making them full-blown administrators on their machines. Several tools exist to resolve this problem by allowing a low-privilege user to perform software installation in an elevated context. An issue I discovered with this approach is that when a user can interact with an installer deployed using one of these solutions, they can often escalate privileges on their machine. This post will demonstrate privilege escalation techniques using two pieces of software: System Center Software Center, and Viewfinity.
SCCM Software Center
System Center Configuration Manager (SCCM) enables administrators to publish software installers to Software Center either to the logged-in user, or NT Authority\System. The latter is more common because many pieces of software do not install using low-privilege accounts. More information on SCCM deployment types can be found here. This approach is useful for software that is only needed under specific circumstances, such as for troubleshooting. An example of a scenario encountered during an engagement is described below.
Below you can see the Software Center published application “Flowdock” as available for install. One thing that sticks out is that it was labeled “Attended Install”.
The setup was started, and the program installer launches. The installer allowed me to set the path of installation, which was usually necessary for this attack to work (though not always, as you will see in the Viewfinity section below). This is because when a program is installed to “Program Files”, low-privilege users cannot write to the installation directory. When we can control the path of installation, however, we can write to a location where we have adequate permissions. I installed the program to my Desktop path, which is part of my user profile.
I proceeded with the installation until the final screen with the “Finish” button was presented. Without closing the final screen on the installer, I launched PowerShell.
Using PowerShell, I backed up the original program binary and copied cmd.exe to the original binary’s location. Next, I finished the installation leaving the “Launch Flowdock” check-box checked.
Cmd.exe was launched by completing the installation, and after running “whoami” we can observe that we are running as “NT Authority\System”.
During a different engagement, I was tasked with testing a client’s corporate image for vulnerabilities. Initial testing with automated tools such as PowerUp didn’t turn up anything obvious. Because of this, I looked around the system manually. My first thought was to explore running processes and services. I thought I may find a 0-day in some home-grown software since I had a good amount of time for the test. First, I looked at the running services, and researched anything that I didn’t recognize. The first piece of software I did not recognize on the system turned out to be Viewfinity - a privilege management suite of software. This software differs from Software Center, as it is used for blacklisting, white listing, and privilege elevation.
As I was browsing the filesystem, I saw an executable file called vf_elevate.exe. This sounded promising for obvious reasons, so after additional research I looked around the filesystem for a configuration file to figure out how this program worked, and if it was actually being used. A snip of the configuration is shown below. What you can’t see in this image is the program group name which indicated this group is supposed to run with elevated permissions.
After analyzing the configuration file, I downloaded Sysinternals Process Explorer, and the version of Wireshark referenced in the configuration file. It was important to download the specific version referenced in the configuration file because Viewfinity performs an SHA1 checksum on the file to determine which policies apply to it. I did not use the method described in the above SCCM example in this case though it was also possible. Instead, I ran the Wireshark installer and launched it after installation. I wanted to show the alternative method of launching an unintended executable elevated to show that control of the installation path is not always a requirement to make this attack work.
Using Process Explorer, we can see that the process launches as high-integrity, but is still running as the low-privilege user. This behavior is also different from what was seen with Software Center. I am not sure what mechanism Viewfinity uses to escalate privileges, but it always elevates using the logged-in user’s account. Hit me up on twitter if you know how it does this.
While looking around inside Wireshark, I tried all the assumed “easy-wins” like using the open or export dialogs to launch cmd. What I found was that anything I launched from these dialogs would run as medium integrity and not inherit the permissions of Wireshark. Lucky for me, there is also a Lua script console built into Wireshark. I launched cmd using Lua, and it launched as a high-integrity process. This can be seen in the Process Explorer window.
To verify I was running as an Administrator, I created a user and added them to the local “Administrators” group.
Using “net user”, we can see the created user is a member of the Administrators group.
The mitigation for this issue is simple. Do not allow users to interact with installers that run in an elevated context. This can be done by deploying the installer using a silent flag, or by deploying custom installers that run silently. Additionally, do not enable users to change the installation path or launch the installed program post-installation.