Overview
We conducted a bug bounty blitz where we crowdsourced security testing by inviting security researchers to test Atlassian Marketplace cloud apps and find security vulnerabilities in them over the course of 6 weeks. For this blitz event, Atlassian covered the bug bounty platform fees as well as any monetary rewards for valid security vulnerabilities found (across all Marketplace Partners participating in the blitz) during the course of this event.
Below are some highlights from this event:
- We had 179 cloud apps in scope across 63 Marketplace Partners.
- There were a total of 430 valid security vulnerabilities reported across 61 (out of 63 total) Marketplace Partner programs.
- We paid a grand total of $220,900 USD (which includes some bonuses as well) as monetary rewards for the security vulnerabilities.
- By the end of the blitz, we had approx. 250 researchers invited to each program.
- There were a total of 18 P1s, 76 P2s, 260 P3s, and 76 P4s reported.
- Atlassian paid an average amount of $513.72 USD per submission.
- We saw a common theme of vulnerability classes affecting our Marketplace apps
- Cross Site Scripting - 42% of total issues
- Broken Access Control - 24% of total issues
- Broken Authentication and Session Management - 21% of total issues
In a nutshell, this event was extremely successful in that it helped us improve the application security posture of some of our top Marketplace cloud apps.
It is also worth mentioning that starting up a bug bounty program comes with its own sets of challenges, but it is definitely a good first step in improving the overall security maturity and having some sort of continuous testing being performed against your applications.
Breakdown of Issues
Let’s look at the breakdown of the type of issues we saw in the blitz. Below is a pie chart depicting the breakdown across different vulnerability categories. You can see that XSS is almost half of the entire pie, with BAC and Broken Authentication and Session Management following closely as mentioned at the start of the post.
Next, let’s look at the below graph that shows a breakdown of P1 and P2 submissions against the vulnerability category.
XSS being the most prevalent were mostly scored as P3s but we had quite a few (32) that were P2s as well since they allowed an anonymous user (attacker) signing up for an instance and then exploiting a stored XSS against other users (victims) including admin users.
IDOR is shown separately above but it technically falls under Broken Access Control as the broader vulnerability category. If you combine both, there were a considerable number (25) of P2s and 1 P1 as well.
There were 10 P2s and 2 P1s in the Broken Authentication and Session Management category, which includes Privilege Escalation vulnerabilities as well.
Server Side Injection, XML External Entity Injection, Server Side Request Forgery and Remote Code Execution are all server side vulnerabilities. Combining them all, we saw 9 P1s and 1 P2. These were, by far, the most impactful vulnerabilities as you would expect.
We also saw 6 P1s and 1 P2 for Sensitive Data Exposure, another high impactful category.
Recommendations
Based on the trends observed from the submissions received in the blitz, we want you to be aware of these vulnerability classes mentioned above. We have also come up with a quick list of things to check for across all your apps. Please note that the below list is not exhaustive by any means.
If you have already figured out a way to solve these issues for your apps, we welcome any recommendations/proposals that could help the wider partner community in the interim. Please feel free to suggest/comment your approaches in this post.
-
Ensure you meet all the security requirements documented here.
- We saw some instances where requirement #8 was being violated for certain apps i.e. JWTs were being leaked in the
Refererheader to third parties. More information on these security requirements could be found on this CDAC post.
- We saw some instances where requirement #8 was being violated for certain apps i.e. JWTs were being leaked in the
-
Ensure you validate and sanitize all input you get, even if that means it is coming from Atlassian. We saw quite a lot of Stored XSS issues due to un-sanitized payloads being supplied in the
usernamefield that was directly used by the apps. Similarly, all output should be properly encoded. Connect frameworks such as ACE come with some default templates such as handlebars . We recommend leveraging them to secure against XSS type attacks. This is being tracked underECOSEC-543. -
Ensure you are validating the JWT properly on the server side and using the information retrieved from the JWT to check for user permissions before allowing that user to perform a particular operation. Missing permission checks were a common theme of issues we saw during the blitz. This is being tracked under
ECOSEC-482. Btw, there are some interesting conversations happening on this post around this problem. -
Ensure that JWTs cannot be minted/re-generated indefinitely (from the iframe frontend to the backend communication for authentication) even after the access of a particular user is revoked. We know this is currently possible with ACE - we are investigating the issue in
ECOSEC-545. -
Ensure that JWTs expire within a reasonable time frame. Depending upon your application and its use case, the expiration windows can greatly vary but having the expiration window as large as 30 days is definitely not recommended. As a rule of thumb, we generally recommend expiring the JWT within
15minutes. This is being tracked underECOSEC-544. -
Ensure that you don’t use
Entity Propertiesin Jira and Confluence to store sensitive information. Please follow this post for more information.
Additional Analysis
After the blitz ended, we conducted a survey asking our partners about their general impression about the event and here are the results:
- 72% of respondents feel ‘Mostly’ or ‘Fully’ confident in the security of their products after the Blitz.
- 84% of respondents feel that they will get additional value from their Ongoing Program moving forward.
- 88% of respondents say that Atlassian’s support is ‘Responsive’ or ‘Very Responsive’
- 60% of respondents feel ‘Below Average’ in their confidence of assigning severities and vulnerability categories without any assistance from Bugcrowd and Atlassian - Please refer to this for more information on how to assign severities and vulnerability categories.
During the blitz and from the survey results, there were quite a few things that we observed and got valuable feedback from our Marketplace Partner community. We would like to address them below:
-
There was some confusion amongst the partners initially when the blitz was announced as free for everyone participating however, partners were later asked to fill a reward pool as a way to show their commitment against starting their own ongoing program after the blitz ended. We understand that this communication could have been made much clearer and we will try to keep this in mind for future events, especially when it comes to events that involve money.
-
Using Slack as means of keeping everyone up to date with any announcements/changes about the event seemed to have worked fine and well adopted. It also provided plenty of collaboration opportunities between the Marketplace Partners, Bugcrowd, and Atlassian engineers.
-
Having a blitz FAQ or one place where all updates were made came in as a suggestion in the survey, since it was getting difficult to keep up to date with everything happening across different mediums - CDAC post, Slack, emails, etc. Although we did have a FAQ section on the blitz announcement CDAC post and a separate triage guide, we realize we did not keep them up to date and were treating Slack as the primary medium for all announcements. We will try to streamline this a bit more in the future so that it’s easier to get all the updates from one place.
-
The staggered approach for researcher invitations, where we only invited a handful (1-5) researchers to the blitz programs in the first week and then gradually increased it every week (until most programs had approx. 250 researchers invited), worked fine to some extent. Bugcrowd was quite overwhelmed with the triaging of issues received across all the blitz programs and this approach helped them further to manage that incoming stream and figure out their workloads accordingly. Atlassian engineers were also able to reward the submissions on time, and we kept seeing a steady stream of vulnerabilities being reported during the entire course of 6 weeks. Also, the researchers only had a few programs to focus on as opposed to getting invited to as many as 63 programs at the same time and then cherry picking which ones to look at. That would have certainly given a false signal where having 250 researchers invited to a program didn’t necessarily mean that they were all actively looking at the apps in that program.
-
There was unanimous feedback that most of you are not comfortable assigning severities/priorities and vulnerability categories to submissions. This is understandable and that’s why we leverage Bugcrowd to help us out. Having said that, it is always nice to be aware of how these thing work so we’ve tried to clarify and explain this further via examples. Please see
How to assign severities/priorities and vulnerability categoriessection here for more information.
Thank you!
Finally, to sum it all up, we can confidently say that we feel good after the blitz event. We feel like we now have a good sense of some of the common reoccurring themes of vulnerability classes across all Marketplace cloud apps and we have started tracking them down on our end. We will keep you updated as and when we make progress on these issues. We also hope that our Marketplace Partners found the blitz event useful and are now better educated on the security posture of their apps and things they can do to improve it further.
As always, if you have not already signed up for your bug bounty program, please visit here for more details. The service desk link to sign up for a bug bounty program is here.
Last but not least, we would like to sincerely thank all our Marketplace Partners who were involved in making the blitz event successful. We couldn’t have done this without your support, patience, and willingness to let your apps be susceptible to security testing from a pool of talented hackers.
Signing off for now…
Atlassian Ecosystem Security Team!