Possible access security issue
![[Deleted User]](https://w2.vanillicon.com/v2/24d2a9911b483093b876c0adf7b7a1f2.svg)
In my previous post, I asked how non-Admin members of the recovery group were supposed to start the recovery process without access to an Admin page. So far, it appears that the docs are lying (or the application is misbehaving).
Today, I tried to force the hand of 1Password (so to speak) by logging into my team as a non-admin member of the Recovery Group and pasting the URLs for various sensitive pages. In theory, a non-admin user who is a member of the Recovery group should have access to a page to start recoveries but have no access to information about other users or the team itself.
In practice, I find that 1Password does not present any UI to initiate recoveries but blithely displays other admin pages to the user when asked. There are no menus or buttons to access them, but pasting the URLs works, which allows this user to access, amongst other things, a list of my logged-in machines, a list of all team members, a list of pending invitations, etc. This even extends to administrative URLs like /admin/settings, which has been designated as the repository of billing and plan information at the end of the beta!
The pages come up with all the controls, buttons, and toggles that a bona-fide admin would see. The controls I tried failed to save any information (even though the UI itself works as expected), but all the information was readable enough… Some pages, like /admin/vaults did properly display the user's vaults (and not all vaults) but other admin pages have no business spitting out their contents to every Team user.
I am positive that AgileBits has the cryptography aspect well in hand, but have the Web App and the admin flow been tested at all? With such big issues affecting recovery and authentication, one wonders about the product as a whole…
Comments
-
Hi, @Deleted User. Another great post! Someone left all the good ones for me. :)
You are correct, we have a lot of work to do on some authorization issues in the web app. You're also correct that vault contents are safe and performing of actions is still restricted, but the display of information needs to be reigned in a bit.
There are two sides to this, the front end and the back end, and both need changes. I can easily change the pages to redirect if the proper permissions are not met, and I'll do that, but if the server still sends the information, it's just a cover-up. So we've been working on an overhaul to our authorization model that will better restrict what information the server provides to the client. It's been in progress for a little while now and it's nearing completion from what I can tell.
In the mean time, I'll get an issue open for the client-side issues and see what we can do there.
Thanks again!
ref: B5-1124
0 -
Hello, @rob! Do thank this person for me, since they, in turn, left me with the best possible support specialist. ;) I appreciate your writing during the week-end, and to such great lengths at that.
I am a little concerned that the web application was allowed to ship with such obvious permissions issues but, as long as it is both known and essentially cosmetic, we can live with it temporarily. Data leaks within a team are a genuine matter for concern, but they are not quite in the sky-is-falling category. (Still, we expect much better from AgileBits, or we would all have LastPass accounts and rejoice in their approximate security.)
Have you planned to have the web app audited afresh before entering production? I keep reading about big changes being planned to it and surely the initial pre-Beta audit cannot cover these deep alterations to the code…
It may be preferable not to artificially redirect the pages when the user is not authenticated. As you point out yourself, it is a cosmetic measure that can be easily bypassed, and it may give developers a false sense of it being done already, or being not quite urgent. It's probably best to keep it as-is, with the warts somewhat obvious, until a proper fix is implemented.
0 -
I was working on this issue in the past few days. There are a few places where server should return less information for non-Admin users. I am going to make this change in the next update.
However, the access to admin pages will have to be controlled by the web app. This is because the server still has to return the full list of team members and groups to all users.
0 -
As long as the web app cannot be tricked into displaying more information than it should by entering URLs (which is the case at the moment) or fiddling with JavaScript parameters, I am sure all will be well. :)
My comment above was essentially meant to say that I feel it is better not to bring about cosmetic changes, for example by hiding controls away from view while they remain available in the source code of the page that is being served.
This is similar to the age-old bug whereby web apps issue a redirect to the browser but continue to serve confidential information to malicious agents that stay on the page and keep receiving data. The only proper behaviour for a web app, of course, is to refrain from outputting information it should not, and forego all reliance on "soft" protections. But you know all this.
0 -
Do thank this person for me, since they, in turn, left me with the best possible support specialist.
@Deleted User, you're too kind. :)
Have you planned to have the web app audited afresh before entering production?
Yes, we will be having more security audits, and we plan to schedule them regularly.
It may be preferable not to artificially redirect the pages ... it may give developers a false sense of it being done already, or being not quite urgent.
It's a good point, but we do plan to fix both sides of things, so I'm not too concerned which side gets done first. Both are hidden from most users since the only way to get to the pages is by knowing the URL.
My comment above was essentially meant to say that I feel it is better not to bring about cosmetic changes
Yep, cosmetic changes are needed, but they won't be the only changes. Roustem was concerned I was shifting too much weight to the back end. While the back end will be improved, the front end should avoid displaying admin pages even if there is no sensitive information (devices, group memberships, billing info) available from the server.
0 -
Hello @rob,
We will be having more security audits, and we plan to schedule them regularly.
In the light of my early experiments, this is very reassuring. I am glad that provisions have already been made for regular third-party audits and hope the first is carried out without undue delay.
Both are hidden from most users since the only way to get to the pages is by knowing the URL.
From most users, without a doubt… Still, when trying to protect against malicious actors, whether internal or external, one should not place any trust in the knowledge, or lack thereof, of most users. Most of the URLs mentioned in my initial post are actually quite straightforward. For example, it would not take an evil genius to guess an address such as
/admin/settings…[E]ven if there is no sensitive information
All information stored in 1Password is possibly sensitive and should probably be treated as such, including the Metadata. Avatars, vault names, even user names all contain possibly sensitive information in certain contexts… Your biggest competitor right now appears to be 1Password with Dropbox which, as far as we know, is a pretty ironclad solution…
This reminds me of the earliest versions of 37Signals' Basecamp. The app was designed on the assumption that all users, belonging to a closely-knit group of collaborators, were more or less all chums, and this gave rise to interesting security incidents over time, especially with regards to the leakage of administrative information. Nothing major, but it was interesting to note that the "New Basecamp," which is now being sold, was developed from the get-go without any such assumptions. I would urge you to remember that most threats come from "inside the house"! :pirate:
0 -
Still, when trying to protect against malicious actors, whether internal or external, one should not place any trust in the knowledge, or lack thereof, of most users.
@Deleted User, sure, I didn't mean my comment to imply a naivety toward malicious users, only that the cosmetic changes won't really make a difference to "most users" (who won't see the pages unless they're trying) or malicious actors (who don't care about the pages if they can get the info from the server).
All information stored in 1Password is possibly sensitive and should probably be treated as such, including the Metadata. Avatars, vault names, even user names all contain possibly sensitive information in certain contexts…
So, I'm not sure how far you're going with this, but as Roustem said, "the server still has to return the full list of team members and groups to all users". This allows us to show who last changed an item, along with other things.
We are defining what we consider to be sensitive and what we don't. Group names, user names, and avatars are not considered sensitive within the context of a single team and thus should not be treated as sensitive. They are things that are needed in different parts of the user experience. Vault names, on the other hand, are encrypted along with vault contents, so only those with access to a given vault can read its name. (This means we don't even know any vault names.)
0 -
The server still has to return the full list of team members and groups to all users
I'm not sure I agree — but of course, this is not something I have any say about.
Does Employee T, the telephonist, need to know about Employee L, in the secret lab? If Employee T is a member of the Recovery group, yes, she does, because she needs to be able to locate Employee's L account to initiate the Recovery. Otherwise, unless they both belong to the same vault, which supposes they have some business in common, there is no reason why they should know about each other. Ergo, there is no reason why the web app should ever tell one about the other…
I'm not sure I quite get @roustem's meaning — by which I do not mean that he is wrong, but rather that I think we place different meanings on "server" and "web app." Since I'm already being a total pain in another thread about the woefully insecure storage of Documents, I did not want to press my luck and get him hopping mad at me.
I'm not sure how far you're going with this.
While I would have gone further than you appear to have in terms of what I would consider sensitive information, what you describe makes perfect sense. Thanks for the heads-up! It might be good to add tips to the interface to remind users that avatars and user names will always be seen by the entire team, as an extra precaution. Something discreet during the account and vault creation processes would probably do the trick.
0 -
Hi, @Deleted User.
Does Employee T, the telephonist, need to know about Employee L, in the secret lab?
You raise a good point about identities of certain team members remaining secret. It's not something we're prepared to address at this time. For now, if that were an issue, we would suggest making a separate team for your secret lab employees. :)
I think we place different meanings on "server" and "web app."
Roustem used the term "web app" to refer to the HTML and JavaScript client that is delivered by our server when you request https://someteam.1password.com. The delivered JavaScript is actually in charge of all the pages. There is no HTML delivered from the server after the first page load. All the page URLs are handled by a JavaScript router that changes what is displayed on the screen, but clicking a link does not necessarily make a call to the server (unless that page will need additional data).
So when we talk about preventing access to certain pages, that's going to be a client-side, JavaScript limitation, rather than a route that the server determines is not authorized.
It might be good to add tips to the interface...
Yes, we should probably add more info there. We'd like to do that around the app for other things as well. I'll open an issue. :)
ref: B5-1140
0 -
I have fielded customer requests for what the INFOSEC community calls "Red / Black" processing where the Red team has lower security than the Black team. The usual approach, in that instance, is to have two separate systems. It's usually far easier to administer two separate systems than it is to manage the various sensitivities and labels that would have to be managed. Consider an instance where a Red team and Black team member are both in the same vault. What does the Red team member see for who last modified an item when the last modification was performed by a Black team member? I have worked on Multi-Level Secure (MLS) operating systems and getting the compartmentalization correct is often rather challenging, for both the developers and the end-users.
0 -
Are you by any chance a Bond girl, @julie-tx? Or maybe Bond himself working undercover? You are perfectly right, of course, and I thank you for the extra insights. :)
I look forward to seeing the access errors in the current web app resolved with an update, as well as better behaviour for the Recovery group and its UI. In the meantime, the theory that informs it all is certainly impressive, and it is reassuring to know that a team of such value is working on keeping our information secure!
0 -
I wrote secure operating systems for 20 years and led 4 different secure operating system evaluations, including one MLS evaluation. And that's all I'm cleared to tell you :)
0
