Today we are releasing Grafana 7.5.11 and 8.1.6. These patch releases include an important security fix for an issue that affects all Grafana versions from 2.0.1.
Grafana Cloud instances have already been patched, and an audit did not find any usage of this attack vector. Grafana Enterprise customers were provided with updated binaries under embargo.
8.1.5 contained a single fix for bar chart panels. We believe that users can expedite deployment by moving from 8.1.4 to 8.1.6 directly.
A more detailed report can be found on our blog.
CVE-2021-39226 Snapshot authentication bypass
Summary
CVSS Score: 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
We received a security report to security@grafana.com on 2021-09-15 about a vulnerability in Grafana regarding the snapshot feature. It was later identified as affecting Grafana versions from 2.0.1 to 8.1.5. CVE-2021-39226 has been assigned to this vulnerability.
Impact
Unauthenticated and authenticated users are able to view the snapshot with the lowest database key by accessing the literal paths:
-
/dashboard/snapshot/:key
, or -
/api/snapshots/:key
If the snapshot “public_mode” configuration setting is set to true (vs. default or false), unauthenticated users are able to delete the snapshot with the lowest database key by accessing the literal path:
/api/snapshots-delete/:deleteKey
Regardless of the snapshot “public_mode” setting, authenticated users are able to delete the snapshot with the lowest database key by accessing the literal paths:
-
/api/snapshots/:key
, or -
/api/snapshots-delete/:deleteKey
The combination of deletion and viewing enables a complete walk through all snapshot data while resulting in complete snapshot data loss.
Attack audit
We can not guarantee that the below will identify all attacks, so if you find something using the audit process described below, you should consider doing a full assessment.
Through reverse proxy/load balancer logs
To determine if your Grafana installation has been exploited for this vulnerability, search through your reverse proxy/load balancer access logs for instances where the path is /dashboard/snapshot/:key
, /api/snapshots/:key
, or /api/snapshots-delete/:deleteKey
, and the response status code was 200 (OK).
For example, if you’re using the Kubernetes ingress-nginx controller and sending logs to Loki, use a LogQL query like {job="nginx-ingress-controller"} |= "\"status\": 200" |= "\"uri\": \"/api/snapshots/:key\""
.
Through the Grafana Enterprise audit feature
If you enabled “Log web requests” in your configuration with router_logging = true
, look for
"requestUri":"/api/snapshots-delete/”
,“requestUri":"/api/snapshots/:key"
, or "type":"snapshot"
in combination with "action":"delete"
.
Patched versions
Release 8.1.6:
Release 7.5.11:
Solutions and mitigations
Download and install the appropriate patch for your version of Grafana.
Grafana Cloud instances have already been patched, and Grafana Enterprise customers were provided with updated binaries under embargo.
Workaround
If for some reason you cannot upgrade, you can use a reverse proxy or similar to block access to the literal paths:
-
/api/snapshots/:key
-
/api/snapshots-delete/:deleteKey
-
/dashboard/snapshot/:key
-
/api/snapshots/:key
They have no normal function and can be disabled without side effects.
Acknowledgement
We would like to thank Tran Viet Tuan for responsibly disclosing the initially discovered vulnerability to us.