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
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "This is the last time we hire Game of Thrones Security"
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-12-09
IBM Watson Assistant for IBM Cloud Pak for Data 1.0.0 through 1.3.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session....
PUBLISHED: 2019-12-09
IBM Planning Analytics 2.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 168519.
PUBLISHED: 2019-12-09
IBM Planning Analytics 2.0 is vulnerable to malicious file upload in the My Account Portal. Attackers can make use of this weakness and upload malicious executable files into the system and it can be sent to victim for performing further attacks. IBM X-Force ID: 168523.
PUBLISHED: 2019-12-09
IBM DataPower Gateway throug 6.0.14 and 2018.4.1.0 through 2018.4.1.5 have a default administrator account that is enabled if the IPMI LAN channel is enabled. A remote attacker could use this account to gain unauthorised access to the BMC. IBM X-Force ID: 168883.
PUBLISHED: 2019-12-09
An unsafe deserialization vulnerability exists in CA Release Automation (Nolio) 6.6 with the DataManagement component that can allow a remote attacker to execute arbitrary code.