CVE-2024-0819: Incomplete Protection of Personal Password Settings
This semester, I had the opportunity to take part in a reverse-engineering seminar offered by Jiska Classen at HPI in a team with Lukas Radermacher and Nils Hanff. Together, we decided to take a look at the TeamViewer remote desktop application and were able to find a vulnerability regarding the application's personal password settings that enabled local privilege escalation on a multi-user system (CVE-2024-0819).
In this blog post/writeup, I want to give some insights into how this vulnerability came to be and how we found it.
TeamViewer's Basic System Architecture
During our analysis, we only looked at the Linux and Windows versions of the TeamViewer application, so this explanation will focus on these. Other platforms, especially mobile ones, likely use a different structure regarding the software components.
On a desktop system, a running instance of TeamViewer consists of two components. First off, there is the TeamViewer daemon (or teamviewerd for short). It runs in the background, manages the system configuration, and communicates with the second component, the TeamViewer desktop application. The communication happens via a TCP port that listens on the loopback interface. It is worth noting that there is only one teamviewerd service per system running with root privileges while the TeamViewer desktop application can be started by any user. The desktop application performs the interaction with the operating system (i. e., screen capture, user input, filesystem access) when a remote connection is established, so that the remote session automatically inherits the privileges of the signed-in user.
The TeamViewer daemon is also responsible for enabling the TeamViewer Secure Network, the proprietary encrypted protocol used for transmitting data over the internet. The daemon and desktop application communicate via a different proprietary, albeit mainly plaintext, protocol.
Security Configuration: Where Security Assumptions Break
As stated in the previous section, there is only one daemon running on each machine. This daemon also only operates with a single configuration. This configuration is stored in a protected file on Linux or the registry on Windows. Thus, all users on a system share the same TeamViewer configuration. We noticed this while attempting to understand the TCP protocol and remembered that the configuration contained a number of security-relevant settings. So, we decided to see whether there were any ways we could exploit this design.
Among the settings is the so-called personal password. To understand what it does, one first has to take a look at the default functionality of TeamViewer: A user can share their machine ID and a temporary password with another user, who can then enter these credentials to establish a connection to the first user's machine.
If one now wants to ensure more permanent access to a machine, a personal password can be set in the advanced settings of the application. This personal password can then be used in place of the temporary password that changes regularly.
The fact that such a personal password has been set is not obvious to the user. There is no indication apart from the settings dialogue. This is made worse by the fact that an attacker can also enable another password to prevent accessing the TeamViewer settings altogether.
Any user on a system was able to edit these password settings when running a vulnerable version of TeamViewer. Thus, an attacker could use an unprivileged account to set the permanent password. When an administrator now signed in to the machine, the attacker could use the machine ID and their set password to hijack the administrator's session by establishing a remote connection.
One prerequisite for this attack to work is that the TeamViewer desktop application must be running. It is, however, not untypical to run the application at startup. On Linux, TeamViewer even allowed the attacker to enable autostart for all users.
Suggested Actions
If you are running a vulnerable version of TeamViewer (any version older than 15.51.5), it is best to update to the latest version, which only allows administrators to set the personal password on a machine. Also see the Security Bulletin released by the TeamViewer team for more details on alternative mitigations.
In addition to these measures, we also suggest checking that there are no unwanted personal passwords set on your machine. You can do so by opening the advanced settings of the desktop application.
Responsible Disclosure and Acknowledgements
First off, we want to thank the TeamViewer Product Security Incident Response Team for their cooperation and direct communication. We also thank Jiska for her support during the project.
We initially discovered the vulnerability on January 11, 2024 and used the following days to validate which versions of TeamViewer were affected and compiled our report, which we submitted on January 14. On January 15, we received an initial response, and our findings were confirmed on January 19. We were notified on February 1 that the fix would be released on February 27.
Dirk Knop
