Stop scratching the surface, and hack the dependencies

TLDR; How I’ve found four XSS vulnerabilities in Grafana rather than keep scratching the surface while hunting in a private BBP and got rewarded for three criticals(!)
* But you will have to read it to figure out why 😎

Not too long ago, I was hunting in my favorite Bug-Bounty program but couldn’t find anything new or suspicious in its narrow scope, so instead of stopping there, I decided to pursue their dependencies.

The program is using Grafana for some of its core functionalities, so I thought to myself, why not go after Grafana?

After a few minutes, I have found a stored XSS in the table visualization.

I also found another one before that, but it ended up as a duplicate since it was already a known issue — https://github.com/grafana/grafana/pull/23254. ¯\_(ツ)_/¯

Grafana’s vulnerable table visualization

Impact

By exploiting this vulnerability, an attacker could have executed any JavaScript code on the victim’s browser only by them viewing a dashboard with the malicious visualization.

Alert box with the “victim’s” cookies

References

https://github.com/grafana/grafana/blob/master/CHANGELOG.md#673-2020-04-23

Pie-chart is an official Grafana plugin that comes with its default installation.

I discovered that the “Values Header” field was not validating nor sanitizing the user input and therefore was vulnerable to XSS injection.
I was able to inject a simple XSS payload, e.g. <img src onerror="confirm(document.cookie)">.

Impact

By exploiting this vulnerability, an attacker could have executed any JavaScript code on the victim’s browser only by them viewing a dashboard with the malicious visualization.

References

https://github.com/grafana/piechart-panel/issues/218

The “alias” input field in the “Query” tab was not sanitizing nor validating the user input when using ElasticSearch as its data source, which allowed me to inject a simple XSS payload to that field (e.g. <img src onerror="alert(document.cookie)">).

The payload gets triggered once the victim opens the visualization tab.

Impact

By exploiting this vulnerability, an attacker could have executed any JavaScript code on the victim’s browser by manipulating them to open the “query” tab of a malicious visualization.

References

https://github.com/grafana/grafana/blob/master/CHANGELOG.md#710-beta-1-2020-07-01

I have found this vulnerability via manual code review, and it is much harder to be exploited due to the exploitation’s prerequisites (described below).

Prerequisites

1. The attacker must be able to push a new tag value to the OpenTSDB data source, e.g.curl -X POST http://localhost:4242/api/put -d '{"metric":"rotem.cpu.xss","timestamp":1346846400,"value":11,"tags":{"host":"web","dc":"lga<img src onerror=confirm()>"}}'2. The OpenTSDB data source must allow special characters for our exploit to work:tsd.core.tag.allow_specialchars = !@#$%^&*()_+{}|: <>?~`-=[]\;',./°

Impact

By exploiting this vulnerability, an attacker that meets the above prerequisites could have executed any JavaScript code on the victim’s browser by manipulating them to perform the following actions:

Go to an existing or a new dashboard and add a new panelIn the query’s data source select their OpenTSDB data sourceAdd a new tag by clicking on the + signClick on the value field and the XSS payload from our OpenTSDB tag value will trigger

References

https://github.com/grafana/grafana/pull/24539