PulsePost-mortem: unintended automatic joining of a workspace
The background to, and response to, an event caused by how organisation domains were handled.
This is a template for publishing a security event. Where an event is found to have affected users, UNCHAIN, Inc. publishes the background, what was done and who was affected, and thanks whoever reported it. When publishing an actual event, we use this structure: summary, how it arose, what we did, who was affected, preventing recurrence, acknowledgements, further reading. What follows is a worked example. Dates, reporter names, numbers of people and items, and version numbers are left as placeholders, to be replaced with the real values on publication. Where a third-party supplier is named, agree it with them before publishing.
Summary
Pulse workspaces have a setting that lets users with the same email domain join automatically. Because that decision was based solely on a match of the email domain received from the external identity platform, an account that was not managed by the organisation could join that organisation's workspace as long as the domain matched.
Following a report from a user, we investigated and applied a fix requiring confirmation that the account is under the organisation's management, in addition to the domain match. Our investigation found no case of an unmanaged account actually having joined a workspace.
| Item | Details |
|---|---|
| Affected | Workspaces with “allow users on the same domain to join automatically” enabled |
| Date reported | Please contact us |
| Reported by | [reporter name] (reported by a Pulse user) |
| Date fixed | Please contact us |
| Instances of an unmanaged account joining | None found |
| Action needed by users | None |
How it arose
This event arose because the automatic-join decision was made solely on a match of the email domain received from the external identity platform. The assumption that an account with a matching domain must be managed by that organisation did not match how the platform actually works.
Background
| Date | What happened |
|---|---|
| Please contact us | A user reports the behaviour. It is shared on the internal security channel, and engineering and support begin reproducing it |
| Please contact us | We search production data and confirm there is no case of an unmanaged account being a member of a workspace |
| Please contact us | We confirm that the external identity platform no longer issues unmanaged accounts of this kind, while existing ones remain valid |
| Please contact us | We analyse the impact and identify the gap in the default automatic-join decision |
| Please contact us | The fix is verified and applied. Production data is searched again and no impact is found |
| Please contact us | The user who reported it is told the response is complete |
| Please contact us | This post-mortem is published |
Direct cause
The external identity platform used to permit the creation of personal accounts that had an email address on an organisation's domain while not being under that organisation's management. Pulse's automatic-join decision treated a matching email domain as meaning “a member of that organisation”, without checking whether the account was under the organisation's management.
The underlying understanding — that holding an account on an organisation's domain means being managed by that organisation — did not match how the platform actually works.
What we did
| Date | What was done |
|---|---|
| Please contact us | Searched production data and confirmed there was no case of an unmanaged account being a member of a workspace |
| Please contact us | Added confirmation that the account is under the organisation's management to the automatic-join decision, on top of the domain match. Unmanaged accounts can no longer join automatically |
| Please contact us | After applying the fix, searched production data again and confirmed no users were affected |
How we investigated
We searched the membership lists of production workspaces for users who had joined with an account not under the organisation's management. We ran the search twice, before and after applying the fix, and on neither occasion was there any such user.
Who was affected
- Those that could have been affected are workspaces with “allow users on the same domain to join automatically” enabled. Workspaces with that setting disabled accept members only by invitation and were outside the scope of this event.
- Within the scope of the investigation, no unmanaged account was found to have joined a workspace. Nor was there any evidence of data being accessed in any workspace other than that of the user who reported it.
- No action is needed by users.
Automatic joining on a domain match is convenient for spreading use within a company, but an organisation cannot necessarily control exactly who is able to join. For workspaces handling notes from sensitive meetings, consider disabling automatic joining and accepting members by invitation only. Where the setting lives is explained in Workspaces.
Where personal data is leaked, lost or damaged, or there is a risk of that, the nature of the case may make it necessary to report to the Personal Information Protection Commission under Article 26 of the Act on the Protection of Personal Information (a preliminary and a final report) and to notify the individuals concerned. The situations that must be reported are set out in Article 7 of the Enforcement Rules, the reporting deadlines in Article 8, and what must be notified to individuals in Article 10. Because the situations set out in those Rules include cases where there is a risk that something has occurred, it is necessary to consider whether the data was reachable even where no record of actual access can be found. In this worked example, no instance of an unmanaged account joining was found, so we treat it as not amounting to a leak.
This page is published as something UNCHAIN, Inc. does of its own accord. No law generally requires private businesses to publish security events. The obligations that can arise in law are reporting to the Personal Information Protection Commission and notifying individuals under Article 26 of the Act on the Protection of Personal Information; reporting a leak of the secrecy of communications where registered as a telecommunications carrier; and notification under contracts with corporate customers.
Preventing recurrence
- Making the conditions explicit — automatic joining is now limited to cases satisfying both a match of the email domain and confirmation that the account is under the organisation's management.
- Identifying assumptions about external behaviour — we identified the places where we make implicit assumptions about how the external identity platform behaves and checked them against how it actually works.
- Revisiting defaults — we revisited the default automatic-join setting for newly created workspaces, and the explanation given to administrators.
- Making the user reporting route known — we set out a procedure ensuring that security reports from users reach the internal response channel.
Acknowledgements
Our thanks to [reporter name] for their responsible disclosure, and for helping us reproduce the behaviour and confirm the fix.
Further reading
- Vulnerability disclosure policy — the scope of permitted research, how to report, and how we respond to reporters
- Workspaces — the automatic-join setting and managing members
- Our security arrangements — the technical and organisational safeguards in place day to day
- Enquiries about this matter: tharada@the-unchain.com / vulnerability reports: tharada@the-unchain.com
Where the reporter or an external researcher has published technical information, link to it here. Agree with whoever published it whether and when to include it.