Avira VPN (2.15.2.28160) Elevation of Privilege through Insecure Update location

Product Version: Avira Phantom VPN
Downloaded from: https://package.avira.com/package/oeavira/win/int/avira_en_vpn__ws.exe
Operating System tested on: Windows 10 1709 (x64)
Vulnerability: Avira VPN Elevation of Privilege

Brief Description: The Avira Phantom VPN Service performs a handful of checks when it checks for an update (this happens when the service starts, so on boot or via manual start/stopping). When updating, the VPN service downloads the update to “C:\Windows\Temp\” as AviraVPNInstaller.exe (which any user can write to). It then checks if the file is signed, and if the version is less than the installed product version. If these requirements are met, the service will run the update binary as SYSTEM.  It is possible to overwrite “AviraVPNInstaller.exe” with a signed, valid Avira executable (with a version greater than the installed version) that looks for various DLLs in the current directory. Due to the search order, it is possible to plant a DLL in “C:\Windows\Temp” and elevate to NT AUTHORITY\SYSTEM.

Vulnerability Explanation
When the Avira VPN service (Avira.VPNService.exe, version 2.15.2.28160) starts, it checks to see if there is an update available:

After some poking, it was determined that the VPN service updates from “C:\Windows\Temp”

As you may know already, any authenticated user can write (but not read) to C:\Windows\Temp. Once the update is there (as C:\Windows\Temp\AviraVPNInstaller.exe), the VPN service checks the “FileVersion” property of the executable in order to determine if the “update” is already installed on the system:

If the version of the file shows it hasn’t been installed, the service will check the file to make sure it is valid and signed by Avira:

If the file is indeed valid and signed by Avira, the VPN service will start the “update” package. Since all of this happens in a place a low privilege user can write to, it is possible to hijack the update package and perform DLL sideloading.

In order to hijack “AviraVPNInstaller.exe”, three of the following conditions have to be met:

  1. “AviraVPNInstaller.exe” has to be signed by Avira
  2. The signature on “AviraVPNInstaller.exe” has to be valid (any modification of that file would invalidate the signature
  3. The version number of “AviraVPNInstaller.exe” proves the update hasn’t been installed on the system.

This means we need to abuse an Avira signed file that has a version greater than what is deployed.

After some hunting, “ToastNotifier.exe” fit the bill as it satisfies all three requirements:

(If you are curious of where ToastNotifier.exe came from, it is from the Avira Antivirus product suite that was abused in a similar manner in a bug reported on the Antivirus platform).

To exploit this, all we need to do is copy “ToastNotifier.exe” to “C:\Windows\Temp\AviraVPNInstaller.exe”. Since the requirements are met, the VPN service will run it as SYSTEM when the service restarts. This can be accomplished via a reboot, or by running powershell as an Administrator and then doing “Get-Service AviraPhantomVPN | Stop-Service” followed by “Get-Service AviraPhantomVPN | Start-Service”. Once executed, “ToastNotifier.exe” (which is now C:\Windows\Temp\AviraVPNInstaller.exe) will try to load a handful of DLLs out of C:\Windows\temp:

 To elevate our privileges to SYSTEM, all we need to do is provide one of those DLLs. In this case, we will hijack “cryptnet.dll”. This will result in the VPN service starting our “AviraVPNInstaller.exe” binary as SYSTEM, which will then load “cryptnet.dll” as SYSTEM, which is our malicious code. This results in elevation from a low privileged user to SYSTEM:

 

Disclosure Timeline:

  1. Submitted to Avira on September 28, 2018
  2. October 1, 2018: Issue reproduced by Avira
  3. December 13, 2018: Issue fixed by Avira

 

 

 

 

 

 

 

 

 

Avira VPN 2.15.2.28160 Elevation of Privilege

Product Version: Avira Phantom VPN version 2.15.2.28160

Downloaded from: https://package.avira.com/package/oeavira/win/int/avira_en_vpn__ws.exe

Operating System tested on: Windows 10 1803 (x64)

Vulnerability: Avira VPN Elevation of Privilege

Brief Description: The Avira Phantom VPN service changes the DACL on “C:\ProgramData\Avira\VPN\VpnSharedSettings.backup” and “C:\ProgramData\Avira\VPN\VpnSharedSettings.config” when a configuration change is made in the VPN settings menu. By setting a hardlink on “C:\ProgramData\Avira\VPN\VpnSharedSettings.backup”, it is possible to overwrite the DACL on an arbitrary file, leading to elevation from a low privileged user to SYSTEM.

Vulnerability Explanation

When making a configuration change via the VPN GUI, the VPN service (Avira.VPNService.exe) calls the function “AdjustSecurity()” that resides in “Avira.VPN.Core.dll” to change the DACL to allow any authenticated user to write to “C:\ProgramData\Avira\VPN\VpnSharedSettings.backup” or “C:\ProgramData\Avira\VPN\VpnSharedSettings.config”. When a configuration change is made (which can be done as a low privileged user), the service makes sure the “Shared” VPN profile setting file (C:\ProgramData\Avira\VPN\VpnSharedSettings.backup and C:\ProgramData\Avira\VPN\VpnSharedSettings.config) exist by calling “EnsureFileExists()”:

If the configuration file doesn’t exist, the service will create it and continue. If it does, it simply continues to  the “StorageSecurity.AdjustSecurity()” function. In the case of the shared vs private configuration profiles, the “StorageType” being passed is either “AllUserAccess” or “Secure”. The “private” VPN profile is assigned the “Secure” storage type while the shared profile is assigned “AllUserAccess”.

When the “AdjustSecurity()” function is called (passing the storage type of the configuration file), it adjusts the DACL on the file itself appropriately. This is where the bug lies. For the “shared” profile (with the StorageType of “AlluserAccess”), the VPN service calls “AdjustSecurity()” and grants the everyone full control over the file:

This is dangerous because the “SetAccessControll()” call changes the DACL on a file in which a low privileged user can control. So, how do we exploit this?

First, an attacker needs to create a hardlink on “C:\ProgramData\Avira\VPN\VpnSharedSettings.backup” and point it at a file. In this case, we will point it at  “C:\Program Files (x86)\Avira\VPN\OpenVPN\phantomvpn.exe”. Doing so will overwrite the DACL on “C:\Program Files (x86)\Avira\VPN\OpenVPN\phantomvpn.exe”.

After doing so, open the VPN and click the “Settings” tab:

After doing so, uncheck the “Send Diagnostic Data” box. This will trigger a config change and kick the code-path off:

At this point, the DACL on “C:\Program Files (x86)\Avira\VPN\OpenVPN\phantomvpn.exe” has been overwritten to allow any user to write to it. The attacker now just needs to copy a malicious binary to replace it:

Once done, execution of the malicious binary can be accomplished by simply trying to connect to the VPN. This can be done by clicking “Secure my Connection” in the VPN GUI:

After clicking “Secure my connection”, you should see a few cmd.exe processes running as SYSTEM:

Disclosure Timeline:

  1. Reported to Avira on September 28, 2018
  2. October 1, 2018: Avira acknowledged the report
  3. October 4, 2018: Avira was able to reproduce
  4. December 13, 2018: Issue resolved