Jira Server Side Request Forgery Vulnerability Could Expose Cloud Data – InApps Technology 2022

Further research into a Jira vulnerability found in September has raised new concerns around the bug tracking and project management software offered by Atlassian, particularly for its use by cloud service providers and container users.

Malicious attackers could use this vulnerability — found on thousands of cloud-based deployments — to bypass web firewalls and trick Jira into exposing sensitive configurations, logs, and credentials.

In September 2019, researchers found a vulnerability (CVE-2019-8451) that affected Jira releases earlier than 8.4.0 that would allow remote attackers to access the content of an internal network resource, via a Server Side Request Forgery (SSRF), due to a logic flaw in the JiraWhitelist class.

New research on this vulnerability has been released by Unit 42 of Palo Alto Networks that should raise concern to anyone developing or deploying containers. The research group took a close look at the Jira SSRF vulnerability and studied its impact on six public cloud service providers (CSPs). What they found is eye-opening.

An SSRF is a web application vulnerability capable of redirecting malicious requests to resources that are usually restricted to the affected server. This is the same type of vulnerability that led to the Capital One breach in July 2019. Attackers are able to circumvent a firewall by tricking the vulnerable application to forward a malicious request to random domains (including the localhost and machines on the LAN).

The most common types of SSRF requests are HTTPS and Uniform Resource Identifier (URI).

According to the Unit 42 findings, their vulnerability scanner found more than 7,000 Jira instances exposed to the internet within public clouds. Of those 7,000 instances, 3,152 were vulnerable to CVE-2019-8451. And 1,779 leaked cloud infrastructure metadata.

The root cause of SSRF, according to Jay Chen, senior cloud vulnerability and exploit researcher at Palo Alto Networks, is “that a web application needs to retrieve resources from another domain to fulfill the request, but the input URL is not properly sanitized and allows attackers to manipulate the destination.”

Chen further explained the issue by saying, “the vulnerable API /plugins/servlet/gadgets/makeRequest?url=endpoint fetches data from the service provider endpoint to populate the gadget. The server does validate the query string and only the whitelisted endpoints are allowed.”

“Due to a logical error in the JiraWhiteList class, an at symbol (@) in the parameter string can bypass the whitelist validation. A request sent to http://vulnerablehost.com/plugins/servlet/gadgets/makeRequest?ur l=http://[email protected]://targethost.com will be redirected to targethost.com. This logical error thus allows attackers to send http requests to any target that is reachable from the vulnerable server,” Chen further explained.

The Unit 42 research claims that Jira caught their attention because it contained the SSRF vulnerability (CVE-2019-8451) which can be exploited without authentication. A patch was immediately released for the flaw, but software like Jira rarely gets updated (due to it being so tightly integrated with business operations). Unit 42 (via a Shodan search) discovered around 25,000 Jira instances exposed to the internet. They then selected six CSPs with the highest number of vulnerable Jira instances and found that 80% of those instances were running versions below 8.4 and could all be vulnerable, if not patched.

The breakdown of those statistics looks like:

• Digital Ocean customers have the highest rate of metadata leaks at 93%.
• Google Cloud customers had the second highest at 80%.
• Alibaba customers came in at 71%.
• AWS rated 68%.
• Hetzner customers were the lowest at 21%.

In the end, Unit 42 offered this list of best practices and remediation for the Jira exploitation:

• Enforce a whitelist of domains that an application is allowed to communicate with.
• Never allow an application to trust another application, simply because it is on the same network.
• Make use of a Web Application Firewall.
• Always keep your web applications updated and patched.

Palo Alto Networks is a sponsor of InApps Technology.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Unit, Uniform.