Ecoscanner

The Ecoscanner platform is a platform used for performing security checks against all Marketplace cloud apps on an ongoing basis. This will help us continuously monitor our Marketplace cloud apps for common security vulnerabilities and improve the overall security posture of our ecosystem.

What type of scans will the Ecoscanner Platform run?

Missing Security Requirements

On November 23, 2020, we open sourced a tool called Connect Security Requirements Tester aka CSRT. This tool is built specifically to scan for missing security requirements.

Starting April 1, 2021, we will be scanning Marketplace apps for a subset of the Security Requirements.

Security requirement	Ecoscanner check	CVSS score	Details and remediation
1a	The application must use TLS to encrypt all of its traffic and TLS version 1.2 (or higher) are required.	7.4 (High)	Transport Layer Security
1b	HSTS must be enabled with a minimum age of at least one year.	6.8 (Medium)	Transport Layer Security
3	For the domains where your app descriptor file is hosted and the domains specified (as the baseURL or other URLs) in the app descriptor file, TLS certificates of these domains must be valid	8.1 (High)	Validity of Domain Registration & TLS Certificates

QSH bypass

A vulnerability within the Connect platform allows Connect Context JWTs tokens to be used in the place of server-to-server or iframe JWTs because of a missing qsh claim.

The qsh claim is designed to prevent replaying JWTs against other endpoints within apps (such as /installation lifecycle hooks). Because the qsh is not present in context JWTs they can supplemented where server-to-server JWTs are expected to:

Load modules regardless of conditions
Sign web triggers, web panels, etc
Send a /install payload signed with a context JWT overwriting the app install data, and giving the “attacker” control over the app secret
Uninstall the app (sending /uninstalled lifecycle)

Impact

The impact of this vulnerability depends on what your app does. Your app is vulnerable if:

It contains any Connect UI modules (web panels, macros, pages, etc); and
The context JWT from these modules can be used in lifecycle hooks (/installed), or substituted as the jwt in iframe URLs

Because this is a vulnerability in the Connect platform/JWT spec, it’s highly likely your app is impacted.

How we scan for `qsh` bypass

Our Ecoscanner utility checks if Connect apps are vulnerable to context jwt qsh verification bypass by examining the app descriptor file for the following snippet:

1
2
3

"apiMigrations": {
    "context-qsh": true
}

Apps containing this parameter are not vulnerable. In all other cases, a security vulnerability ticket will be raised against the app with the default severity of High (7.4).

Mitigation

As of March 22, 2021, Connect allows apps to opt into a static qsh in context JWTs. To mitigate the vulnerability in your app, you must:

Opt into the context JWT qsh claim behavior by updating your apiMigrations Connect descriptor; and
Update app endpoints that need to accept context JWTs to allow static qsh claims; and
Ensure you’re not accepting context JWTs in app module (web panels, lifecycle hooks, etc) endpoints; and
Deploy your app to production

Your descriptor should look like:

...
"apiMigrations": {
    "context-qsh": true
}
...

Expired domains

Marketplace apps with a registered domain that is expired can be re-registered by a malicious user and then used to exfiltrate sensitive information from any tenant where the vulnerable app is installed.

How we scan for expired domains

We check the app baseUrl for domains that appear to be available for registration. For apps with expired domains, a security vulnerability ticket will be raised with the severity of Critical (9.0).

Mitigation

Domains for any app installed on a customer tenant must be owned and controlled by the developer of the app. Apps that are no longer maintained must be uninstalled from all customer instances.

Scan Cadence

The Ecoscanner runs all above checks daily.

Ticketing

Valid findings will be ticketed and assigned to the app owner with corresponding SLAs attached. To find out more about our vulnerability management framework, see this page.

FAQ

Can we have the Ecoscanner scan only our staging environment?

All scanning activity originating from Ecoscanner is supposed to be non-intrusive and very basic so Atlassian will continue to scan the production environment of cloud apps for now. If this changes in the future, we will communicate accordingly.

How do we know if the scan traffic is coming from Atlassian and not from some adversary?

All scan traffic should originate from the below listed IPs and IP Ranges:

100.25.61.160
3.214.98.112  
35.172.132.4  
3.221.51.2    
3.217.215.43  
35.174.235.12
34.211.197.111/32
50.112.197.134/32
52.42.55.113/32
54.68.221.42/32

What would the scanning be like? How intrusive? Requests/sec? What kind of requests should we expect to see?

Generally speaking, the more links in your descriptor, the more traffic you will receive. The traffic is very “bursty”. But, some approximate numbers are below:

Initial validation – Max 2 requests
Descriptor scan – Max 6 requests per link
TLS scan – No noticeable traffic at the app-level

Apart from the CSRT scanner, what other types of scanning will happen? Will they be announced and open sourced like CSRT?

As and when we introduce additional scanners, we will follow up with a CDAC post and also update this page. We will treat open sourcing on a case by case basis.

Can we build our own scanner and ask Atlassian to run it for us and for other Marketplace apps?

Yes, absolutely. We would totally love this. You come up with scanners and let us deal with figuring out how to run them at scale against all apps. Please feel free to create a request in our service desk describing the scanner and instructions on how to run it.

What will be the cadence of the scanning? What time/time zone will the scanning occur?

We will keep the scanner sections above updated with their scanning cadence

How will we get notified about the scan results?

We will communicate the vulnerability reporting/notification once we have more information.

Will server/DC apps also get scanned?

As of now, we are not planning to scan server and DC apps. This might change in the future as the Ecoscanner platform becomes more mature.

Can apps opt out of scanning?

Apps CANNOT opt out of scanning at this time.

How do we get in touch or contact Atlassian if the scanning somehow breaks the app? How do I get support wrt the scanning?

We hope this never happens since the scanning is going to be non-intrusive (unless otherwise mentioned). In the odd case when it does end up breaking your app and you want us to look into it, please go ahead and create a request on our service desk.

How do I know the scanner is running? How do I know app X is being scanned?

During our staged rollout, not all apps will be scanned. Once we have fully rolled out EcoScanner, every marketplace app will be scanned on a regular cadence as listed above. If you feel like your app is not being scanned, you are welcome to open a ticket with us to confirm at our service desk.

Why are we not scanning all the security requirements? Out of all the security requirements that will be scanned, which ones will be reported as security vulnerabilities?

We understand it is not practically possible to scan for all the requirements (because of the subjective nature of them that is different for different apps) but there are a handful of requirements that we can scan for. We will NOT be reporting any security vulnerabilities right now. We are going to continuously monitor the platform for any improvements and fine tune it, if necessary. Once we are confident about the quality of findings, we will then begin reporting them as vulnerabilities. More information on this to come at a later date.