Exposing a New BOLA Vulnerability in Grafana

This post is also available in: 日本語 (Japanese)

Executive Summary

Unit 42 researchers have discovered a new Broken Object Level Authorization (BOLA) vulnerability that impacts Grafana versions from 9.5.0 before 9.5.18, from 10.0.0 before 10.0.13, from 10.1.0 before 10.1.9, from 10.2.0 before 10.2.6, from 10.3.0 before 10.3.5. Grafana is a popular open-source data observability and visualization platform with over 20 million users worldwide and almost 60,000 stars on GitHub.

This vulnerability, assigned as CVE-2024-1313 with a CVSS score of 6.5, allows low-privileged Grafana users to delete dashboard snapshots belonging to other organizations using the snapshot's keys, impacting the integrity of the system. Exploiting this vulnerability is relatively straightforward as it only requires knowledge of the snapshot's key, which is not considered a secret and is shown in several endpoints’ query parameters.

In addition to this BOLA vulnerability, Unit 42 researchers also found an endpoint that allows any Grafana user to create snapshot images and does not enforce complexity checks on the self-assigned secret keys. While these are not deemed vulnerabilities by Grafana, attackers can potentially exploit them to launch denial-of-service attacks or brute-force the weak secrets to view or delete snapshots belonging to other users.

All the security concerns discussed in this article arise from the dashboard snapshot APIs, a popular feature commonly used for sharing, displaying and backing up data. A low-privileged user with malicious intent could exploit these issues to access sensitive data or compromise data integrity.

This article offers a comprehensive analysis of the BOLA vulnerability and the attack vectors within Grafana, including technical specifics, preconditions and potential impacts. The post also provides practical advice on solutions and mitigations, underscoring the importance of proactive security measures.

Prisma Cloud customers using Web-Application and API Security (WAAS) are better protected from these threats using a new custom rule.

Customers are also better protected through our Next-Generation Firewall with Cloud-Delivered Security Services, including Advanced URL Filtering.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Broken Object-Level Authorization (BOLA)

Also known as insecure direct object references (IDOR), BOLA occurs when an application's server fails to validate whether a user has the right permissions to access, modify or delete an object. An object refers to any data in a system such as the following:

• A message
• A photo
• A trip
• A user profile
• An invoice

Attackers can exploit API endpoints with BOLA by manipulating the identifiers of an object in the requests. In doing so, they can potentially gain unauthorized access to other users' data, leading to data leak, data manipulation or even full account takeover.

In the context of Grafana, these objects refer to data resources such as dashboard snapshots.

Grafana

Grafana is an open-source data visualization and monitoring tool that allows users to pull data from various sources to observe and understand complex datasets. To understand the new vulnerability we discovered, this section explains the two key Grafana components: organization roles and dashboard snapshots.

Organization Roles

In Grafana, a user can be affiliated with none, one or multiple organizations. Users with no organization typically have restricted access, and they are deemed a low-privileged user. They do not hold any specific roles within an organization, preventing them from accessing or modifying data.

On the other hand, users associated with an organization can be assigned specific roles, allowing them to perform certain actions within the organization. Grafana has a set of predefined organization roles that control user access to resources owned by the organization, such as dashboards and data sources. There are four organization roles that a user can be assigned, as described by Grafana:

• Organization administrator: has access to all organization resources, including dashboards, users and teams
• Editor: can view and edit dashboards, folders and playlists
• Viewer: can view dashboards, playlists and query data sources
• No Basic Role: has no permissions, permissions will be added with role-based access control (RBAC) as needed

CVE-2024-1313 allows users with a No Basic Role role or users without organization affiliation to delete any snapshots in other organizations if they know the snapshot's key.

Dashboard Snapshots

Grafana dashboard snapshots capture the current state of a dashboard, including its visualizations, data and configurations. A dashboard snapshot can be used to preserve the data even after raw data sources have been deleted. The snapshot functionality is commonly used for sharing specific data views, creating backups or collaborating on insights. Users can generate a snapshot of their Grafana dashboard and share it with others through a URL.

Figure 1 shows an example of a dashboard snapshot in the Grafana UI.

Keys and DeleteKeys

When a user creates a snapshot via the user interface (UI), by default, Grafana generates a random, 32-character Key and deleteKey that can be used to view or delete the snapshot. For example:

hxxp://localhost:3000/dashboard/snapshot/l1cWRaD0kJERIYF9eyz3RVhafNWEKPbz

When creating a snapshot through the API, users can optionally specify two values: a Key and a deleteKey. A Key uniquely identifies a snapshot, while a deleteKey serves a unique identifier for deleting a snapshot. The deleteKey is different from the Key so that only the snapshot creator can delete the snapshots.

BOLA: Unauthorized Users Can Delete Snapshots

CVE-2024-1313 allows any Grafana user to delete a snapshot with the snapshot’s key through an HTTP/s request for DELETE /api/snapshots/{key}. Grafana users who are not part of the organization that the dashboard belongs to can delete any dashboard snapshot across every organization in Grafana.

An attacker who lacks any organizational affiliation (or holds a No Basic Role within any organization except the one where the dashboard exists) can delete a snapshot created by any user, including Grafana administrators, if they possess the key or URL. This action can lead to data loss or business disruption. Attackers in the same organization as the dashboard snapshot, however, cannot delete the snapshot. This vulnerability has a 6.5 CVSS score.

Creating Snapshots in Any Organization With Weak Key and DeleteKey

During our research, we also found that the HTTP/s request POST /api/snapshots exhibits two potential issues. Firstly, it allows any Grafana user to generate snapshots. Second, it lacks enforced complexity checks on self-assigned secret keys.

Despite Grafana not considering these to be vulnerabilities, we believe they could be exploited to compromise the availability and confidentiality of a Grafana system for the following two reasons:

1. The first issue is that any Grafana user, regardless of their role and organization affiliation, can create snapshots within Grafana. This opens up the possibility for a malicious actor to incapacitate a Grafana system by continuously generating large snapshots filled with random data. (Of note, however, the user cannot control the organization in which the snapshot will be created. If the user is part of an organization, any snapshots will be created within that same organization.)
2. By default, when a dashboard snapshot is created in Grafana's web console, a high-entropy 32-character Key and deleteKey are automatically assigned. Later on, other endpoints rely on the fact that these keys are unguessable. Therefore, to trigger some functionalities, Grafana does not require authorization but relies on the premise that only authorized users are familiar with the keys. The second issue is that users can post their own keys when using the endpoint and it does not enforce any complexity requirements. This makes them vulnerable to brute-force attacks. The absence of a complexity requirement enables attackers to exploit other endpoints that depend on these keys to leak or delete snapshots. For instance, the HTTP requests for GET /api/snapshots/{key}, DELETE /api/snapshots/{key}, GET /api/snapshots-delete/{deleteKey} could all be susceptible to brute-force attacks if the victim’s keys are of low complexity.

Related to the second issue, the global configuration public_mode variable might exacerbate the problem. When public_mode is set to true, even unauthenticated users can generate snapshots using weak keys and query the endpoints shown in the example, which exacerbates the issue. It is worth noting that public_mode is set to false by default and this issue only arises when a user creates a snapshot using the API.

Figure 2 shows an example of a low-privileged user creating a dashboard snapshot with a low-complexity Key and deleteKey. These keys also appear in the URL's path parameters, allowing an unauthorized user to easily access and delete the newly created snapshot.

The HTTP/s request for POST /api/snapshots does not have any dependent parameters in the input. The required dashboard model data contains the telemetry to be included in the snapshot, which can be arbitrary. The Grafana backend does not validate whether this telemetry data exists or not.

Preconditions

To exploit security issues explained in the previous two sections, attackers must know or guess the Key or deleteKey of a snapshot. An attacker can potentially obtain these keys through one of the methods described below.

1. If a snapshot is generated with a low-complexity Key and deleteKey, attackers can perform brute-force attacks on these keys at generating HTTP/s requests such as DELETE /api/snapshots/{key}, GET /api/snapshots/{key} and GET /api/snapshots-delete/{deleteKey}. If they successfully guess the keys, attackers can then access or delete the snapshots.
2. Under normal circumstances, when accessing the snapshot, the key is displayed in plain text as part of the URL’s path parameters, for example, hxxp/s://grafana_host/dashboard/snapshot/admin_key_123. If a snapshot is displayed in a browser during a presentation, audience members may record the key visible in the URL. Furthermore, since the snapshot feature is commonly used for sharing, displaying and backing up data, a low-privileged attacker could potentially discover snapshot keys in places like the organization's content management system, messaging platform or shared documents.

Fixes and Mitigations

Grafana has released a fix to CVE-2024-1313 noted in their security advisory on the matter and suggested upgrading the version to 10.4.x, 10.3.5, 10.2.6, 10.1.9 or 9.5.18 to mitigate the BOLA risk.

Prisma Cloud customers using Web-Application and API Security (WAAS) are better protected from these threats using a new custom rule mitigating the risks associated with snapshots that use low-complexity keys in the HTTP/s requests listed below:

• POST /api/snapshots
• GET /api/snapshots/{key}
• DELETE /api/snapshots/{key}
• GET /api/snapshots-delete/{deleteKey}

Below is a snippet of our WAAS rule deployed for detecting Grafana users creating, fetching or deleting snapshots with weak keys:

In addition, Prisma Cloud customers could detect the BOLA vulnerability in their workloads using vulnerability management.

Customers are also better protected through our Next-Generation Firewall with Cloud-Delivered Security Services, including Advanced URL Filtering.

Disclosure Process

• January 22: We discovered the vulnerability and submitted a report to the Grafana bug bounty program
• January 23: Grafana swiftly responded, confirming it is an issue and checking it further
• February 7: CVE 2024-1313 has been reserved for this issue
• March 26: Grafana released fixes in versions 10.4.x, 10.3.5, 10.2.6, 10.1.9, and 9.5.18

Conclusion

BOLA is a type of vulnerability that many people often overlook, despite its potentially high impact. Even mature applications undergoing rigorous security audits can reveal a BOLA that seems obvious once uncovered. The absence of automated testing tools is the primary reason organizations continue to grapple with BOLA vulnerabilities.

Researchers at Unit 42 are committed to fortifying open-source software and innovating technology to discover new vulnerabilities more efficiently and effectively. Palo Alto Networks customers are safeguarded by our latest research findings and insights.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:

• North America Toll-Free: 866.486.4842 (866.4.UNIT42)
• EMEA: +31.20.299.3130
• APAC: +65.6983.8730
• Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.