As a follow-up to our Statement on Recent Post - CVE-2019-18988 regarding the encryption of TeamViewer registry keys, we would like to again clarify that TeamViewer account passwords are not affected as we use Secure Remote Password (SRP) for account authentication. The issue discussed in a blog post by a security researcher concerns the local data storage and encryption of the TeamViewer client as detailed below. In order to take advantage of the issue, someone would need to have already gained access to a user’s system via other means.
TeamViewer account password encryption has not been compromised. TeamViewer implements Secure Remote Password (SRP) for account authentication.
In the blog post, the researcher mentions a privilege escalation risk. There’s no direct vulnerability offering someone the ability to gain additional privileges on the local system. The only risk would be in the case that a user is reusing the exposed passwords on other services.
In the blog post the researcher discusses the encryption of certain Windows Registry entries, which may include the TeamViewer client settings-password that is used to restrict configuration access. Additionally, these registry keys can hold temporary information used only in specific TeamViewer client deployments as well as for the TeamViewer license and statically configured session passwords of legacy versions. The blog post also refers to some unused registry keys.
As this is a local exploit, in order to take advantage of the issue, someone would need to have already gained access to a user’s system via other means. In this case, someone who manages to decrypt the registry entries in question would gain access to:
The remainder of the registry entries are used only during deployment process and are automatically cleaned up afterwards.
Our security engineers are working on concrete solutions to mitigate the researcher's findings such as further improving the encryption for the data points that need to be available on the local system.
The changes will be centered around improving the security and limiting the use of local registry keys. There are certain values that need to be stored locally for the usage of TeamViewer. As the client has changed over time through major releases, some of those are still required while others make sense to store centrally or deprecate out of the product.
Here are the 7 registry keys discussed in the researcher’s blog post:
This registry key is only valid in TeamViewer versions older than TeamViewer 9. By default, TeamViewer utilizes a dynamic password system that generates a new session password with each session. For those users who chose to set a static session password in order to support unattended access, that value is stored in this registry key. Since then we introduced an option called easy access, based on the account authentication and inviting the user to distance themselves from using a static password which can be weak, re-used from somewhere else, guessed, etc.
Strengthen the cryptography. Adapt the storage/verification to a more modern method.
This registry key is used for cases where users chose to export their configurations in order to make it portable to other systems. It is important to note that this key is an ephemeral value that is only existent during the export/import of a configuration.
Strengthen the cryptography. Change export file type to something other than .reg so that users don’t mistakenly import this value permanently into the registry.
This registry key was added to the client as preparation for an unimplemented backend feature. It is not used.
Remove the key from the client.
TeamViewer has quite a few methods of reaching the internet that make it easy for users to use the product in a large variety of network configurations. Be it TCP, UDP hole punching, over HTTP ports or by inheriting the local systems proxy configuration. Sometimes customers chose to set up a custom proxy just for TeamViewer, and in those cases, we store a password for that proxy configuration in this registry key.
Strengthen the method used to read the value. This entry would only be considered if the service is running which allows us to use a strong cryptographic model.
This is the license key for TeamViewer clients installed with a license. The registry key only exists until the client registers with our servers; after that it is deleted.
For newer versions of TeamViewer (some v14 and all v15) the license is under a subscription model that is tied to an account authentication. The registry key is not used in these cases.
Remove the key from TeamViewer 15 as it is not used in that version. Legacy versions still need to support that temporary entry, given the former licensing model.
As with most client applications, the TeamViewer client is open to configuration by the current logged in user on the machine. We offer the option to lock those configurations with a password. This is usually used in deployments in larger environments to help IT administrator preventing any alteration of the configuration.
Change the way this is handled cryptographically.
TeamViewer implemented the Secure Remote Password protocol for authentication starting with TeamViewer 9. This key is used to store the SRP password verifier as part of that protocol.
No fix needed, works as intended. Not vulnerable.
Malware getting access to Proxy Passwords and the TeamViewer license are pretty bad things, but you are mistaken when you say most people don't lock the options menu...and, worse, people will often have one password that they reuse across the platform, (login password, options menu and remote access etc).
You're effectively saying that your product is unusable in a secure enviroment, and that large features like the proxy implementation leak important data, but it's OK because people don't use them or have usually implemented other solutions so it's fine....which is, frankly, a bit weird...but, anyway, I made a video of your latest release being exploited so that your users can decide for themselves how bad this is.or isn't.