An exploitable CSRF vulnerability exists in Atlassian Jira 7.6.4. An attacker controlling a subdomain different that the Jira hosting subdomain enables cookie injection and control of the CSRF header token. An attacker can create a cookie and submit CSRF attacks on behalf of a logged-in user to trigger this vulnerability.
Atlassian Jira 7.6.4
5.4 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
CWE-352 - Cross-Site Request Forgery (CSRF)
For a Jira instance hosted at jira.example.com, any other subdomain of example.com may set the
atlassian.xsrf.token cookie to any value of their choice to enable CSRF attacks. In large organizations with many subdomains, this creates a significant exposure to CSRF attacks.
This attack does require knowing the unique deployment identifier, but this is obtainable by any non-authenticated user that can connect to the Jira instance.
This practice of using a cookie value for CSRF, the Double Submit Cookie pattern, is known to be insecure.
Example of a cookie set by
atlassian.xsrf.token=A3D2-4M23-294Z-ABCE|deadbeefdeadbeefdeadbeefdeadbeefdeadbeef|lin; Path=/secure/; Domain=.example.com; Secure
Subsequent CSRF attacks to
jira.example.com/secure/... will be able to set the
atl_token value to the now-known cookie value and successfully bypass CSRF protections.
2019-05-14 - Vendor Disclosure
2019-09-09 - Vendor Patched
2019-09-16 - Public Release
Discovered by Ben Taylor of Cisco ASIG.