Avast Secure Browser (ASB) is a browser with built-in security and privacy features. Developed by Avast, it can be found free of charge on its official website.

The security analyst of Tempestโ€™s consulting team, Silton Santos, has recently discovered a vulnerability that hits the ASB upgrade process, resulting in privilege escalation.

In summary, there was a privileged process responsible for the ASB updates that performed a recording operation in a file and, in sequence, redefined its permissions for full control, making it accessible to any user. Therefore, this operation was redirected using a hardlink to an arbitrary file. With this, the privileged process started to operate with the redirected file, consequently also redefining its permissions.

For a better technical understanding of the exploitation, the concept of the hardlink and its peculiarities will be the first one to be approached:

According to Microsoft documentation, hardlinks are symbolic links that reference a representation of file contents on the NTFS system through other directories in the same volume.

This type of link can be easily created by using the mklink tool (present in current versions of Windows operating systems) through the /H parameter. There are some requirements for creating hardlinks using mklink:

  1. The user needs recording privileges in the target file;
  2. The user needs to writing privileges in the directory in which the hardlink will be created.

Requirement 1 would eliminate the possibility of using hardlinks in exploits that impact on a privilege escalation, bearing in mind that, if the user already has permission to write in the target file, it would be enough to overwrite it with the desired content.

Fortunately, James Forshaw from Google Project Zero discovered that, at the moment the file is opened by the NTOpenFile function, used during the implementation of the CreateHardLink API โ€” responsible for creating hardlinks โ€” the value FILE_WRITE_ATTRIBUTES is sent as an attribute of the object, thus identifying the need for recording privilege during link creation. However, James also detected that, when the NTOpenFile function is called, it is possible to suppress the FILE_WRITE_ATTRIBUTES flag, which makes it possible to create the hardlink with read-only permission. For more details about exploring this behavior, see the article BetWeen Rock and hard link.

In addition, Project Zero has made available in its Github a toolkit that implements, among other things, the action described above.

First, an inspection with AccessEnum (part of Sysinternals) was performed on directories related to Avast Secure Browser in order to find excessively permissive files, as illustrated in the image below:

Figure 1: Detection of the Update.ini file which is too permissive.

As shown in Figure 1, one of the excessively permissive files is Update.ini, located in the directory C:\ProgramData\AVAST SOFTWARE\Browser\Update. In the figure, it is also possible to notice that any user may have total control over the Update.ini file.

Based on this directory, some filters were created with ProcMon (also part of Sysinternals) that made it possible to monitor any operation by a privileged process with the Update.ini file. As can be seen in Figure 2, it is possible to notice a process called AvastBrowserUpdate.exe performing some operations in the Update.ini file:

Figure 2: Identification of the interactions of AvastBrowserUpdate.exe with the Update.ini file.

The next step was to replace the Update.ini file with a hardlink pointing to the C:\Program Files\Avast Software\Browser\Update\1.5.245.0\psmachine.dll and start the update process. Thus, the permissions of psmachine.dll of the DLL have been reset to full control for any user (as seen in picture 3).

Figure 3: Update.ini file permissions before and after scanning.

Finally, to complete the privilege escalation exploit process, the DLL content was replaced by one that returned a personified shell with the user NT AUTHORITY\SYSTEM.

Figure 5: Shell that has been personified with the privileged user
  • 23/Aug/2019 โ€” Responsible disclosure is started with Avast;
  • 26/Aug/2019 โ€” Vulnerability analysis is started;
  • 15/Sep/2019 โ€” Vulnerability is confirmed by Avast which initiates correction;
  • 20/Dec/2019 โ€” Avast informs that it is performing the final checks and that the patch is scheduled for 20/Jan/2020;
  • 20/Dec/2019 โ€” Avast thanks all the support provided and asks for a name to carry out a public thank you;
  • 20/Jan/2020 โ€” Avast communicates that there is a public release with the fixed vulnerability;
  • 21/Jan/2020 โ€” Avast releases a thank you note for all the given support