Webroot really needs to implement a better MFA system. Your "security code" is extremely susceptible to keylogging. For a security focused product, it's disappointing you still don't have an MFA system that can leverage the many authenticator apps that are available in the market.
We are constantly looking to evolve our implementation of authentication features, including our 2FA secondary security code. This is under evaluation by Product Management and more information will be forthcoming.
After thoughtful consideration to both the product and customer impact, Webroot also decided to disable agent commands used to remotely execute files. Disabling these agent commands prevents potential misuse in customer environments.
Did this already happen, or is it planned to happen at a specific time? I just logged into the portal and I still appear to have the ability to download and execute files as well as run cleanup scripts and dos commands / scripts. Based on the email I received, I was under the impression that this had already been completed. Based on the seriousness of this attack vector, I am expecting the change to go into effect very quickly.
Personally I prefer that the features remain in place. They are very useful for our business.
The real issue is that Webroot continues to drag it's heels on implementing proper 2FA into the dashboard. I've brought this up with my contacts within Webroot and couldn't get a straight answer.
I'd like to know why this feature has yet to be implemented when it was something that was requested in Webroot forums and feature requests for years and years.
There really shouldn't be any excuse for this for a security company. Even if it was a technical issue, this should have been worked on years ago right through. I'm sure there are some bright minds over there that can implement it.
An explanation as to how secure stored passwords and the "secondary code" are would be helpful. Are they properly encrypted? Are they stored in completely separate locations? etc...
The initial announcement is vague. For Webroot to make drastic changes, the incidents had to be serious. What, specifically, happened? Are you saying that all Agent Commands are going away, or just certain ones? When will the commands be disabled?
The GSM has the ability under Agent Commands menu to issue things like a remote DOS or Registry command to the agent located on a system.
What happened was that credentials for several MSP's were breached and bad actors gained access to their RMM/PSA platforms, they then were able to disable ESET and Webroot and either through the integration of Webroot through those tools or directly into the Webroot GSM, they were able to push a command to download and exectur a powershell script that downloaded a crypto-ransomware variant. (I have a copy of the ransomware and powershell script used in this attack in my lab).
Again the issue is poor credential management/implementation of 2FA across all environments, and not locking down workstations further NOT the actual commands themselves. The MSP(s) were breached and essentially if somebody gains some sort of admin access to a box or admin console, all bets are off and eventually, if given enough time undetected, will be able to find a way to do harm.
By Webroot taking these away, they're further crippling their products ability through the management platform to be utilized to manage endpoints. SentinelOne is an example that they ADDED remote registry, Powershell (remote shell) and DOS ability to their console just recently. NOT removed that capability.
Instead of properly implementing 2FA instead of that dumb code, they take the easier route and remove wanted features that MSP's use.
Webroot needs to tell us WHY full 2FA hasn't been implemented after being requested for years now. Saying the are working on it won't cut it as it's been requested for 5 years now.
The initial announcement is vague. For Webroot to make drastic changes, the incidents had to be serious. What, specifically, happened? Are you saying that all Agent Commands are going away, or just certain ones? When will the commands be disabled?
Thanks for the question,
@DanäHD . Here’s a list of the agent commands that have been disabled:
Download and Run a file
Run a DOS command
Run a Customer Support Script
Customer Support Diagnostics
Run a Registry Command
All other agent commands will remain active.
If you have additional questions or need clarification, please
open a ticket with our customer support team.
After thoughtful consideration to both the product and customer impact, Webroot also decided to disable agent commands used to remotely execute files. Disabling these agent commands prevents potential misuse in customer environments.
Did this already happen, or is it planned to happen at a specific time? I just logged into the portal and I still appear to have the ability to download and execute files as well as run cleanup scripts and dos commands / scripts. Based on the email I received, I was under the impression that this had already been completed. Based on the seriousness of this attack vector, I am expecting the change to go into effect very quickly.
@gpshift & @DanäHD
The changes were implemented last night on the backend systems that invoke these commands. The only commands disabled were the 4 most impactful general ones you mentioned as it relates to where the agent can download and run something. They still show up in the GUI but will not work. This was quicker than recoding the UI, which will be addressed soon and a UI update will be forth coming.
In regards to all other agent commands, they will continue as expected because they're specific to the agent and not general or could be exploited.
Hope this helps
SNIP
By Webroot taking these away, they're further crippling their products ability through the management platform to be utilized to manage endpoints. SentinelOne is an example that they ADDED remote registry, Powershell (remote shell) and DOS ability to their console just recently. NOT removed that capability.
Instead of properly implementing 2FA instead of that dumb code, they take the easier route and remove wanted features that MSP's use.
SNIP
@jhartnerd123 - so, the removal of these commands was for immediacy until additional changes can be implemented. They may be re-implemented at a future date with more tech permission rigor around configuration for JUST those techs that need them can be established. To be frank, the research done indicated a very small percentage of partners actually use them given they replicate the same power with other RMM tools.
2FA has not been ignored and is being worked as part of the larger admin console rework, so watch for more information on that front in the future. I wish I had more info than that, but it's what I know as of this pots.
@freydrew @coscooper Thank you for the details. Do push for real MFA.
5+ years though???? Waiting 5+ years for a admin console rework???? I'm a huge supporter and fan and with that you'll get nothing but honest feedback here.
Being told to wait for the future for 5+years???? Hrmmm.......
Also, how do we now get assistance from Webroot support when we can't issue Customer Support Diagnostics to the endpoints?? Will support now have the ability to do that or is this now something that is yet another manual process where we have to find a way to get to the endpoint and manually run a tool, manually zip them up and since your support portal doesn't accept 7zip or zip format files to upload them there. Has that been figured out???
After thoughtful consideration to both the product and customer impact, Webroot also decided to disable agent commands used to remotely execute files. Disabling these agent commands prevents potential misuse in customer environments.This is part of our ongoing strategic approach to provide additional cybersecurity measures to protect against the evolving threat landscape. We will continue to evolve our product and appreciate the input from our customers.
I understand your decision and caution in disabling agent commands, and I fully support your decision to make sure security is a priority, but could I ask you to please consider the following:
Would it be possible to add the security code or a MFA layer to the agent commands as well, so one has to type a code in before you could submit an agent command? I don’t believe one should disable functionality just because of security concerns, but rather work around it to implement better security with the current functionalities. Reducing functionality is ultimately just giving in to threat actors as they accomplish more than just causing damage, they affect the usability of the product and make life more miserable and inconvenient for MSP's.
I would also like to see
and additional OTP layer for the login that we could choose to use on top of the current security code layer. I like using Duo Authenticator for OTP, but even better, if you could consider implementing Duo Authentication with push authentication, that would be excellent!
Also, there seems to be a new security layer that is popping up called 'phishing phrase'. This is also a great idea and should also be considered to be implemented. The way it works is that one can configure in the Security settings a 'phishing phrase' of any kind e.g. "I love my dog Spot". What this does is, after you log in with your password, the phishing phrase will display before typing in the 2FA code. They idea behind it is, if the phrase is displayed correctly, it's safe to log in, but if the phrase is blank or missing, then something has hijacked the authentication and the login should be aborted.
I would also agree that the current security code is not very good and can be quite frustrating. I would highly recommend to implement Duo Authenticator from Cisco. Implementing Duo push authentication works great!
We are constantly looking to evolve our implementation of authentication features, including our 2FA secondary security code. This is under evaluation by Product Management and more information will be forthcoming.
Can you comment on the request for real 2 factor authentication in a thread or two in this community taking over 4 years? With each year a webroot employee mentioning on how they are "looking into it". Is webroot a security company, or a marketing company?
SNIP
By Webroot taking these away, they're further crippling their products ability through the management platform to be utilized to manage endpoints. SentinelOne is an example that they ADDED remote registry, Powershell (remote shell) and DOS ability to their console just recently. NOT removed that capability.
Instead of properly implementing 2FA instead of that dumb code, they take the easier route and remove wanted features that MSP's use.
SNIP@jhartnerd123 - so, the removal of these commands was for immediacy until additional changes can be implemented. They may be re-implemented at a future date with more tech permission rigor around configuration for JUST those techs that need them can be established. To be frank, the research done indicated a very small percentage of partners actually use them given they replicate the same power with other RMM tools.
2FA has not been ignored and is being worked as part of the larger admin console rework, so watch for more information on that front in the future. I wish I had more info than that, but it's what I know as of this pots.
5 YEARS in the making
Would it be possible to add the security code or a MFA layer to the agent commands as well, so one has to type a code in before you could submit an agent command? I don’t believe one should disable functionality just because of security concerns, but rather work around it to implement better security with the current functionalities. Reducing functionality is ultimately just giving in to threat actors as they accomplish more than just causing damage, they affect the usability of the product and make life more miserable and inconvenient for MSP's.
I agree that adding an MFA layer to the agent commands would be very effective. I mean if a threat actor has acquired access to your MFA then they have dug pretty deep and its pretty much an all bets off situation.
I like using Duo Authenticator for OTP, but even better, if you could consider implementing Duo Authentication with push authentication, that would be excellent!
I implemented Duo Authenticator as MFA on a web based management system this past weekend. It took a few hours to get the existing login code adjusted to allow for addition of the Duo code.
While in the short term I support removing the ability to run agent commands such as powershell or DOS commands, etc.
While I do not use these commands often, there are times they have been useful. I have been able to install an RMM agent remotely using the pre-existing Webroot agent.
Beyond this, I've used the commands with regards to Webroot support requests. That's about it.
I think if there was a TOTP based MFA at login such as Google Authenticator and another request for the current TOTP and or a full re-authentication at time of remote command execution, it would solve a bunch of issues.
Another option would be to have a TOTP MFA with the current security code MFA, but also a second execution security code which would have to be different from the security code, then have they system prompt for the execution security code and current TOTP MFA before allowing execution of a DOS command or downloading and running something.
I do not believe there is any cost to implement Google Authenticator with TOTP other than the time to implement the code changes. This seems to be the most common implementation of TOTP that I have seen.
Just a few thoughts.
Kind Regards,
Chris
Oh and another thought. We have two users on our GSM who are super admin users, all others a limited admins or site only admins. Primarily it is only the two super admin users who would make use of these agent commands, so you could reduce the attack surface by giving only super admins access to run these types of commands.
Please don't globally force disable agent commands used to remotely execute files. Sure, make us jump through 2 or 3 authentication hoops but come on, this is one of the 5 reasons we have been with webroot for the last 8 years.
There are lots of good suggestions here as to an alternative to just turn it off.
This must be a joke. I Just received a mailing from webroot titled ‘NEWSLETTER: What "2FA" Means and Why it Matters’ which points to te following article on the webroot website:
https://www.webroot.com/blog/2017/11/07/two-factor-authentication/
This article is from 2017 and it reads ‘we recommend that you use authenticator apps such as Google Authenticator and Authy.’. So they advise to use 2FA while their own system doesn’t support it that way.
Unbelievable!
Frank.
While I understand the decision to disable agent commands for the time being until proper MFA is implemented, these features absolutely need to be re-enabled once MFA is worked out. Webroot is deployed to our entire client base, and we frequently use the agent commands. MFA has got to be the most requested feature that's gone unanswered for years, and you wouldn't be in this position if you listened to the community and implemented it previously. Unacceptable.
Also, you're essentially punishing your entire client base by removing a core feature of Webroot because of some MSPs oversight. This feature was a huge pro to us for Webroot and one of primary reasons we continue to use it for our clients. However, if this feature is to be permanently disabled, it will be a deal breaker for us and we will begin to look for a replacement AV solution.
.
We are constantly looking to evolve our implementation of authentication features, including our 2FA secondary security code. This is under evaluation by Product Management and more information will be forthcoming.
Please, let's be clear. The Webroot "secondary security code" is NOT in any way a Two-Factor Authentication implementation.
* In reality it is essentially an extended, and overly-complicated, SINGLE password with a slightly-dynamic bit.
* The password is STATIC
* It is all created through the SAME channel
* And, because of the complexity of use, users are sorely tempted to write it down, eliminating ANY security advantage.
I've written this up, including a simple definition of real 2FA, as a Business Endpoint "feature suggestion."
What has been done with this shoot-from-the-hip response is make Webroot Admin more difficult to use, WITHOUT improving the security at all. That's not a win for anybody.
I think if there was a TOTP based MFA at login such as Google Authenticator and another request for the current TOTP and or a full re-authentication at time of remote command execution,
it would solve a bunch of issues.
Personally I prefer that the features remain in place. They are very useful for our business.
The real issue is that Webroot continues to drag it's heels on implementing proper 2FA into the dashboard. I've brought this up with my contacts within Webroot and couldn't get a straight answer.
I'd like to know why this feature has yet to be implemented when it was something that was requested in Webroot forums and feature requests for years and years.
There really shouldn't be any excuse for this for a security company. Even if it was a technical issue, this should have been worked on years ago right through. I'm sure there are some bright minds over there that can implement it.
An explanation as to how secure stored passwords and the "secondary code" are would be helpful. Are they properly encrypted? Are they stored in completely separate locations? etc...
Jhartnerd123 is absolutely right.
Webroot seems completely deaf or monstrously understaffed and overburdened when it comes to the task of feature implementation through community request.
-Temporary disable of Webroot (with password) on an agent followed by auto-enable after a set time.
This one has been out there for eons.
-2FA through legitimate apps such as Google Authenticator, Duo, or even just SAML with Azure AD (allowing Microsoft 2FA). A feature suggestion five-years old that has never gotten more than "We're looking into it", "we're implementing", "it's in progress" with no ETA or timeline. This smacks of a canned NDA response generated between legal and marketing that Webroot support can cut-and-paste into forum threads. It has no teeth. Further, you have punished all of us who are trying to be secure with complex passwords and the PIN codes by removing commands I have regularly used to get recalcitrant endpoints to upgrade to a new version, allowing them to be less secure over time and denying us tools because you haven't gotten your solution together.
-Duplicate workstation reporting and elimination options. This one's been sitting out there, requested by many.
I'm sure there's others, but I'm going to be proposing a timeline to my boss - If I don't actually see a real move to, or a firm ETA on 2FA by Q1 of 2020, I figure it's time to examine our options. I'm hoping Carbonite's acquisition causes some much-needed attention to this process of feature request and development; it is sorely needed.
