Page Comparison

Overview

Summary of Vulnerability

This advisory discloses two medium-severity security vulnerabilities in the Secure Login product family. All versions of Secure Login are affected. Both of these vulnerabilities had been found by the independent security specialist Christian specialist Christian Flaßkamp, who gratefully informed us about the issues.

Both vulnerabilities described below relate to the default configuration of the app. Under certain cirumstancescircumstances, the default configuration would allow an attacker to bypass the MFA mechanism , or to access sensitive information hosted in the instance , without MFA. We have no information that these vulnerabilities have already been actively exploited.

According to our agreement as a vendor, we informed Atlassian about the vulnerabilities beforehand.

the vulnerabilities beforehand.

Vulnerability 1:  Unsecure default TOTP configuration

In the default configuration, the value for for Time Window Size is  is set to to 30. That means , that the last 30 and the next 30 tokens are valid. With the default time step value of 30 seconds, it is possible to use an up to 15 minutes old token. Together with the deactivated brute force detection , in the default configuration, this might make a brute-force attack feasible.

Based on the calculation of our internal security consultant, this vulnerability has an overall CVSS score of 3.1, which means medium severity.

Vulnerability 2:  Unsecure default whitelist

In the default configuration, the URL endpoints endpoints /rest and  and /downloads are whitelisted are allowlisted. So in , by default, REST service relying relies only on username and password. Whitelisting Allow listing of the REST services ensures , that other systems are still able to communicate with your Jira Atlassian instance, as there is no reliable way to include 2FA in machine-to-machine communication. 

Due to an error in the status management of Secure Login, it was possible to call the OnBoarding dialog through a deep link after a successful login, but before PIN validation. That was also possible if the user was already successfully registered for the two-factor authentication.

A potential attacker would have been able to exploit this error, to get access to the secret key of a user. The precondition again is, the potential attacker already was in possession of the login credentials of that user.

Fix

Both vulnerabilities have been fixed with version 2.2.2.5 of Secure Login for Jira. To ensure the necessary security, the update contains a significant change concerning the whitelisting. After the update, all administrative and self-service functions require a valid 2FA authentication. That also applies if the corresponding user is actually on the whitelist through IP or group filters.

What you need to do

We recommend that you upgrade to the latest version. For a full description of the latest version of Secure Login for Jira, see the release notes in the Atlassian Marketplace. You can upgrade from the UPM or download the latest version from the Atlassian MarketplaceThe /download endpoint is used to access internal assets, like logos, as well as accessing file attachments. Due to the high number of support requests, e.g., because logos were no longer displayed or access to attachments between systems was prevented (e.g. when accessed by Jira Service Management), the endpoint was added to the default configuration.

Customers have to be aware that as long as these two endpoints are allowed, it is possible to access sensitive information via REST or by accessing attachments only with a username and password. Both endpoints are not protected by MFA if allowed.

Based on the calculation of our internal security consultant, this vulnerability has an overall CVSS score of 5.1, which means medium severity.

Fix

Based on the CIS Critical Security Controls definition, unsecure or not optimal default configurations represent security vulnerabilities. We are currently examining what a corresponding fix could look like. Either the next version of Secure Login will be delivered with a customised, stricter basic configuration or we will completely dispense with a basic configuration and leave the configuration entirely to our customers. We will inform you accordingly in the patch notes.

It is important to note that we will not automatically adjust the existing customer configuration with the update.

What you need to do

However, the right configuration for you is always a trade-off between security and user experience. A value that is too low can lead to a poor user experience or to problems if the end devices do not have functioning time synchronisation. We also recommend activating brute force detection. However, you must be aware that this requires the audit log to be activated. Please clarify internally whether this is OK in terms of compliance and regulatory requirements (e.g. GDPR). You should also check whether the whitelisting of the two endpoints is necessary in your case.

Overall, the configuration is the responsibility of you as the customer. The app can only secure your system as well as the base system and your configuration allow. In addition, MFA is not a substitute for other security measures, such as intrusion detection.

Support

If you have any questions or concerns regarding this advisory, please raise a support request at our Service Desk.