"Super Administrator" accounts should not be editable by anyone with access to the "User List".

  • 5
  • 13
  • Idea
  • Updated 10 months ago
  • Implemented
Currently, we have two types of "Admin" users in our organization. There are "Helpdesk" users, who's role includes troubleshooting user issues, creating / disabling accounts, and other common tasks. We also have two users with the "Super Admin" role, who manage the system by assigning roles, creating templates, purchasing / deleting phone numbers, etc.

Today, I found out that any Admin user that has the "User List" permission can modify the credentials of a "Super Admin" account. This is something that I consider a vulnerability. No user in any application should be able to, by any method, elevate their own permissions. Currently, our Helpdesk staff, who have the "User List" role, can elevate their permissions by changing a Super Admin's password and signing into their account.

I called RingCentral Support to make sure I wasn't missing something, and they confirmed that this is functioning as intended. They also discussed my concerns with Tier 2 support, and the recommendation I received from them was to remove the "User List" permission from my Helpdesk staff, which would admittedly solve my issue, but would also cripple our Helpdesk's ability to...help users. And I can't put the onus of supporting our 1,000 accounts on TWO Super Administrators.

I also received the suggestion that my helpdesk should have users send their passwords in their help tickets so that the helpdesk agent could sign into the individual users account directly and troubleshoot the issue that way.

I hope it's clear that this suggestion is in no way acceptable. A good IT organization will never need a user's credentials. Taking a users credentials removes any accountability from the IT staff. When an admin makes a change to an account, it should be logged as an "Administrative Action", and while RingCentral doesn't currently log administrative actions (which is an entirely separate issue), I'm not going to start teaching my userbase that sending their credentials to IT is an "okay" thing to do. It's not, under any circumstances, an acceptable practice.

The obvious solution to this issue is that accounts with the Super Administrator role should not be able to be modified by any user that does not also have the Super Administrator role. If you take a look at the way Google implements the Super Administrator role in it's business service offerings, that is exactly what they have done. 

"At least one user in your account needs to be a super administrator, but we recommend having at least two. That way, if one of you forgets your password the other can reset it for you. Having more than three super administrators, however, limits all your administrators' options for password recovery...."  -Google
https://support.google.com/a/answer/2405986

I could keep going about this for ages, but I think I've made my point. This oversight is a vulnerability in RingCentral that should not be overlooked.
Photo of Karim

Karim

  • 908 Points 500 badge 2x thumb
  • super confused by the existence of this issue.

Posted 12 months ago

  • 5
  • 13
Photo of Lee D

Lee D

  • 312 Points 250 badge 2x thumb
I do not have this situation as yet but COMPLETELY agree with this. Users should never be able to change the password of an account that his higher up the security foodchain than their own.  Ever. Ever ever.
Photo of Cecile Glassy

Cecile Glassy

  • 14,314 Points 10k badge 2x thumb
That is a HUGE security risk - RingCentral needs to fix this now.  We have about 14 Admin level and only 4 SuperAdmins which in our organization is a necessity (even though I would prefer to only have 2 SuperAdmins.)  Now we have to change access for all the Admins to a lower level because of this. Not Happy. :< 
Photo of Karim

Karim

  • 908 Points 500 badge 2x thumb
Yup. It sounds like you, like myself, just kind of presumed that this was not the case...because that is literally how the Super Admin / Admin relationship is supported to function, by definition.
Photo of Sarah Gomez

Sarah Gomez

  • 102 Points 100 badge 2x thumb
I super agree with this. No average/basic level user should be able to change anyone's password other than their own. ESPECIALLY higher level users. What's the use of even having levels if that is allowed? 
Photo of Karim

Karim

  • 888 Points 500 badge 2x thumb
Yup. Allowing an Admin to change Super Admin's password is basically the equivalent of allowing a user to change an Admin's password. It's all permission elevation.
Photo of Mike

Mike, Official Rep

  • 89,840 Points 50k badge 2x thumb
Thanks for posting your concerns everyone. We have already forwarded these comments to our Product Team. 

Mike
Photo of Karim

Karim

  • 908 Points 500 badge 2x thumb
Great.
Photo of Cecile Glassy

Cecile Glassy

  • 14,314 Points 10k badge 2x thumb
Thanks Mike - this is generating some super unhappy fur flying here - so the sooner the better that they change that access issue. 
Photo of Eric

Eric

  • 462 Points 250 badge 2x thumb
Mike, if this helps, let your folks know: As you desire to grow the business into larger customers with 1000+ phones and beyond, your customers will be doing a lot of the 1st level support before RC will ever get the call. Thus, setting up Admin users to do repetitive tasks vs. configuration items performed by Super Users is important.  As RC considers the $$ factor in fixing this, your users offload that 1st level of support work so YOUR call center does not have to do it ($ saved by RC).  It's a win both ways, but RC can't just blow this one off.
Photo of Jan Ferguson

Jan Ferguson, Champion

  • 28,950 Points 20k badge 2x thumb
Karim,

Your point was succinct and well put. I agree with you 100%. I have voted for this functionality, as should all who agree with your post.
Photo of Karim

Karim

  • 908 Points 500 badge 2x thumb
I appreciate the compliment and the support Jan. :)
Photo of Elliot Beaudoin

Elliot Beaudoin, Alum

  • 924 Points 500 badge 2x thumb
Hello All,

Elliot here from the RingCentral Product team. 

I understand the ask here, and it makes sense. 

I think we have a feature that would help with this, though it may require some additional up front thought/setup work on your user configuration.

The feature is 'User Groups', located underneath Users (for Office - Enterprise customers only). This feature would allow you to setup groups of users and assign them managers. Those managers then will only see those users for which they are managers in the User List and make changes to only those accounts (based on permission level of course)

One caveat to watch out for is that the standard RC admin roles bypass this "Group Manager" setting. But, if you use the standard RC Manager role, or a custom role, this feature will limit the users they can see. 

I believe this solves the problem, and this use case mentioned here is what this feature was built for. 

I hope this helps!

- Elliot
Photo of Karim

Karim

  • 888 Points 500 badge 2x thumb
So, I want to make a couple of things clear:

  1. Are you recommending that I make a User Group that contains all "Regular" users and one "Admin" user who is marked as the "Manager" for the group, per Administrator? I can do that with a template, and I think that would be an adequate workaround, but, our helpdesk needs to be able to re-assign phones, and from what you're saying, if the helpdesk agents have any kind of admin permissions, the helpdesk agent will not be able to see the accounts they are deligated "Managers". (Full disclosure, I didn't test this, but I think that's what you were trying to point out with your disclaimer). Also, before it's mentioned, no, giving a helpdesk agent two account, one manager and one device admin is absolutely not an option.
  2. While I appreciate the presentation of a workaround, which honestly might be a valid one for some other  you didn't address my root concern. Does RingCentral recognize that the relationship between Super Administrators and Administrators is not implemented correctly in the product, or will the relationship continue to exist in it's current state?
I appreciate your quick reply on this, and hope we can continue to have a productive conversation regarding this issue. :)

Thanks!
Photo of Cecile Glassy

Cecile Glassy

  • 14,314 Points 10k badge 2x thumb
Hi Elliot

That leaves all other RingCentral customers who do not have an Enterprise account - still with a gaping security hole.   Whomever is in charge of vetting security settings in DevOps must be aware that this is NEVER a best practice --- the reason for having any SuperAdmin role in any software or hardware implementation is never to share that level of access with an ADMIN role which is always in hierarchical order less rights than a SuperAdmin. This is Computing 101.   Basic and Standard accounts do not even have customizable ROLES enabled and thus - do not even have that level of control.   
(Edited)
Photo of Eric

Eric

  • 462 Points 250 badge 2x thumb
Since those are at the same permission level, that should be fine, but I don't want to speak for Karim.
Photo of Karim

Karim

  • 908 Points 500 badge 2x thumb
I 100% agree Eric.

A Super Admin should absolutely have the ability to modify any aspect of another Super Admin's account, including password resets. Like Eric said, this does not lead to an elevation of permissions, and allows for Super Admins to support each other in the case that the need arises, like when one forgets their password, or leaves the organization and needs to be disabled.
Photo of Cecile Glassy

Cecile Glassy

  • 14,314 Points 10k badge 2x thumb
In all other systems, usually any user with lower level rights cannot view details of SuperAdmin.  It should be done according to IEEE standards for password/access/view privs/etc.  SuperAdmin can view and edit each other, and all users with lesser rights. 
Photo of Elliot Beaudoin

Elliot Beaudoin, Alum

  • 924 Points 500 badge 2x thumb
Cecile, that creates an interesting new use case for us. In 9.3, we are going towards a master / detail type view where you can flip through the users and see their details without being taken away from the grid. Maybe we can allow viewing the grid column info, which is basic, but then lock down the panel and all CTAs for that record. 

Quick question for all, seems like this would be an issue for Billing Admin users as well? 
Photo of Karim

Karim

  • 908 Points 500 badge 2x thumb
Hope you had a good weekend Elliot.

Yes, it does, and it's good that you point that out.

In my head, the ideal solution to this would be a "flag" you could tick on a role that would restrict the accounts belonging to that role form being edited by those with the Super Admin role.

I was just focusing on the built in "Super Admin" account because the relationship between that specific account and any other administrative user is most likely assumed to behave a certain way, and if that assumption is wrong, it could lead to issues.

Thanks.
Photo of Cecile Glassy

Cecile Glassy

  • 14,314 Points 10k badge 2x thumb
So making sure I understand how to protect our security, the only option I have for the foreseeable future is to re-assign every Admin to prevent their access to change password on SuperAdmin.  Then move all 2060 of our users to a "group" and make the former Admins re-assigned as Managers of that group?   At a time when we are onboarding a huge volume of new users for August 1st, this is not an acceptable solution for use of my time. 
Photo of Eric

Eric

  • 462 Points 250 badge 2x thumb
100% agree with Karim and Cecile.  I have not tested this myself, but assuming the above is correct, the workaround may work, but instead of RC coding the tool properly and following Security Best Practices, "Please extend your workload 5-fold so we at RC don't have to do anything. Blackhat is this week in Vegas, I hope whoever at RC is there, should come back demanding this be fixed.  Like yesterday! Major security issue.
Photo of Karim

Karim

  • 908 Points 500 badge 2x thumb
Amen.
Photo of Karim

Karim

  • 908 Points 500 badge 2x thumb
Did this get marked as implemented by accident? This is not resolved by any means.
Photo of Cecile Glassy

Cecile Glassy

  • 14,314 Points 10k badge 2x thumb
It must have been an accident - I sure hope so. Agreed it is not resolved. I have attempted to escalate this through additional RC channels.
Photo of Elliot Beaudoin

Elliot Beaudoin, Alum

  • 924 Points 500 badge 2x thumb
Changed to Under Consideration. See my recent comment in response to Karim. I think if we can agree to a simple set of rules quickly I can see about getting this prioritized. 
Photo of Chris Duquette

Chris Duquette, Champion

  • 13,132 Points 10k badge 2x thumb
this seems like a standard "class of service" style problem, if im a receptionist, i shouldnt be able to edit the CEOs level of access or info. thats preety basic, i realize the original analogy fits better, but people and user at the bottom or middle of the totem pole shouldnt be able to mess with admin settings unless given the permissions. i mean you have to give other users permissions to answer your call or see your presence, why shouldnt i have to grant access to edit a super admins password? that seems like it shouldnt be anything thats available right out of the gate and stumbled upon when its too late.  
Photo of Elliot Beaudoin

Elliot Beaudoin, Alum

  • 924 Points 500 badge 2x thumb
Hello,

I have an update on this item. I am flipping the status to planned on this one. 
In one of our upcoming product patches, in order to secure Super Admins from non-Super Admins we will:

  1. Only allow users with Super Admin roles the ability to edit other users with Super Admin roles. No changes at all should be possible. This also applies to templates and bulk actions.
  2. We will allow non-Super Admins to view Super Admins in the User List if they have permission, but On Save, we will give the a user an error message saying that they can't edit that user because they don't have the Super Admin role. The ability for non-Super Admins to see Super Admins in the User List is something we are considering changing in our long term approach to this problem. 
  3. We will prevent a non-Super Admin user from assigning the Super Admin role to any user.
Thanks for your patience on this, and I hope this helps in your day to day duties. 

Have a good weekend. 

- Elliot
Photo of Cecile Glassy

Cecile Glassy

  • 14,314 Points 10k badge 2x thumb
Thanks Elliot to you and your team - this is great progress. Thank you to the DevOps dept. for listening to your users!  This is a good start - I hope the further security enhancements several of us have detailed will be integrated soon.
(Edited)
Photo of Elliot Beaudoin

Elliot Beaudoin, Alum

  • 924 Points 500 badge 2x thumb
Hello everyone here, 

Just a quick update. Most of you have already seen this, but in a few of the recent updates we've closed this security concern regarding Super Admins. 

- In the first update to 9.2 we gave the non-Super Admin a notification that their changes would not be saved because they did not have access to update another Super Admin
- In the most recent update to 9.2, we removed the Save buttons for non-Super Admins when they are viewing Super Admin users

I am switching this post to Implemented.

I hope to see everyone in a few weeks at ConnectCentral!

- Elliot
Photo of Karim

Karim

  • 888 Points 500 badge 2x thumb
Music to my ears sir, thank you and the team. :)
Photo of Cecile Glassy

Cecile Glassy

  • 14,314 Points 10k badge 2x thumb
Thanks Elliot for carrying this forward - a lot of us are grateful!