Action required: Atlassian Connect vulnerability allows bypass of app qsh verification via context JWTs

Hi @cmacneill,

as I understand it, if my app use “none” for the authentication descriptor, it is only necessary to add “context-qsh”: true in the “apiMigrations” section to avoid generating the vulnerability report. it is right?

Thank you

Thank you Remie,

This is very helpful indeed. I really appreciate you helping me and others by explaining this in more detail.

It’s so important to get this right and potentially business damaging if we don’t.

1 Like

Thanks marc. All background and guidance is helpful.

Your understanding is correct. Your app isn’t vulnerable if your app uses none for authentication.

We’ll only be raising AMS tickets for eligible apps that haven’t opted into the apiMigrations and are using authentication other than none.

1 Like

Thank you very much for the reply

Thanks for the explanations.

Some of the HTML links describes in the descriptor, such as dialogs, cannot be validated (JWT/QSH) because JWT token is not sent with the request: AP.Dialog doesn't provide JWT token on URL call

Is it planned to also include these for JWT/QSH validation and so, include JWT/QSH in the request ?

Thanks for your reply.

Hi,

Thanks for the write-up about the vulnerability and the fix. Since this is a security vulnerability, do you have a CVSS score for it?

Thanks.

NVD - CVE-2021-26074 - Connect Spring Boot
NVD - CVE-2021-26073 - Connect Express

4 Likes

Great question. As @OfirNir linked, we’ve raised CVEs (currently undergoing analysis, will be scored in the NVD soon) for Atlassian Connect Express and Atlassian Connect Spring Boot (the official Atlassian Connect app frameworks). These vulnerabilities cover the issue of context JWTs being accepted in lifecycle endpoints:

The overall vulnerability, which is due to ambiguity of context JWTs and iframe/server-to-server JWTs, was scored also as CVSS v3 9.1 Critical which was upgraded from the initial CVSS High scoring after additional analysis.

2 Likes

Hi,

Does this means that all the vendors should threat this as a security incident as mentioned here?
https://developer.atlassian.com/platform/marketplace/app-security-incident-management-guidelines/

Or is Atlassian planning to make a single communication to all customers that have apps installed?
I’m not sure about the model that Atlassian uses to report vulnerabilities on cloud products. I don’t remember to be notified about a critical vulnerability on jira, confluence or bitbucket cloud in the last 3 years. Is it possible to check any advisory, or Atlassian never had a critical vulnerability reported for cloud products?

Thank you.

2 Likes

Well, either way, not all vendors. Only those using ACE / ACSB. We’re not affected by this vulnerability, because we have a custom implementation and never accepted context JWT for lifecycle events, webhooks, etc.

Sure, I was referring to all vendors using ACE or ACSB.

We advise vendors to follow the app incident management guidelines if you determine exploitation of the vulnerability within your environment.

Good question, we contact customers inline with the Atlassian Security Practices. You can read more about them on our Trust Center: Security Practices | Atlassian
Server advisories (which require customer action) are posted on Security Advisories | Atlassian

@HeyJoe if I update my app descriptor and its URL remains the same, I just have added a new parameter. Should I create a new version of my app in the Marketplace vendor management section? Or new descriptor will be automatically updated by Marketplace?

The Atlassian Marketplace should spot the difference, via polling your descriptor, and make a minor version bump. If that does not happen automatically then you can always perform the change manually.

If I only received webhooks from JIRA after the installation do I only need to add the new field to my descriptor or must I validate the qsh I received in the webhook jwt?

If the requests I make to the JIRA rest API already contain a qsh in the jwt do I need to do anything more?

Hi everyone,

Please note the update to this announcement dated today (May 7 2021) - If your app is using Atlassian Connect Spring Boot, please upgrade to Atlassian Connect Spring Boot 2.1.5 or later, 2.1.4 regressed on the fix introduced in 2.1.3.

Sorry for the confusion!

Hi @MichaelRichardson ,

Because webhook requests to your app are signed with a JWT that includes a qsh claim, you must do both: Add the new field to your descriptor and validate the JWT including the qsh claim in your webhook request handler.

This vulnerability relates to authenticated JWT requests that Atlassian sends to your app, not authenticated JWT requests that your app sends to Atlassian.

@HeyJoe - I just got alerted for this for a bitbucket cloud connect app. I made the fix and added it to the descriptor, and now I’m getting errors per email which looks like the bot is scanning for JIRA or Confluence cloud apps only? According to the documentation (which btw still does not mention apiMigrations), the proper scopes for bitbucket are account or repository.

The .json descriptor provided is invalid (/scopes/0: instance value ("repository") not found in enum
 (possible values: ["none","NONE","read","READ","write","WRITE","delete","DELETE","project_admin","PROJECT_ADMIN","space_admin","SPACE_ADMIN","admin","ADMIN","act_as_user","ACT_AS_USER","access_email_addresses","ACCESS_EMAIL_ADDRESSES"])). Check your descriptor and try again.

We’ve published a new CVE to cover Atlassian Connect Spring Boot 2.1.4: NVD - CVE-2021-26077

If you’re using Atlassian Connect Spring Boot, please upgrade to 2.1.5 or greater as soon as possible.

1 Like