Tempest ́s advisory team recently detected a vulnerability in Avira AntiVirus in its Windows version which, if exploited, could lead to privilege escalation attacks on this system. The flaw is present in a file named SwuConfig.json, which, by default, has open access and control permissions for all Windows users.

By using as the attack vector an object type present in operating systems named Symbolic Links, the researchers were able to exploit the permissions assigned to the JSON file to deploy a malicious DLL in Windows´ System32 folder.

Symbolic links are a special type of object that contains a reference to another file or folder. On Windows, there are several types of symbolic links, but, for a better understanding of the exploit described here, we will restrict the concept to only two types, Object Manager Symbolic Link and NTFS Mount Point (or NTFS Junctions).

Object Manager is a Windows component for centralizing and managing internal objects from this operating system, including symbolic links.

An example of Object Manager Symbolic Link is the volume unit letters; on a Windows computer, the C: drive is nothing more than a symbolic link to “device\HarddiskVolume1”. The following image shows the link between the HarddiskVolume1 device and its symbolic link “C:\” in Object Manager.

Image 1 — A device volume represented by a symbolic link

Creating, altering, or deleting these device-referenced symbolic links can be accomplished by any user (regardless of their privileges) through an API called DefineDosDevice, represented as follows:

    BOOL DefineDosDeviceW(DWORD dwFlags,

    LPCWSTR lpDeviceName,

    LPCWSTR lpTargetPath );

The researchers observed that the argument IpDeviceName, present in the API, does not check the name/letter of the driver (which is fundamental for the exploitation of this flaw). For example, it is possible to specify, instead of a letter, a path (eg “GLOBALROOT \ RPC Control \ Link”) so that an object (“Link” in this case) is added to the namespace “\RPC Control” instead of the original namespace (DosDevice or GLOBAL ??) as shown in the following code.

    int main()

    {

    DefineDosDeviceW( DDD_NO_BROADCAST_SYSTEM | DDD_RAW_TARGET_PATH,

    L”Global\\GLOBALROOT\\RPC Control\\Link”,

    L”\??\\C:\\ProgramData\\Link”);

    }

The result of this command would be as follows

Image 2: Creating a symbolic link in a directory other than DOSDevices.

Another symbolic link involved in the research lies in the NTFS Mount Points (NTFS junctions), which allows for creating a mount point for other directories; for example, a directory located at “C:\Windows\System32\sysprep\” could be accessed through a junction located at “C:\Users\test\Desktop\Link”.

The only requirements for creating these junctions are: reading permission to the referenced directory (“C:\Windows\System32\sysprep\”) and writing permissions to the directory where the junction will be stored (“C:\Users\test\Desktop\Link”).

A highlight in this process lies in the Reparse Points (a “user-defined data collection — whose format is understood by the application that stores the data — and a file system filter, used to interpret the data and process the file”, as per Microsoft documentation).

Implemented in the creation of NTFS junctions, Reparse Points can be defined in the creation of a folder; however, the directory must be empty, otherwise, the creation of the junction will be unviable since it is not allowed to create folders or files within a folder that already contains Reparse Points.

The flaw discovered by the consulting team is present in Avira Software Update, which is a tool designed to automatically update all programs installed on the computer whenever updates are available to “maintain system security”.

Image 3 illustrates the moment when the service named Avira.SoftwareUpdater, counting with SYSTEM privileges, handles files in a fully accessible directory, and, in image 4, we can see how the SwuConfig.json file (available at C:\ProgramData\Avira\SoftwareUpdater \) is also fully accessible by any user of the system.

Image 3: json file in user directory
Image 4: json file permissions on user-controlled folder

To exploit this vulnerability, two types of symbolic links must be created, an Object Manager Symbolic Link named SwuConfig.json pointing to the file C:\Windows\system32\api-ms-win-core -fibers-l1–1–1.DLL, and an NTFS junction inside C:\ProgramData\Avira with the name SoftwareUpdater. Since there is a folder with the same name, it must be renamed before exploitation in order for the junction to be created without error.

The reparse point to this NTFS junction must be manipulated so that the Object Manager Symbolic Link named SwuConfig.json is queried.

For the simultaneous creation of these two symbolic links, the researchers used the CreateSymLink tool. Image 5 shows the creation of the symbolic link within Object Manager.

Image 5: symbolic link referencing the json file.

After the symbolic links have been created, it is necessary to wait for Avira to try to create SwuConfig.json again — which will happen after a new Software Updater has been run. Image 6 shows the already created file with all possible permissions in the chosen directory.

Image 6: file permissions created
Once control over the api-ms-win-core-fibers-l1–1–1.DLL file is complete, it is possible to overwrite its contents with a malicious DLL in order to execute arbitrary code. The next time Avira update service is run, it will import this malicious DLL, inheriting the permission of the process that imported it— NT AUTHORITY \ SYSTEM— (image 7).
Image 7: cmd.exe with System permissions

According to Tempest’s researchers, the study warns of processes that have elevated system privileges, specifically when they need to manipulate files or directories created in folders which are common to all users.

Depending on how these permissions are assigned, these processes can be used as a tool for writing arbitrary malicious files.

In turn, these malicious files can be used to exploit vulnerabilities such as DLL Hijacking, Unquoted path, and others.

.   .   .

Report Timeline

  • 12 Apr 2019 — the request for a CVE-ID began.
  • 15 Apr 2019 — the Responsible disclosure of the manufacturer was initiated.
  • 16 Apr 2019 — the manufacturer requested more details about the flaw. An email containing more information was sent.
  • 21 Apr 2019 — CVE (reserved) was signed CVE-2019–11396.
  • 21 Apr 2019 — an email was sent to the manufacturer requesting an update of fix status.
  • 23 Apr 2019 — the manufacturer successfully reproduced the vulnerability and informed that they had started to work on a correction.A new email was sent requesting an update about the time needed to release a patch.
  • 29 Apr 2019 — the manufacturer claimed that the development team had started the correction process, but did not have a date for the fix to be delivered
  • 21 May 2019 — The manufacturer said the patch would be released within 1 week.
  • 28 May 2019 — The manufacturer reports that the vulnerability had been fixed and that the update was made public.
  • o4 Jun 2019 — Email sent to the manufacturer informing that the vulnerability has not been fixed, despite the patch.
  • 18 Jun 2019 — Avira reports that the vulnerability has been fixed.
  • 19 Jun 2019 — Email sent to the manufacturer explaining that the vulnerability persists.
  • Jul 03 2019 — Avira responds that it had identified the issue and was going to patch it again.
  • 08 Jul 2019 — The manufacturer patched the vulnerability.