Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


12:10 PM
Connect Directly

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:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Home Safe: 20 Cybersecurity Tips for Your Remote Workers."

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

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Major Brazilian Bank Tests Homomorphic Encryption on Financial Data
Kelly Sheridan, Staff Editor, Dark Reading,  1/10/2020
Will This Be the Year of the Branded Cybercriminal?
Raveed Laeb, Product Manager at KELA,  1/13/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Give us your best shot! You might win an Amazon gift card!
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-01-17
openQA before commit c172e8883d8f32fced5e02f9b6faaacc913df27b was vulnerable to XSS in the distri and version parameter. This was reported through the bug bounty program of Offensive Security
PUBLISHED: 2020-01-17
The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and...
PUBLISHED: 2020-01-17
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node.
PUBLISHED: 2020-01-17
In SaltStack Salt through 2019.2.0, the salt-api NEST API with the ssh client enabled is vulnerable to command injection. This allows an unauthenticated attacker with network access to the API endpoint to execute arbitrary code on the salt-api host.
PUBLISHED: 2020-01-17
Intelbras WRN240 devices do not require authentication to replace the firmware via a POST request to the incoming/Firmware.cfg URI.