Introduction
On November 19th, Tableau announced a Critical vulnerability that allows “…an unauthenticated attacker to configure Site-Specific SAML settings and can lead to account takeover for users of that site”. Very limited additional information was released on this vulnerability, and at the time no public exploit was available. However, due to the CVSS score of 9.8, there is significant risk if organizations are unable to ensure they have successfully mitigated the issue. Given that companies rely on Tableau as a visualization platform for their SaaS products, we started working to identify the exploitability in order to validate the concern.
This vulnerability applies to Tableau servers that are configured to use site-specific SAML, which is used when a different SAML identity provider needs to be configured for each Tableau site in a multi-tenant environment. More details on site-specific SAML can be found here.
Our team was able to develop an exploit resulting in full site takeover with a single prerequisite of knowing the login email address of any existing active user of that site. By specifying that username in our unauthenticated interactions we were able to achieve complete, unrestricted access to the Tableau site.
CVE Overview
During our review of the vulnerability, we identified several API endpoints which seem to be affected by an unintentional lack of authorization. In addition, many of the affected endpoints also had parameters that were able to be obtained prior to authentication. In most cases, only a siteID parameter was needed to invoke the API call and receive a valid HTTP response. The siteID could be easily obtained through proxying and decoding SAML requests to the identity provider during a login attempt.
Our efforts led to two notable exploits:
1. Identity provider (IdP) takeover.
• By setting the identity provider of a specified site to one under our control and configuring our IdP to return a success for any login attempt, we were able to login as any valid user of the system, including administrators.
2. A login denial-of-service.
• By removing the configured identity provider from the server configuration, SSO is disabled.
Timeline
11/19/2020
Tableau releases patches for all supported versions of Tableau server
11/23/2020
Vulnerability publicly disclosed by Tableau with CVE 2020-6939
11/25/2020
Proof-of-concept exploit developed by Seiso, Tableau security team notified
12/01/2020
Tableau confirms awareness of the Seiso exploit and intent to publish; requests 60 day responsible disclosure
03/01/2020
Blog and proof-of-concept details published
Recommendations
The most straightforward method to protect a vulnerable Tableau server is to upgrade it to a non-vulnerable version. For all supported versions of Tableau Server, the vendor has released a patch version dated November 19, 2020 that contains a fix for the issue.
If upgrading is not feasible, blocking access to the vulnerable API endpoints on the affected server where exposure is not necessary will prevent exploitation (see Restricting Vulnerable Endpoints below for more detail).
To test whether this mitigation works in your target environment, refer to the “Proof of Concept” section below, which contains curl commands that will succeed in an unpatched or unmitigated environment.
The commands below can modify critical Tableau configurations and also may cause a Denial of Service condition. Seiso takes no liability for any issues you encounter. Test them at your own risk.
Restricting Vulnerable Endpoints
In many situations, upgrading Tableau Server quickly is not an option. For those scenarios, consider using other infrastructure components such as a Web Application Firewall (WAF) or load balancer to apply HTTP request restrictions which limit access to the vulnerable API endpoints. Those systems should only be limited to servers used for configuring or integrating with your Tableau systems. If none are required, block all access to URIs on your Tableau server which start with /samlservice/private/api/
Alternatively, restrict access to the following URIs:
- /samlservice/private/api/adminLog
- /samlservice/private/api/backup
- /samlservice/private/api/clear
- /samlservice/private/api/clearIdP
- /samlservice/private/api/configureIdP
- /samlservice/private/api/entityDescriptor
- /samlservice/private/api/getAuthUserIds
- /samlservice/private/api/loginToken
- /samlservice/private/api/oidc
- /samlservice/private/api/setAllowEmbeddedAuthentication
- /samlservice/private/api/setAuthenticationTypeForEmbedded
- /samlservice/private/api/setEnabled
- /samlservice/private/api/setSiteAttributeMapping
- /samlservice/private/api/siteConfiguration
- /samlservice/private/api/userConfiguration
- /samlservice/private/api/validateEntityDescriptor
Proof of Concept
Obtain the Tableau Site’s “siteID” Parameter
Tableau’s documentation specifies the login endpoint that the identity provider must use for forwarding authentication attempts back to the server:
We discovered that by browsing directly to https://<tableauserver>/wg/saml, we could force a redirect to the configured identity provider, and in the process, capture a valid SAML request from Tableau.
Base64 decoding the SAML request yields various metadata sent to the server. Particularly useful is the entity alias which shows up as a query string within the AssertionConsumerServiceURL and the saml2:Issuer attribute, which is the siteID. That ID can be used in the future to reference a specific site in a multi-tenant Tableau environment.
Reading and Modifying Vulnerable Endpoints
With the Tableau server URL and site ID, we were able to GET/POST to multiple “private” API endpoints to manipulate Tableau server configurations. For example, you can retrieve the SAML site configuration settings with the following command:
curl --location --request GET 'https://<tableauserver>/samlservice/private/api/siteConfiguration?siteId=<siteId>'Further, you can also disable Single Sign On (SSO).
The command below will cause a denial-of-service in vulnerable environments, preventing user logins until the IdP is re-configured. We take no liability for any issues you encounter. Test them at your own risk.
curl --location --request POST 'https://<tableauserver>/samlservice/private/api/setEnabled?siteId=<siteId>&enabled=0'The most critical issue we were able to exploit was the ability to reconfigure a Tableau site’s identity provider to our own which provided access as any existing user.
Taking Over User Accounts
Note: the steps below may vary between environments based on factors such as the chosen identity provider and the configuration of SAML claims, groups, and attributes.
Step 1 – Configure an identity provider to respond to incoming authentication attempts from the service provider. Doing so will require the acsUrl (Assertion Consumer URL) that was previously obtained through the Tableau server’s siteConfiguration API endpoint:
Step 2 – Export the EntityDescriptor metadata XML file from your IdP, which is needed by the Service Provider (Tableau) to use the new identity provider. In this example, we are assuming you store it in configureIdp.xml.
Step 3 – Configure the Tableau server to use your identity provider using the following POST:
curl --location --request POST 'https://<tableauserver>/samlservice/private/api/configureIdP?siteId=<siteId>' --data @./configureIdp.xmlIf successful, the identityProviderEntityId and ssoServiceURL should reflect the URL of your identity provider.
Once the new IdP is configured you are ready to attempt a login as any existing user account. Methods to identify valid Tableau users within your scope is outside the scope of this article but are often be easily obtainable through open-source intelligence methods.
Using that account is as straightforward as logging in as the user from the Tableau server’s login page. Keep in mind that the correct claims must be set for the victim environment to accept your login flow, such as mapping “username” to the user’s email address in the IdP.
Summary
We anticipate that successful exploitation will vary based on the environment and Tableau server configurations, but in the worst case could allow an attacker to gain highly privileged access to the Tableau site. An attacker able to identify a highly privileged account will likely be able to completely compromise the site and the data within.
This issue has been patched for over 3 months as of the time of publishing. We strongly suggest following the recommendations listed above.