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 more than 65,000 customers, including the likes of the Apache Software Foundation, Cisco, Fedora Commons, Hibernate, Pfizer and Visa.
CPR researchers said that with just one click, an attacker could have siphoned sensitive information out of Jira.
CPR researcher Roman Zaikin, author of the report, told Threatpost that the main issue is with the Atlassian platform: The team “found multiple vulnerabilities and chained them in order to find this bug,” he said. As far as what sensitive information could have been drained out of the platform, Zaikin said it would have included “anything related to managing a team or writing…code that you can encounter bugs in.”
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.
SolarWinds-esque Supply-Chain Attack
With that level of control over Atlassian, one imagines a potential exploit 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 that 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 actually 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 other 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 CPR, 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
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.”
Exploiting Atlassian required, first off, finding a way to inject code into Atlassian. Researchers did so via a 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 attempted to see if they could make a user add a malicious item without the user’s 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 would-be 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.
Attack Methodology
A successful attack chain would have entailed these steps:
- 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.
- 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.
- 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.”
062421 09:16 UPDATE: An Atlassian spokesperson sent this statement to Threatpost: “Based on our investigation, the vulnerabilities outlined impact a limited set of Atlassian-owned web applications as well as a third-party training platform. Atlassian has shipped patches to address these issues and none of these vulnerabilities affected Atlassian Cloud (like Jira or Confluence Cloud) or on-premise products (like Jira Server or Confluence Server).”
062421 14:24 UPDATE 2: Added clarifying input from CPR researcher Roman Zaikin regarding what kind of information attackers could have been drained from the Atlassian platform.
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.
