---

Introduction

SafeBreach Labs discovered a vulnerability in TeamViewer.

In this post, we describe the CVE-2019-18196 vulnerability we found in TeamViewer.

We then demonstrate how this vulnerability could have been exploited by an attacker during a post-exploitation phase in order to achieve persistence and in some cases defense evasion. This vulnerability may have allowed attackers to implant an arbitrary unsigned executable, executed by a signed service that runs as NT AUTHORITY\SYSTEM.

Note: In order to exploit this vulnerability the attacker needs to have Administrator privileges.

TeamViewer

TeamViewer is a proprietary software application for remote control, desktop sharing, online meetings, web conferencing and file transfer between computers.

Part of the software runs as a service using NT AUTHORITY\SYSTEM permissions.

Vulnerability Discovery

In our exploration, we targeted the “TeamViewer 14” service. I seemed interesting because:

1. The executable of the service is signed by TeamViewer and if the attacker finds a way to execute code within this process, it can be used as an application whitelisting bypass which can lead to security product evasion.
2. This service automatically starts once the computer boots, which means that it’s a potential target for an attacker to be used as a persistence mechanism.
3. It runs as NT AUTHORITY\SYSTEM – the most privileged user account.

When the service is started, TeamViewer_Service.exe tries to load a missing DLL file:

PoC Demonstration

In order to test this vulnerability, we compiled an x86 unsigned arbitrary DLL which writes the following to the filename of a txt file:

1. The name of the process which loaded it
2. The username which executed it
3. The name of the DLL file

Using the CVE-2019-18196 vulnerability, we were able to load an arbitrary DLL file which was signed by TeamViewer GmbH and run as NT AUTHORITY\SYSTEM. Our code was executed within TeamViewer_Service.exe

Root Cause Analysis

Once the service is loaded, it calls the WSAStringToAddressW WinAPI function (which causes the process to load the ws2_32.dll library, because this function is implemented there).

Next, the ws2_32.dll library loads the mswsock.dll library, and after a few calls it gets to the SockLoadHelperDll function, which tries to load wshtcpip.dll using LoadLibraryExW:

There are two root causes for this vulnerability:

1. No signature validation (or for that matter, any validation) was made against the DLL file which the service tried to load (i.e. calling the WinVerifyTrust function).
2. Uncontrolled Search Path – The lack of safe DLL loading
   The library tried to load the mentioned DLL files using LoadLibraryExW without flags (which is identical to LoadLibraryW). The problem is that it only used the filename of the DLL, instead of an absolute path. In this case, it is necessary to use the LoadLibraryExW function in order to control the paths from which the DLL is loaded, using the LOADLIBRARYSEARCH_SYSTEM32 flag, which tries to load the library only from the System32 folder (in our case SysWOW64).

Although this issue is caused by Microsoft’s DLL library (mswsock.dll), there are a few actions that TeamViewer can do in order to remediate this issue, including

verifying the signature and loading the real mswsock.dll from SysWOW64 before the Microsoft component loads it.

Potential Malicious Uses and Impact

Below we show two possible ways that an attacker could have leveraged these vulnerabilities which we discovered and documented above.

Whitelisting Bypass, Defense Evasion

The vulnerability give attackers the ability to load and execute malicious payloads within the context of TeamViewer GmbH’s signed process. This ability might be abused by an attacker for different purposes such as execution and defense evasion, for example: Application Whitelisting Bypass.

Persistence Mechanism

The vulnerability gives an attacker the ability to load and execute malicious payloads in a persistent way, each time the service is loaded. That means that once the attacker drops a malicious DLL, the service will load the malicious code each time it is restarted.

Affected Products and Versions

TeamViewer 11 (Windows Client) up to 11.0.133222

TeamViewer 12 (Windows Client) up to 12.0.181268

TeamViewer 13 (Windows Client) up to 13.2.36215

TeamViewer 14 (Windows Client) up to 14.6.4835

Timeline

July 23rd, 2019 – SafeBreach reported the vulnerability to TeamViewer.

Aug 20th, 2019 – TeamViewer confirmed the vulnerability. TeamViewer said they will report the issue to Microsoft because the root cause is in Microsoft’s component, and will get back to us with Microsoft’s answer.

Oct 7th, 2019 – TeamViewer said that Microsoft’s answer was that they do not intend to fix the issue, at least not in the short term and that they recommend developers to mitigate the issue themselves.

TeamViewer asked to delay our publication by 1-2 weeks so they can release a fix for all affected versions.

Oct 22nd, 2019 – TeamViewer provided us with the affected versions, released a patch to the customers and issued CVE-2019-18196. They asked to delay the publication by a week in order to provide customers with time to get patched up in advance.

Oct 22nd, 2019 – SafeBreach agreed to delay the publication.

Oct 22nd, 2019 – TeamViewer released a security bulletin [1].

References

[1] https://community.teamviewer.com/t5/Announcements/Security-bulletin-CVE-2019-18196/td-p/74564