Multi-Tenant SaaS Authentication Bypass or Works-as-Designed?

Four months ago, researchers at Cequence discovered an authentication vulnerability in the Lithium community forum platform (now part of Khoros), that warranted a responsible disclosure submission. The vulnerability impacts Khoros customers using the Lithium platform to host public communities and forums, exposing their customer data to unauthenticated users. Khoros has been made aware of our findings but has said the platform works-as-designed.

The Discovery

We pointed a new API security tool at several popular sites including Fitbit, and we noticed a couple of key oddities, including:

• Unauthenticated endpoints, which led to the discovery of endpoints that don’t require a completely valid authentication token.
• The queries were SQL variations and seemed to be editable.

To validate these findings, we modified the query discovered by the tool in use to look for the profile of one of our employees.

“/xmnuz23762/api/2.0/search?q=SELECT+id,+login,+avatar.profile,+rank,+view_href+F ROM+users+WHERE+id+%3D+%22[CEQUENCE EMPLOYEE REDACTED]%22?”

The format here is standard for an SQL query, so we modified the query to look for a list of users.

“/xmnuz23762/api/2.0/search?q=SELECT*FROM+users”

The list of users shows us that the user profile IDs are numeric and the request points to an alphanumeric endpoint “xmnuz23762”.

Image 1: Modified query results display a user profile.

These two data points (the user profile being numeric and the odd endpoint nomenclature) drove us to investigate further. First, we confirmed that user profile 1 is an admin profile for Lithium. Armed with the administrative info, a malicious actor might continue to poke around to see if they make admin-level changes, like modifying or deleting a profile.

Image 2: Query results display an administrator profile.

Tying Lithium and the alphanumeric ID together uncovered that xmnuz23762.lithium.com is one of the Lithium registered domains that redirects to community.fitbit.com. That alphanumeric sequence in the queries is part of the tenant API call.

Further investigating the authentication issues, the team found other Lithium tenants to validate consistent behavior, for example, navigating to aempf32337.lithium.com redirected us to community.roku.com. While still authenticated to the Fitbit community, we ran the same SQL query against Roku, with the same results—we were able to see the user profiles.

“/aempf32337/api/2.0/search?q=SELECT*FROM+users”

It seems Fitbit authentication works perfectly fine on Roku. As shown in the screencap below, the team verified that a user authenticated against one of the public Lithium forums (Fitbit) can view/read all posts from all users on all of the other public Lithium forums (Roku, etc.).

Image 3: Accessing a different community while authenticated to Fitbit.

Delving a bit further, the team removed the authentication tokens completely, placing random characters or using the tokens from another tenant. Each of the authentication scenarios tested (using auth from another forum, no auth at all, or malformed/bad auth) allowed authenticated access to the site.

The Implications

According to the Fitbit community terms of service, all users must have a login and must have provided user details to use the forum. Our findings show that the authentication flaws in the Lithium community platform allow those terms of service to be easily bypassed—you do not need to have a login to read their forum, nor any other public forums. Like Fitbit, all of the public community forums hosted on the Lithium platform will have terms of service that provide guidance on how the platform is used. Even when participating in a public forum, there is an assumption that a user is afforded a small amount of privacy. Our findings indicate that several potentially malicious scenarios are possible if no further action is taken:

• A malicious actor could scrape the data off of all of Khoros’ public tenants.
• A competitor could easily uncover the Khoros customer names and contacts.
• A disgruntled user (or competitor) could use information from posts about product issues to execute a disparaging social media campaign.
• Given the lack of authentication, and the ability to view data in the tables, we believe the platform may be susceptible to SQL injection attacks.

The 90-day waiting period outlined in responsible disclosure best practices expired in August. The last communication with Khoros maintained that it worked-as-designed. We believe the ramifications are significant and warrant an investigation and perhaps a discussion. If the findings are not significant to Khoros, then certainly to their customers and their customers’ users.

Works-as-Designed?

Following responsible disclosure practices, the team submitted the findings to Khoros in May. In most cases, a responsible disclosure submission initiates a mutually beneficial conversation. Khoros replied that what we saw was not SQL but LiQL, their own proprietary look-up language and the public nature of the forum means authentication isn’t required. From their May 24^th communications to us:

“What you found is our API, called LiQL (Lithium Query Language). LiQL uses a syntax similar to SQL. Occasionally, the similarity causes confusion with security experts concerned about SQL injection vulnerability. LiQL queries do not act directly against the Community database. Instead, LiQL queries go through a REST API abstraction layer which maps to predefined objects, not SQL tables. A LiQL query never provides access to the underlying SQL tables and database schema, so you are not at risk of SQL injection when using LiQL. In addition, all queries adhere to the permissions granted to the user account making the queries to ensure that private data is not exposed to the wrong parties.”

A second attempt to reiterate the authentication bypass concerns, (which are that one can view any of the Lithium-hosted public forums without authentication) was dismissed as they are public forums, and the platform worked-as-designed. For Khoros customers that are using the platform to host a public forum, it appears that anyone can read the forum and can pull all posts without your knowledge of who they are. We tested the private forum settings, and private forums do not appear to suffer the same issues with authentication against the backend APIs.

Feeling a bit frustrated, the team turned its attention to Fitbit, now part of the Google responsible disclosure process, which is routed through Bugcrowd. The findings were submitted to Bugcrowd and because it was related to the community forum, it was viewed as out of scope. Following the Bugcrowd procedure, an out-of-scope case was opened to facilitate communication with Fitbit. The out-of-scope report was also rejected. The case has been escalated within Bugcrowd and they have confirmed our findings and they are engaging with Fitbit. No word yet on the status.

Timeline

• May 12th, 2021: Testing finds SQLi and Authentication issues on FitBit’s community.
• May 24th, 2021: A report is made to Khoros, the owner of the Lithium platform that hosts the community. The 90-day responsible disclosure period begins.
• May 24th, 2021: An autoresponder creates a ticket.
• May 24th, 2021: Ticket updated with: LiQL uses a syntax similar to SQL. Occasionally, the similarity causes confusion with security experts concerned about SQL injection vulnerability. LiQL queries do not act directly against the Community database. Instead, LiQL queries go through a REST API abstraction layer which maps to predefined objects, not SQL tables. A LiQL query never provides access to the underlying SQL tables and database schema, so you are not at risk of SQL injection when using LiQL. In addition, all queries adhere to the permissions granted to the user account making the queries to ensure that private data is not exposed to the wrong parties.
• August 12th, 2021: Out-of-Scope submission to Fitbit’s program on Bugcrowd
• August 12th, 2021: Bugcrowd closes the submission for being not applicable.
• August 26th, 2021: Notification to Khoros that 90-day responsible disclosure has expired, Authentication bypass is reiterated and still exists. Next step is to take this information public and include it in educational materials.
• August 26th, 2021: Khoros responds, that we were explaining expected behavior for public open communities and that customers have the ability to restrict unauthenticated access.
• Sept 2nd, 2021: Bugcrowd reopens after escalation; submission forwarded to Fitbit.