Overwolf Local Privilege escalation (Ghost dll)

Special thanks to @Chriss_WH who discovered this with me.

This vulnerability is pretty straightforward.  Anyone can go from basic user to system level from dropping a CRYPTBASE.dll into c:\ProgramData\Overwolf\Overwolf\Overwoldupdater directory

I submitted this to Overwolf 01/29/2020

05/03/2020 They told me i can post about it.

 

Installed Overwolf

Dropped the malicious DLL CRYPTBASE.dll into c:\ProgramData\Overwolf\Overwolf\Overwoldupdater directory

Then restart this service.  This service will then call the DLL as system as shown in the procmon output in the next image.

Restarted the service OverWolfupdater while running procmon and found the ghost dll being called with system permissions.  Since the permission allows the everyone group to write to the directory c:\ProgramData\Overwolf\Overwolf\Overwoldupdater where the dll CRYPTBASE.dll is being called as system it allows for an escalation of privileges to system

 

Overwolf I am assuming has fixed it since they told me I can now post.  I have not tested again to ensure their fix is in place.

 

.Net System Persistence / bypassuac / Privesc if the user who installs .net loses permissions

After Installation of “.NET core” modifies a registry key path that local system calls when different Microsoft default installed services run automatically which goes from user to System Persistence 

APPLIES TO:

.Net

Path: Computer\HKEY_USERS\.DEFAULT\Environment or hku\.default\Environment

Post explains what “user” .Default is : https://devblogs.microsoft.com/oldnewthing/20070302-00/?p=27783

Before installation:

    

After Installation:

When a local System service runs and sees the environment variable %USERPROFILE% it knows to navigate to “c:\windows\system32\config\systemprofile\”.  Since the path was changed after installing .Net SDK the local system service ends up searching for a missing dll under the user writeable path “C:\users\kool\Appdata\Local\Microsoft\WindowsApps\”.

https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/install

The path that gets called by different local system services on bootup is

C:\Users\kool\AppData\Local\Microsoft\WindowsApps\WptsExtensions.dll

2 Example services that calls this dll on boot:

Another:

Before adding the malicious dll (svchost.exe tries to queryopen and createfile a dll that is not there)

Added the malicious dll to the user writeable path

   

 

CVE-2020-1988 (Unquoted path)

Software Version:
———————————————————-
Description Of Issue : Unquoted Service Path that allows escalation to system. Due to spaces in the path if an adversary places an exe along the path then they can get system execution.
———————————————————-
Steps To Reproduce : An adversary can drop C:\Program Files\Palo.exe or C:\Program Files\Palo Alto.exe. Can test it with calc.exe and rename it to the exe in one of these paths. Then you can reboot or just restart the service Pan GlobalProtect Service (PanGPS) and it will kick it off as system. The final path that the service is looking for is “C:\Program Files\Palo Alto Networks\GlobalProtect\PanGpHipMp.exe”

Wondershare drfone Local Privilege Escalation

The issue is with permissions in the directory.
The directory  “C:\Program Files (x86)\Wondershare\drfone\Library\DriverInstaller” allows any user to have full control of it.  The issue with this is that DriverInstall.exe is located in this directory.  An attacker can replace the DriverInstall.exe with their malicious executable with the same name.  Then the attacker would start or restart the service: WsDrvInst (Wondershare Driver Install Service) And the executable will kick off as system.
This is a privilege escalation to system from any user.
Here are the permissions given the directory after install
get-acl “C:\Program Files (x86)\Wondershare\drfone\Library\DriverInstaller” |flPath   : Microsoft.PowerShell.Core\FileSystem::C:\Program Files (x86)\Wondershare\drfone\Library\DriverInstallerOwner  : BUILTIN\AdministratorsGroup   BUILTIN\Users Allow  FullControl
The key here is that  Access : BUILTIN\Users Allow  FullControl  (this should not be there)
That gives all users full control over the files in this directory.  There is an executable being called as system when the service Wondershare Driver Install Service is ran.  So any user can become system on any machine that has the software installed.

Shell-usoscan: An unquoted Environment Variable path

Unquoted paths are abused frequently on engagements.  Normally an attacker would see an unquoted service path, not an unquoted schedule task path.  What makes this unique is that it is an environment variable that has a space in it that allows for an attacker to abuse it.  The key is, if the path is unquoted then Windows sees the space character in the path as a delimiter and will then search for program.exe instead of knowing to go to C:\Program Files\.  I was surprised that an up to date Windows 10 machine would still have a vulnerability like this.

 

The scheduled task shell-usoscan is present when Windows 10 reports issues updating to the most recent version and uses the environment variable %programfiles% with a path that is unquoted.

Figure 1: shell-usoscan Schedule Task

Figure 2: %programfiles% is unquoted C:\Program Files

If Access Control Lists (ACLs) for C:\ allow an attacker to write to the root of C:\ the unquoted path can be used for local Privilege Escalation to SYSTEM.

Because the path is unquoted and there is a space after ”Program” even though it is using the environment variable an attacker could drop a binary called Program.exe to C:\ and get execution as SYSTEM.

 

APPLIES TO:

Windows 10

Reference: https://shell_usoscan_versions_windows

Versions: 1507, 1511, 1607, 1703, 1709, 1803, and 1809 and current

Persistent System Execution

Scheduled Task: shell-usoscan

Is scheduled by default as a daily task

Requirements for vulnerability:

Misconfigured ACL that allows non-Administrator users to write to C:\

 

08/26/2019: Submitted to MSRC

09/03/2019: Initial response from MSRC:

MSRC closed the case and asked how it was a MITM or social engineering attack

09/10/2019: Reached back out to ask MSRC because their response didn’t make sense; informed MSRC of my intent to publish findings.

09/10/2019: MSRC reopened the ticket

09/10/2019: MSRC final response:

Will be a next version fix

 

This is the link provided by Microsoft as a point of reference:

https://blogs.msdn.microsoft.com/aaron_margosis/2014/11/14/it-rather-involved-being-on-the-other-side-of-this-airtight-hatchway-unquoted-service-paths/

 

The reference sent by Microsoft refers to vendors having misconfigured services.  This is a Microsoft owned Scheduled Task.