Analysis of Jira Bug Stresses Impact of SSRF in Public Cloud

More than 3,100 Jira instances are still vulnerable to a server-side request forgery vulnerability patched in August.

Thousands of Jira instances remain vulnerable to server-side request forgery (SSRF), a Web application vulnerability that redirects malicious requests to resources restricted to a server. The extent of this exposure underscores the impact of SSRF on applications in the public cloud.

SSRF poses a threat to cloud services due to the use of metadata API, which allows applications to access configurations, logs, credentials, and other information in the underlying cloud infrastructure. While the metadata API can only be accessed locally, an SSRF flaw makes it accessible from the Internet and could enable lateral movement and network reconnaissance.

The root cause of SSRF is a Web application needs to get resources from another domain to fulfill the request, but the input URL isn’t properly sanitized and could let attackers manipulate the destination. One of the reasons attackers like to find SSRF vulnerabilities is because they can pivot and see what’s behind the firewall. The implications of this bug vary depending on the environment, though SSRF could have potentially far-reaching effects for many companies: This is the same type of vulnerability that enabled this summer’s Capital One data breach.

To understand the effects of SSRF in the public cloud, researchers with Palo Alto Networks’ Unit 42 investigated known Jira SSRF flaw CVE-2019-8451 and analyzed its impact on six public cloud service providers (CSPs). This vulnerability, which can be exploited without authentication, was disclosed back in August. NVD shows CVE-2019-8451 was introduced in Jira v7.6, which was released in November 2017. Unit 42 found it affects versions back to v4.3, released in March 2011.

“What was especially significant was what the attackers had access to and how long the vulnerability had been out there,” says Jen Miller-Osborn, deputy director of threat intelligence at Unit 42. The fact an exploit would have worked as far back as 2011 “was concerning.”

A patch was immediately released for the vulnerability in August. However, software like Jira, which is closely integrated with business processes, is rarely the first to receive an update.

“Sometimes, with things like this, it’s in part just because you can’t have downtime,” Miller-Osborn explains. System administrators would often rather delay the patch than disrupt business operations, putting critical systems at risk. “This highlights the danger the organization is accepting if they’re making the decision not to patch,” she says.

Calculating Exposure: Who Is Most at Risk?
Researchers started with a Shodan search, which revealed 25,000 Jira instances are currently exposed to the Internet. They chose six CSPs with the highest number of Jira deployments. The goal was to determine how many Jira instances were vulnerable to CVE-2019-8451 in the public cloud, the exploitability of those instances, and the number of hosts leaking metadata, they say.

The researchers’ vulnerability scanner found 7,002 Jira instances exposed to the Internet in these six selected public clouds. Forty-five percent of the 7,002 instances (3,152) are vulnerable to this CVE because they haven’t been patched or updated. More than half (56%) of these vulnerable hosts (1,779) leak cloud infrastructure metadata, the Unit 42 team explains in a blog post.

This leaked metadata ranges from source code and credentials to internal network configuration, and vulnerable firms include technology, media, and industrial companies. DigitalOcean customers have the highest rate of metadata leak (93%), followed by customers of Google Cloud (80%), Alibaba (71%), AWS (68%), and Hetzner (21%).

Microsoft Azure is the only CSP with zero metadata leak, researchers report, because its strict header requirement in metadata API effectively blocks all SSRF requests. It’s worth noting GCP also enforces header requirements in its latest metadata API (v1); however, attackers can still access metadata using legacy APIs if legacy API endpoints (v0.1 and v1beta1) aren’t disabled.

What Admins Can Do
To fix the problem of SSRF, developers should validate the format and pattern of user input before passing it to the application logic. For admins who only install and manage Web apps, there are a few preventive measures to take to lessen the damage of an SSRF flaw.

One of these is domain whitelisting. Most apps only need to communicate with a select few domains, including database and API gateways. Creating a whitelist for approved domains that an application is allowed to communicate with can cut down on services an attacker can hit.

Metadata API can be protected by CSPs, but if this kind of protection is not available, there are additional steps businesses can take to reduce the risk of metadata leak. One of these is enabling CSP metadata API security. Some CSPs have configurable options to secure metadata API. Companies can also create firewall rules inside VMs to block the IP of metadata API.

Related Content:

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial … View Full Bio

More Insights

Read More HERE