Check Point says string of Atlassian bugs gave it "one click" account takeovers.
Supply chain compromise risk is huge: bugs took 4 months to patch...
Security researchers at Check Point say there were able to take over "any Atlassian account, in just one click" by chaining a series of vulnerabilities together in a disclosure that casts a fresh harsh light on the vulnerability of software supply chains to malicious intervention. Troublingly, Atlassian took over four months to fix the bugs.
The series of bugs opened the door to attacks to Atlassian's Bitbucket, a code respository service with over 10 million users; Jira, the software development tool used by over 65,000 customers, including Cisco, Pfizer, and Visa; and team workspace platform Confluence, which has over 60,000 customers, including LinkedIn and NASA.
See also: From C2 to C3: Hackers get esoteric with command and control channels.
(Atlassian uses SSO to navigate between Atlassian products such as JIRA, Confluence and Partners. Despite implementing various web security measures such as CSP, SameSite “Strict” cookies and HttpOnly cookies, Check Point could bypass the controls to achieve full account take-over of a given Atlassian user's account, it said.)
Using a combination of cross-site scripting (XSS) and Cross-Site Request Forgery (CSRF) attacks alongside a form of Man-in-the-Middle (MiTM) attack called "cookie fixation" researchers at the Tel Aviv-based cybersecurity company were able to take control over a victim’s account, perform actions on behalf of them.
https://www.youtube.com/watch?v=GClhS5rNga0 A POC from Check Point.
The cybersecurity company said on June 24 that it disclosed the bugs to Atlassian on January 8, which deployed a fix on May 18. Abuse of the vulnerabilities by a sophisticated adversary -- e.g. through changing source code/implanting backdoors in code hosted on Bitbucket -- could have devastating consequences.
The attack would require luring an Atlassian user into first clicking onto a link that directed them to a Atlassian sub-domain (into which the attacker had injected some malicious code through the XSS bug), where their details could be captured. Technical details here.
Oded Vanunu, head of products vulnerabilities research at Check Point Software: “Supply chain attacks have piqued our interest all year, ever since the SolarWinds incident. The platforms from Atlassian 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.... 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. We hope our latest research will help organizations to raise the awareness on supply chain attacks.”
Attacking Atlassian
The vulnerabilities included an initial XSS bug on the subdomain training.atlassian.com. A simple payload injection let the security researchers grab all of the user’s cookies and local storage. A hop, skip and jump later, they used a "cookie fixation" attack to bypass HTTPOnly protection and hijack the user’s Atlassian account.
As Check Point Software's team explained: "Cookie Fixation is when an attacker can remotely force the user to use a session cookie known to him,
which becomes authenticated. Initially, when the user browses to the login page, the server generates a new session cookie with ‘path=/’ flag. That cookie isn’t associated with any account and only after the user passes the
authentication process that same cookie will be associated to his account.
We knew that using the XSS we couldn’t get the user’s session cookie, since it was protected by HTTPOnly flag.
"Instead, we could create a new forged one. The newly created JSESSION cookie has the same flags as the original, with one major change – the path flag. The original path flag is set to the root directory. We were wondering what would happen if we changed it to a more a particular path? It turns out that our path would have priority since it is more specific and
could be used instead of the original. We changed the path to the exact directive we know the user will get redirected to after authentication,
which caused the backend to authorize our cookie over the original one."
