Site icon Martin Haller, A blog about corporate IT protection and management

TeamViewer: 4-Year User Review (Part 2/2)

martinhaller
TeamViewer

In my previous work I started to share our experience with TeamViewer (part 1/2), which is our primary tool for remote user support. We have been using TeamViewer since 2015 when we moved from LogMeIn Central. In this work, I will go through what does not suit us. And I will describe how we set it up to be as safe as possible.

Things we don’t like

We are happy with TeamViewer. It does not mean, however, that we absolutely love it. Which things have been the most troublesome over the years?

Bugs

TeamViewer, like any other SW, is not bug-free. Some of them have been troubling us for years, and they will probably never be resolved. For example, policies sometimes choose to not to deploy (we need to remove them from the device and reassign them + this can only be done when the device is online). Easy access sometimes does not work (then we need to re-share the whole group again). These things piss us off mainly because we are in charge of many devices (that is they are more frequent) and the repair costs us a lot of time (which no one will pay). However, we have not experienced bugs in terms of basic functionality.

It sometimes happens that a cloud crashes and it is not possible to connect to the device (see TeamViewer Alerts, TeamViewer Uptime).

TeamViewer tech support

Although we buy the “highest” Corporate license, and the TeamViewer price continues to grow, there is not much support. They are nice but only deal with things you can find solutions on their own site. They know about the above-mentioned bugs and are working on them (for a few years already), but the results are none.

Solution penetration

TeamViewer is our core tool. That’s why I was looking at how secure it is to know that it’s well designed and that we can trust it. The only thing I found and what I was told about from the support are things at the TeamViewer Trust Center. It is not very detailed. 🙁 I still do not know if “random/personal password” is verified at the target device or TeamViewer servers? How about “easy access”? In theory, easy access could be less secure. Could TeamViewer servers can send arbitrary commands to clients? In this case, compromising TeamViewer servers would mean compromising clients as well. How about a public/private key for user accounts? Are there, or are they used by the computers where you are currently logged in use?

They use the RSA 2048bit, which says as much about security as the photo below – a good basis, but it does not mean that the whole is properly secured. 😊

Picture 1: (Photo: Mitchel Haindfield/flickr)

The “master” account principle

If you buy a “multi-user” license or higher, you have a TeamViewer management console available, and there is an account for your company. All user accounts, policies, and associated devices are then associated.

Logically, it would make sense for anyone from your business to assign a device under your business so the device will be under the business and manageable (renaming, deleting, changing policies, sharing onwards) by an account with the appropriate rights. Unfortunately. it is not so. All devices that are assigned to the company, created groups and policies are under the account management that has assigned/created them. And that is the only one that can change them (except renaming/deleting the device).

The above limitation puts greater demands on managing the TeamViewer account. You need to plan everything and create all objects and add devices under one account only. Which brings us to the problem that all people must know the credentials of this account so they can assign the device to that account. Fortunately, with new versions of TeamViewer (Host 13.2+, Full 14.0), you can also assign a device without knowing the login credentials of that account (see “Assignment with the TeamViewer executable“). Learn more about the master account issue with “Using a Master Account for the TeamViewer Management Console“.

A mix of old and new versions

Sometimes a third party needs to connect to a PC (for example, support of the information system manufacturer). The problem occurs if you do not license the latest version of TeamViewer. TeamViewer must shut down and run an older version on the PC. Because 2 different versions can not run simultaneously on one device. This process delays and does not allow the device to connect at any time. The only solution is to install an older version of TeamViewer. But again, it is a matter of concern to us, because the older version sometimes lacks functionality and makes exceptions to our standardization.

I often encounter the fact that the company bought TeamViewer a few years ago and does not want to upgrade it to a newer version because it costs money. I understand this with internal IT departments that only support their colleagues, so they use a unified version of TeamViewer throughout the company. But I’m not very excited about the fact that old versions are being used by companies in the IT industry to support their customers – it makes life more complicated for all parties. It is not a good way to save on a primary work tool.

However, since there are only licenses in the form of subscriptions (that is, you always have the latest license), this problem will resolve itself over time.

Security

The correct setting for TeamViewer is critical for us. It is can be used to access all of our customers’ computers. By compromising it, all of our customers’ computers could be compromised (Tier 3 in my article Network Security: Tier Model and PAW).

TeamViewer has 3 security flaws in a database. It was misused to steal funds from the PayPal account in 2016. But it was not TeamViewer´ fault, but rather of users who had poor passwords to access their TeamViewer accounts. Since then, TeamViewer has increased security. Improved protection against brute-force device attacks, increased the default length of the random password and introduced mandatory 2FA (at least in the pre-validation version of the device via an e-mail message). More at TeamViewer Trust Center. However, I still consider it important to not to poke any security holes due to its poor security.

We at PATRON-IT have set it up as follows:

User accounts

Each of us has our own TeamViewer account. Which is important for auditing (who has accessed what), communication with customers (customers know who is connected to them), different entitlements we have with colleagues, and the groups we share with each other.

Two factor authorisation (2FA)

It is important that no one gains access to our TeamViewer accounts because other security measures rely on it. This is why we have 2FA turned on for all accounts.

Even if we have active 2FA, none of us can sign into TeamViewer on other than our work stations (see “Network Security: Tier Model and PAW“). The reason is that if one has logged into TeamViewer with the “stay logged in” option ticked on a foreign computer and then did not log off – the owner of that computer would have access to his account.

If you choose to turn on 2FA, you can safely save the “recovery code” in case you lose the second factor. Otherwise, you will never reach your account. Even with TeamViewer help. Own experience. 😊

Where to not to install TeamViewer

TeamViewer is mainly a tool for user support (ie, stations). We do not use it for server administration and we do not install it at servers at all. In fact, our monitoring system monitors whether TeamViewer is not installed at servers.

Servers are more important to us than a station in terms of security (see “Network Security: Tier Model and PAW“). As for TeamViewer security, I’m not 100% sure of it. It’s mainly because of the Solution Penetration and attitude of their technical support (see above – things we do not like at TeamViewer). In the future, some RCE (remote code execution) or “local privilege escalation” error may occur. So, within the limitation of risk, we simply do not give TeamViewer the servers. We do not need it anyway. 😊

Remote access without password

When you are connecting to a remote device, you have more options to check to get verified by the device to connect. In summary, this is described in an article on TeamViewer “All about passwords“. Our experience below:

The user must confirm that you can connect to it. We do not use it.

After each connection (may be fixed, depending on the setting) a new password is generated. So, if you wish to connect to a device, someone has to dictate it. This means that you can not connect to the device arbitrarily.

We have random passwords mostly deactivated. And so that users can not (un)consciously let anyone else into their PC. 😊

This is any password you define that you can use at any time to connect to the device. The password is not “readable” on the target device and therefore cannot be misused by anyone to whom you will not say it.

It is also worth mentioning that you can have more personal passwords on each device. e.g. when another company joins a part of the equipment, you do not have to pass on your personal password, but you will create their own.

The disadvantage is that you will not change this password in bulk (for example, when it is revealed).

You can also enter the login information of a local or a domain user who has the right to join the PC. We do not use this option and we have a policy blocked effectively on our devices. Especially in Active Directory environments, it seems to me that accounts that can log on to a device are more than desirable. 😊

Allows us to connect to a remote device without any password. Login will be based on your TeamViewer account. E.i. the TeamViewer account to which the device is assigned is assigned to the remote device. Or TeamViewer accounts are shared. TeamViewer recommends this method because they consider it safe. There are no passwords that could be revealed and one has to worry about. Up to the login information for your TeamViewer account. This method also makes sense and we slowly move on to it everywhere.

Policies

Policies are great! We have the same settings on all devices thanks to them, and users can not change it.

Overall, we have 3 policies that vary according to security. We always try to put the “strictest” option onto the customer. Our policies are:

Apart from the above, our policies and other settings are included. Among the useful choices that you should have a look at certainly include:

Monitoring system connection

TeamViewer is also linked to our monitoring system. It checks that we have it installed on each managed device, that the device is properly assigned under our TeamViewer account, that it has applied policies and an up to date version of TeamViewer. Exactly in accordance with the fact that we can see all the information about the state of our customers’ environment in one console.

Similarly, we read through the API TeamViewer Management Console information about when the device was last online and compare it against the last time the ESET SMC has seen it online. Such a “cross-check” to know that no system is cheating us. It happens more often than you would expect. 😊

Conclusion

I would like to share so much interesting information with you. But the article is quite long now. That’s what my colleague Lucka has cut out a lot of sentences. 😊

Please ask if you have any questions after reading. I will be pleased if you would share your experience with TeamViewer below.

For better IT environment ✌

Martin Haller

Do you like topics, I write about?

It is not necessary to periodically visit my blog to check if there is a new article. Subscribe below for notifications. You will be the first one who will know about new article.

Exit mobile version