[Patch] Graphite SSRF patch

[boktorbb]

Problem Statement

Dashboards contains a server side request forgery (SSRF) flaw in the graphite integration for Timeline visualizer. An attacker with administrative access could set the timeline:graphite.url configuration option to an arbitrary URL. This could possibly lead to an attacker accessing external URL resources as the Dashboards process on the host system.

The proposed open source solution is a hybrid approach that makes use of both the default allowlist that already exists in Dashboards and a blocklist for added security

Configuration: Create a graphite_blocklist setting in opensearch_dashboards.yml that is a list of blocked IPs

The blocklist can be checked in graphite.js . If the list is empty or null, the default allowlist approach of Dashboards can be used for graphite, otherwise we validate the inputted graphite url against the urls present in graphite_blocklist

This allows for default allowlisting behavior for those users who want that approach but still address concerns for cloud providers and platforms that give customers access to Dashboards but are still concerned for internal security and access to APIs that customers shouldn’t have

We also need to make sure that for the HTTP client Dashboards uses that we block follow redirect and have defaults to false, which makes it not vulnerable to an attacker using a fake address and redirecting to IDMS or any other service.

Code flow

The code flow in graphite.js after the blocklist is populated with values is as follows:

• Aggregate the url/urls/ips being used for graphite by customer (whether it’s written in text box or added in allowlist)
• Create a function that resolves host-names to IP addresses
• Verify that the url given is a valid url using below scenarios:
  • block-list enabled and allow-list enabled
    • url is valid only if not in blocklist and in allowlist
  • blocklist enabled and allowlist disabled
    • url is valid only if not present in blocklist
  • blocklist disabled and allowlist enabled
    • url is valid only when present in allowlist
  • blocklist disabled and allowlist disabled
    • urls will not be valid and must enable one of/both solutions
• Make request if url/urls are valid making sure to set redirect value to error

UI Impact

The UI will need a new component that supports both a drop-down list like current Dashboards allowlisting solution and some form of text input that allows customers to enter a url that will be checked against the block-list

The proposal is a combined component that is a text box that allows for a drop down menu as well. Since we would have both the option for a block-list and allow-list, we would want the textbox portion of the component to be active and allow input only when the block-list setting is not empty or null. This stops the same SSRF CVE from being exploited

• Design Doc
• Implementation