Critical vulnerability patched in Jira Service Management Server and Data Center

A critical vulnerability was fixed this week in Jira Service Management Server, a popular IT services management platform for enterprises, that could allow attackers to impersonate users and gain access to access tokens. If the system is configured to allow public sign-up, external customers can be affected as well.

The bug was introduced in Jira Service Management Server and Data Center 5.3.0, so versions 5.3.0 to 5.3.1 and 5.4.0 to 5.5.0 are affected. Atlassian has released fixed versions of the software but has also provided a workaround that involves updating a single JAR file in impacted deployments. Atlassian Cloud instances are not vulnerable.

Broken Jira authentication

Atlassian describes the vulnerability, tracked as CVE-2023-22501, as a broken authentication issue and rates it as critical severity according to its own severity scale.

“With write access to a User Directory and outgoing email enabled on a Jira Service Management instance, an attacker could gain access to signup tokens sent to users with accounts that have never been logged into,” the company explained in its advisory. “Access to these tokens can be obtained in two cases: If the attacker is included on Jira issues or requests with these users, or if the attacker is forwarded or otherwise gains access to emails containing a ‘View Request’ link from these users.”

Bot accounts that were created to work with Jira Service Management are particularly susceptible to this scenario, the company warned. Even if the flaw doesn’t impact users synced via read-only User Directories or SSO, users who interact with the instance via email are still affected even when SSO is enabled.

Jira Service Management can be used to set up and manage a service center that unifies help desks across different departments, such as IT, HR, Finance, or Customer Service, allowing teams to better work on shared tasks together. It also allows companies to manage asset, perform inventories, track ownership and lifecycle, IT teams can manage infrastructure configuration and track service dependencies, and can build knowledge bases for self-service. Given the many features that the platform supports and the tasks it can be used for in a corporate environment, the likelihood of a large number of employees, contractors and customers having accounts on it are high and so is the possibility of abuse.

Jira Service Management vulnerability mitigation

The company stresses that companies who don’t expose Jira Service Management publicly should still update to a fixed version as soon as possible. If they can’t upgrade the whole system, they should download the fixed servicedesk-variable-substitution-plugin JAR for their particular version, stop Jira, copy the file in the <Jira_Home>/plugins/installed-plugins directory and then start Jira again.

Once the fixed JAR or the fix version has been installed, companies can search the database for users with the com.jsm.usertokendeletetask.completed property set to “TRUE” since the vulnerable version has been installed. These are users who could have been impacted, so the next step is to verify that they have the correct email addresses. Internal users should have the correct email domain and publicly signed-up users should have their usernames identical to their email address.

A password reset should then be forced for all potentially affected users, which involves a confirmation email being sent, so it’s imperative their email addresses are correct. The JIRA API can be used to force password resets, including expiring any active sessions and logging out any potential attackers.

“If it is determined that your Jira Service Management Server/DC instance has been compromised, our advice is to immediately shut down and disconnect the server from the network/internet,” the company said in a FAQ document accompanying the advisory. “Also, you may want to immediately shut down any other systems which potentially share a user base or have common username/password combinations with the compromised system. Before doing anything else you will need to work with your local security team to identify the scope of the breach and your recovery options.”