Atlassian Bugs Could Have Led to 1-Click Takeover

Atlassian, a platform used by 180,000 customers to engineer software and manage projects, could have been hijacked with a single click due to security flaws, researchers have disclosed.

On Thursday, Check Point Research (CPR) published a report (PDF) outlining how an attacker could have exploited the bugs to access Atlassian’s Jira: a proprietary bug-tracking and agile project management tool. Jira counts some heavyweights among its fan base: the software-development tool is used by over 65,000 customers, including the likes of Visa, Cisco, Pfizer, Fedora Commons, Hibernate, and the Apache Software Foundation.

CPR researchers said that with just one click, an attacker could have siphoned sensitive information out of Jira, such as “security issues on Atlassian cloud, Bitbucket and on-premise products.”

The flaws could have also enabled an attacker to take over accounts and to control some of Atlassian’s applications, including Jira and Confluence: a web-based corporate wiki that comes with a built-in Tomcat web server and hsql database and which also supports other databases. More than 60,000 customers use Confluence, including LinkedIn, NASA and the New York Times.

Bugs Could Have Led to SolarWinds-esque Supply-Chain Attack

With that level of control over Atlassian, one imagines that an exploit could have been fashioned that would have been similar to the SolarWinds supply-chain attack, in which attackers used a default password as an open door into a software-updating mechanism.

The threat actors in the far-ranging campaign were able to use SolarWinds’ Orion network management platform to infect targets by pushing out a custom backdoor called Sunburst via trojanized product updates. Far-ranging is an understatement: The supply-chain attack succeeded in compromising the head of the Department of Homeland Security (DHS) under former president Trump, other top-ranking members of the department’s cybersecurity staff, numerous large enterprises and other U.S. government agencies.

Of note, Orion is an infrastructure monitoring and management tool that sits in a network sweet spot, where it reaches other assets and thus makes an ideal base camp for an attacker to carry out malicious activities.

In fact, it was the SolarWinds catastrophe that inspired CPR to investigate Atlassian n the first place: Researchers said that they grew curious about supply-chain attacks following the incident.

In the course of its investigation, CPR managed to bypass Atlassian’s security measures, “proving that an attacker could have injected malicious code, performed actions on behalf of users, and hijacked user sessions,” CPR researchers wrote.

They noted that Bitbucket, a Git-based source code repository hosting service, could also have played a part in a supply chain attack to target Atlassian partners and customers. The vulnerability affected several Atlassian-maintained websites that support customers and partners but doesn’t affect Atlassian cloud-based or on-prem products.

Oded Vanunu, head of products vulnerabilities research at Check Point Software, was quoted in a release as saying that supply chain attacks “have piqued our interest all year, ever since the SolarWinds incident.” He noted that Atlassian platforms are “central to an organization’s workflow.”

“An incredible amount of supply chain information flows through these applications, as well as engineering and project management,” Vanunu continued. “Hence, we began asking a somewhat provocative question: What information could a malicious user get if they accessed a Jira or a Confluence account?”

Account Takeover

The answer: a lot of sensitive information. In its investigations, CPR achieved account takeover on Atlassian accounts accessible by subdomains under atlassian.com. These are the subdomains that researchers found to be vulnerable:

• jira.atlassian.com
• confluence.atlassian.com
• getsupport.atlassian.com
• partners.atlassian.com
• developer.atlassian.com
• support.atlassian.com
• training.atlassian.com

Exploiting Atlassian required, first off, finding  a way to inject code into Atlassian. Researchers did so via an XSS vulnerability on the subdomain “training.atlassian.com”, which offers users courses or credits. When the item type is “training_credit”, an additional parameter called “options._training_credit_account” is added to request: a parameter that was vulnerable to XSS.

The Content Security Policy (CSP) was configured “poorly” on this subdomain, the researchers explained, with “unsafe-inline” and “unsafe-eval” directives, which allows script execution. This made the subdomain “a perfect starting point” for research, they said. They were able to exploit the XSS bug to snag all the cookies and the local storage of the target.

Next, since the stored XSS could only be run when adding items to the shopping cart, the researchers had to make the user add a malicious item without their notice. Given that there was no CSRF token, they could perform a CSRF attack on the shopping list and execute their payload. To do so, they uploaded a proof of concept and sent it to the victim. Because that payload was Stored XSS, it was stored in the database and added to the Shopping List, and their malicious item was added to the shopping cart.

The researchers used this code injection to add a new session cookie to the user’s account, and, in combination with a session fixation vulnerability in Atlassian domains, they managed to take over accounts.

What Attackers Could Have Done

The bugs would have enabled an attacker to pull off a laundry list of malicious activities, such as cross-site scripting (XSS) attacks; cross-site request forgery (CSRF) attacks; or session fixation attacks.

“In other words, an attacker could use the security flaws found by CPR to take control over a victim’s account, perform actions on behalf of him, and gain access to Jira tickets,” the researchers noted. “Furthermore, an attacker could have edited a company’s Confluence wiki, or [viewed] tickets at GetSupport. The attacker could have gone on to gain personal information. All of this could be accomplished in just one click.”

Attack Methodology

A successful attack chain would have entailed these steps:

1. Attacker lures victim into clicking on a crafted link (coming from the “Atlassian” domain), either from social media, a fake email or messaging app, etc.
2. By clicking on the link, the payload sends a request on behalf of the victim to the Atlassian platform, which would have performed the attack and stolen the user session.
3. Attacker logs onto victim’s Atlassian apps associated with the account, gaining all the sensitive information stored therein.

CPR disclosed its research findings to Atlassian on Jan. 8. According to CPR researchers, Atlassian said it deployed a patch on May 18.

“In a world where distributed workforces increasingly depend on remote technologies, it’s imperative to ensure these technologies have the best defenses against malicious data extraction,” Vanunu concluded. “We hope our latest research will help organizations to raise the awareness on supply chain attacks.”

Threatpost has reached out to Atlassian for comment. As of Wednesday evening, the company hadn’t provided any input.

Join Threatpost for “Tips and Tactics for Better Threat Hunting” — a LIVE event on Wed., June 30 at 2:00 PM ET in partnership with Palo Alto Networks. Learn from Palo Alto’s Unit 42 experts the best way to hunt down threats and how to use automation to help. Register HERE for free.