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][cve] 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][webdev-samesite], 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][webdev-samesite] / 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. ```javascript 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][grafana-v7.5.14] or [v8.3.5][grafana-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][embed], you've modified Grafana's configuration and have set - the [`cookie_samesite` property][cookie_samesite] to `none`, - the [`cookie_secure` property][cookie_secure] 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][mdn-samesite-compat], most notably); favour Chromium-based browsers or Firefox. If the [`cookie_samesite` property][cookie_samesite] is set to `lax` (default) or `strict`, you should scrutinise the security of your subdomains. Rule out the possibility of [cross-site scripting (XSS)][owasp-xss] or [subdomain takeover][honeybadger-subtko] on _all_ [Web origins][mdn-origin] that are [same-site][webdev-samesite] with respect to the Web origin where your Grafana instance runs. [cookie_samesite]: https://grafana.com/docs/grafana/latest/administration/configuration/#cookie_samesite [cookie_secure]: https://grafana.com/docs/grafana/latest/administration/configuration/#cookie_secure [cve]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21703 [embed]: https://grafana.com/docs/grafana/latest/sharing/share-panel/#embed-panel [grafana-admin-role]: https://grafana.com/docs/grafana/latest/permissions/#grafana-server-admin-role [grafana-v7.5.14]: https://github.com/grafana/grafana/releases/tag/v7.5.14 [owasp-xss]: https://owasp.org/www-community/attacks/xss/ [honeybadger-subtko]: https://www.honeybadger.io/blog/subdomain-takeover/ [grafana-v8.3.5]: https://github.com/grafana/grafana/releases/tag/v8.3.5 [mdn-origin]: https://developer.mozilla.org/en-US/docs/Glossary/Origin [mdn-samesite-compat]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#browser_compatibility [mdn-site]: https://developer.mozilla.org/en-US/docs/Glossary/Site [rhynorater-twitter]: https://twitter.com/Rhynorater [samesite-confusion]: https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/ [webdev-samesite]: https://web.dev/same-site-same-origin/ ## 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.