Availability of proof-of-concept code for vulnerability in Jira poses a challenge, as the Jira 7.x branch did not appear to contain a fix for the flaw
CVE-2019-8451 is a pre-authentication server side request forgery (SSRF) vulnerability found in the /plugins/servlet/gadgets/makeRequest resource. The vulnerability exists due to “a logic bug” in the JiraWhitelist class. An unauthenticated attacker could exploit this vulnerability by sending a specially crafted web request to a vulnerable Jira server. Successful exploitation would result in unauthorized access to view and potentially modify internal network resources.
The vulnerability was first introduced in Jira Core and Jira Software versions 7.6.0, an enterprise release in November 2017, and affects Jira Core and Software versions from 7.6.0 through 8.3.4.
Shortly after a patch was released, a GitHub repository was created on September 16 containing a proof-of-concept (PoC) for CVE-2019-8451. On September 23, security researcher Henry Chen published a tweet showing exploitation of the vulnerability in an animated GIF and referenced previous work around SSRF vulnerabilities from DEVCORE researcher Orange Tsai’s Black Hat talk, “A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!” from 2017.
Dino A. Dai Zovi, Head of Security at Square’s CashApp, retweeted Chen’s tweet saying “If you’re running JIRA on AWS consider this SSRF to be RCE.” This exposure to a Jira asset within Amazon Web Services (AWS) could provide access to the AWS Instance Metadata service, which has been previously identified in research from 2017.
An SSRF can provide attackers with the ability to query the cloud provider’s APIs, enumerating permissions and extracting data or executing API commands for other cloud services. Our example above simply aims to get the security credentials from the environment.
This Instance Metadata service, located at 169.254.169.254, provides information about Amazon Elastic Compute Cloud (EC2) instances. This SSRF vulnerability could conceptually allow an unauthenticated attacker access to any cloud computing privileges which that instance contains by querying the instance’s API metadata service.
In this AWS use-case, an exploitation of the CVE would provide an attacker the ability to query the instance metadata service for security credentials. AWS’s security-credentials endpoint “/latest/meta-data/iam/security-credentials/” returns a rolename. Querying the security-credentials endpoint with the rolename provides us with the AWS API AccessKeyID, Secret Access Key, and Token w/ Expiration date.
The attacker could use these credentials to execute any action associated with the role of the instance. For example, in a supply chain breach scenario, more deceptive attackers could use this access to query the user-script of the EC2 instance, obtain configurations of Amazon Elastic Container Service (ECS) (Docker container) assets and even retrieve Docker images, plant a backdoor, then push the image back into the registry. Conceptually, any exposed JIRA asset residing on any cloud provider (AWS, Azure, Google Cloud, Alibaba, Digital Ocean) is a target and capable of causing a potentially devastating breach for your organization.
Proof of concept
As noted above, a PoC for CVE-2019-8451 has been available since September 16, with further examples being referenced in tweets on September 23.
Atlassian addressed this vulnerability in Jira Core and Jira Software versions 8.4.0. Many of the releases under the Jira 7.x branch are on a path towards end of life (EOL). Jira 7.13, the most recent enterprise release version, will reach EOL in November 2020. Jira 7.6, however, will reach its EOL in November 2019. Until their respective EOL dates, these Jira versions receive bug fixes. However, it does not appear that CVE-2019-8451 was addressed in any recent release under the Jira 7.0 branch. Outside of upgrading to Jira 8.4.0, there is no specific workaround designed to prevent attackers from utilizing this vulnerability. The only known solution would be to ensure that Jira instances aren’t publicly accessible.
In the context of AWS, we encourage administrators to utilize strong Role and Profile management of AWS assets, restricting API access by following the principle of least privilege, and enabling logging for detection to identify malicious activity.
Identifying affected systems
A list of Tenable plugins to identify this vulnerability will appear here as they’re released.
Get more information
Join Tenable's Security Response Team on the Tenable Community.