Unwanted Customer Persists across every Service Desk - Possible Exploit
I created a new cloud instance so I could begin migrating my company to a different domain name, architecture, etc essentially a restart. I turned on the Service Desk, and finished permissions (company domain access only) maybe within a day or so? Maybe hours - I am not sure.
Once I started creating service desk projects, I noticed I had an inherent customer that was somehow being added (Russian email address) to each new project. The user status (unconfirmed) acts like someone sent them an invite (exploit #1: how was the customer added?) they might accept at any time (Status = invited), but in that limbo status, I cannot remove them (exploit #2: can customers be removed if invited but not accepted?).
The issue is you might not notice the user has made themself a customer, and it appears they would have access to any artifacts available in any service desk that is not further permissioned.
This issue becomes more serious when you consider organizations using the email domain as a means to "permission" customers are essentially running "public" service desks to anyone who has access. That includes users that had access prior to switching to the email domain account creation.
I am trying to imagine how this exploit plays out. Here is one possible scenario:
1. .Ru Person sets up a notification for when a new service desk goes online
2. .Ru Person signs up (or somehow invites themself?) for the service desk while the service desk permissions are still public.
3. .RU Person waits for some amount of time to accept invitation hoping you will a) not notice them in your customer list or b) forget they are there - it appears they cannot be booted in the meantime.
Questions:
- What happens to existing customers using an email outside your acceptable domains once you have put that domain permission in place - are they still allowed access?
- Can you revoke an invite? I was looking into pulling the Service Desk entirely but it looks like the instance stays in place for weeks - so I don't think this is a means to resolve.
Risks:
- If you have IP contained in your service desk, this user has access to it all as they are persisting across all service desks and associated knowledge bases (units you permission them out..
Take-aways:
- Check to see if you have any accounts that fit this scenario. If you only allow for a company domain, this is much easier.
- You can set permissions to remove the user, but try getting that "oh don't worry about that .ru account" past your security team.
Atlassian Input:
I did file this exploit with Atlassian. I like Atlassian, so I am not going to post what was perhaps the most embarrassing series of customer service responses I have ever seen (although completely polite). We went through multiple people and iterations. In summary, I was reporting an exploit, and they would not move beyond the fact that I had submitted it via the new domain I am transferring to (which is where the exploit happened and not an enterprise domain) rather than the Enterprise domain I was transferring from, which apparently has support attached to it (a Standard Plan (for instance?)). Dying to know how people get Atlassian to review possible exploits?! Anyway, absolutely useless, so I am posting here in case the community finds value.