Hi,
We just learned that any service desk user after registering can generate a token for a connect app plugin by opening a special page:
https://{instance-name}/plugins/servlet/ac/{plugin-key}/requirements-page-jira?classifier=json
First of all, is this really a wanted behavior (that any Service Desk user can potentially access a Jira Cloud plugin)? Is there any way to restrict the token generation only to Jira Users?
Second of all, it seems that the subject (sub) in the JWT tokens for Service Desk anonymous users are always in the format
qm:{something}:{something}
Apart from some related bugs in the community, I couldn’t find any official documentation about the format of the subject in JWT tokens. Can anyone confirm that the subject in the JWT will always start with qm: for Service Desk users?
Thanks in advance
Hi,
Why do you think token creation should be restricted?
Because of security. Putting in other words: Why does an anonymous user needs a token for a plugin which is only accessible inside of Jira?
Yes, but what if the plugin doesn’t implement any Service Management module. Why would a Jira Service Management user need to have access to a Jira Software plugin API?
And regarding my second question: Can I identify a Service Desk user by the prefix qm: ?
Hello Bruno
Can you please provided a detailed explanation of how any user’s self-generated tokens are a ‘security issue’.
Please describe the specific method and a proof of concept scenario whereby that user would use the token they generated in combination with a connect app or plugin to compromise Jira, and to what extent.
Thanks,
Dear @sunnyape,
Thanks for getting back on it. The problem really depends on how the plugin is programmed, but most of the Connect plugins will have an API to read/write plugin-related data. These APIs fully rely on Jira-generated tokens to grant access to it.
Any anonymous user can generate a token and, therefore, access the API. You just need an e-mail account and register on Service Manager and generate this token.
For me, the security issue is very clear: Atlassian grants access to all Connect Plugin APIs to anonymous users and there is nothing that the plugin manufacturer can do about it.
Unless you tell me: yes, all Service Manager user account ids start with “qm:”, then the plugin manufacturers can simply block these users from accessing the API without overloading every single API call to an additional call to the JIRA Cloud asking for the user permissions.
@BrunoMarotta
I was not aware that a token randomly generated by an anonymous user could somehow be used to access a random Connect plugin. I’ve always believed that the plugin had to use a specific token, which it was responsible for requesting from the user, and that the user had to approve the requested, and that app to token binding relationship was unique.
In the way you describe it, this randomly generated user token can be used as some form of ‘skeleton key’ that can be used to ‘unlock’ the use of any Connect apps, arbitrarily.
Have you done testing to confirm this security vulnerability with the user token can actually be accomplished, or are you just making a hypothetical speculation?
@sunnyape : Just check my first message. It is not a randomly generated token, nor a random Connect plugin. It is a token generated by a malicious user for a specific plugin.
Assume a Cloud Jira instance with Jira Service Manager installed and a given Connect plugin installed. By default all Cloud instances are public-facing.
Steps to reproduce the vulnerability are:
-
Create a Jira Service Manager account. All you need is an e-mail.
https://{instance-name}/servicedesk/customer/user/signup
-
Open the page
https://{instance-name}/plugins/servlet/ac/{plugin-key}/requirements-page-jira?classifier=json
Voila, you have a valid plugin token in contextJwt. From a plugin developer perspective, this token is as valid as any token generated by any Jira Cloud User. The major difference is that the user is an anonymous user.
@BrunoMarotta
Yep. So, I’m a malicious, anonymous user with an account on a JSM instance. I somehow happen to know the key for a particular plugin that is installed and I generate a token to match that key. The plugin accepts my token and allows me to use it.
Will that plugin now operate outside its programmed user scope? IE will that plugin allow me elevated access to data or features in JSM outside my account permissions?
@sunnyape : That depends on the plugin scope. If the plugin has only ACT_AS_USER scope, then no. But if the plugin has any other scope, then yes. And here we are considering only Jira data. No one knows what other customer-related data all plugins are saving and relying on the Jira Authentication/Token to protect it.
There are more than 1000 Jira Cloud plugins currently. Only 160 of them are Cloud Fortified. For all the other ones, Atlassian’s assumption should be that they were done by small companies or even freelancer developers who probably don’t have much knowledge of security.
But we can just reverse the question and ask: Why a Service Manager user should have access to a Jira Cloud plugin in the first place?
Whew! So the plug-in is constrained to its scope, exactly as expected.
What you seem to be describing is not a security problem, but a philosophical problem. You object to the principle of anonymous users being able to generating any tokens, irrespective of whether they might need them for use with a legitimate plugin, because you think such plugins shouldn’t be required by those users anyhow.
I suggest you submit a feature request to review that functionality of JSW and see who else, including Atlassian, agrees with your assessment.
Best of luck.
Thanks for the irony, but my second question is still open:
Is there any documentation on how user account IDs are formed? Can I assume that if an user starts with “qm:” it is a service manager user?