Security is fundamentally broken by the very fact that you require two separate files, host and assignment files. This also applies with the full version where the user is prompted to “Allow and finish”. In either case if the assignment tool fails or is not run, or the user does not click “Allow and finish” then the TeamViewer install is never registered with our account, thus we now have a rogue client which leaves a huge gaping hole.
The issue with TeamViewer really is not about the deployment of the product but how you handle policies in that you are driving policies at the program level when it really should be at the user level. I honestly do not care where TeamViewer is installed if you do not have a login (User management) then you will not get access to any of the TeamViewer hosts.
The install should be simple single file (there should be no host or full version) that is compiled and downloaded from our account that will automatically assign when it is installed. Then a notification is sent to the any of the Company Administrators to be approved or declined and to which group it is assigned to.
Polices and groups are assigned to the user. Policies will define what options that user will have with the TeamViewer application.
The way that TeamViewer is designing things is backwards. You are applying polices to the computer when you are trying to control what the user can do at the computer. This make no sense at all. Computers are dumb controllable objects, users are not. Polices need to be at the user level to mitigate possible user disgruntlement. Currently your setup allows a user to do more harm.
Thanks for sharing your concerns. Please rest assured that there is no breach of security in having two separate files involved in deploying TeamViewer and assigning it to your account. This doesn’t result in any kind of “rogue” client – there is no danger if the client ends up not assigned to any account.
The TeamViewer Host module requires a permanent password to be given to it when it is installed, if the assignment tool doesn’t get used. Normally this password is applied via the TeamViewer_Settings.reg file, and the password is defined by the administrator who is deploying the Host.
Therefore, even if the Host ends up not getting assigned to your account, it is still secure because nobody can connect to it without knowing its ID and password, and the password was defined by you as the administrator. So you can still connect to the Host, but nobody else can without knowing the password. An unassigned Host is still as secure as an assigned Host, in this regard.
For security reasons we intentionally use a two-step process to confirm the account assignment – either via the “allow and finish” prompt, or via the separate assignment tool executable. If the entire process could be done using a single file, it would be too easy for the download link to be given to someone without full disclosure, and that person would install TeamViewer and have it automatically assigned to the account without their knowledge or permission. Therefore we require the assignment confirmation to take place via a separate step.
TeamViewer’s policies are computer-based, rather than user-based, because TeamViewer’s settings are computer-based. This is because TeamViewer runs as a system service, outside the scope of a Windows user account, rather than running as a user process. TeamViewer’s settings therefore need to be system-wide. In that sense, the policies don’t control what the user can do – rather, they control what the computer can do. Could you explain what you mean, when you say this allows a user to do more harm?
You are incorrect. I have already by-passed our own TeamViewer account by not selecting the "Allow and finish" and since there is no way to password the Extra> Options (at least as part of the install) I was able to add this TeamViewer to my own personal account outside of the company and gain access by setting up Grant easy access.
The full version is going to be handed out to our Help Desk staff and if there is a lack of trust then we can assume the possibility of the above procedure. Since there is no TRUE silent install with all options password protected access to our network is easily achievable.
I do not understand how you can think this is even remotely (no pun intended) secure. Help Desk will not have access to download our version of TeamViewer as this is retricted per the setting I have set forth in our account.
I should also add that I do have assigned TeamViewers whitelisted. Free versions are blacklisted. So in this case since I cannot silently deploy either version without the potential of a assignment failure I will not be aware of such assignment failures as my TeamViewer account does not register the un-assgined TeamViewer that I now full control over from my personal account. Security is fundamentally broken!
Next stop, YouTube. TeamViewer, you better listen to this guy. He has a very good, and what appears to be substantial security flaw, point.
I too can do this with ease. It only takes one by-passed commercial version of TeamViewer and all bets are off. Under this scenario someone could easily install hundreds if not thousands of TeamViewer Host throughout the company under a different account. Worse case would be a disgruntled employee installs this scenario on a server or even better an AD server, they would never have any knowledge that this rogue TeamViewer was running in their enviroment. BAD, very bad!
Your feedback is much appreciated and you can certainly rest assured we value you challenging the product. Because this allows us to adapt our documentation and improve the product if necessary.
I understand that you have several tickets in with TeamViewer concerning your deployment of the product. You would like to perform a silent installation utilizing Microsoft Intunes MDM. However, this is currently not supported. Unfortunately, TeamViewer does not support a single file for deployment and account assignment due to security issues.
But let me get back to your point about pass wording the Extra -> Options:
These options will ensure that your TeamViewer is protected, even if the assignment couldn’t be processed successfully.
As for the account assignment feedback, let me offer two scenarios as a solution:
Additionally, you could write a script that scans your network, looking for ID + account assignment values in the registry base. Please note that the use of scripts is not officially supported yet. However, having such an option directly in TeamViewer could be an interesting improvement we acknowledge that.
Should you have any additional questions, please do not hesitate to get in touch with us.
You still do not get it. I have already proven that I can by-pass our TeamViewer account and gain access using the commercial version of TeamViewer. My TeamViewer portal does not register this computer thus I now have a non-free version of TeamViewer and where I have my company whitelisted there is no recourse to block this rogue.
Your process has to many points of failure and scanning the network takes time and resources. Hackers have time on their side, so this is obviously not a secure solution. Keep telling yourself that it is is only going to drive more nails into your coffin.
Backdoor's comments should concern you greatly! YouTube hits the masses at an instant. If he/she was to demonstrate what I have already proven to be a huge hole in your product on YouTube, TeamViewer is going to take another big hit.
Fortunately for me I have a very convoluted process that sill requires very tight controls on deployment, but it works but is far from ideal and still leaves the product vulnerable. User with the full version of TeamViewer can uninstall using Revo and then download the free version and log into their TeamViewer account established by our company bypassing any password protection on the product. With this they can now proxy from another computer outside the company. They could setup a rogue computer tucked away in a closet or desk draw, leave the company and still have access and we would never be the wiser.
The reg export still requires that file be present during installation and in my case Intune MDM cannot deploy more than one file per deployment. USer can still copy the installer from the network share and leave the reg file behind, thus granting them a non-free version of the product.
This is why this need to be a user policy driven product. Grant it there still needs to be an assignment process.
Is there a way to stop TeamViewer from generating partner IDs and password. This might be an option. Currently we do not need the partner ID or password to connect to assigned devices. The host does however prompt to "Show screen". If there is no partner ID and password then this would prevent direct access unless they have account with our TeamViewer portal.
I recieved a pleasent phone call today from TeamViewer. :smileyhappy:
They assured me that a single file installer is on the roadmap for the Host version. This is a MAJOR step forward and I look forward this upcoming feature. This will allow us to do a mass deployment of TeamViewer via Intune MDM, but more importantly this will provide a better experince and security from a deployment prespective.
Thank you very very much TeamViewer. :smileyhappy:
"was able to add this TeamViewer to my own personal account outside of the company and gain access by setting up Grant easy access"
Why is this TeamViewers fault?
By the sounds of it, you have admin access to the machine
And you set up TeamViewer as a backdoor, where it could just as easily have been any old remote control softwware
you can deploy both the host and the assignment tool via intune in silent mode. I know because i did it. Just push the host as you would any msi via intune. Wait a day or 2 for your host to deploy to your endpoints. (slow in our case because of bits bandwidth limitations). After the host is deployed push the assignment tool as a .bat file using the cmd /c command in Intune. When done correctly no end user input or notification of any kind is needed or given.