Trello platform information leakage analysis

March 6, 2024

Introduction

Sometimes it doesn't take a complex attack for an organization's reputation to be affected by its appearance in the media. This is what happened this January to Trello, the well-known project and task management platform owned by Atlassian.

An actor, under the pseudonym emo, put up for sale in a well-known hacking forum, data of 15 million Trello users with public and private information about them: username, full names, and associated emails.

As it usually happens, Trello, when contacted to obtain information about the information leak, suggested that it was not an attack, but information collected by scanning public information (scraping) of the profiles of its platform from a list of potential users.

While it is true that these scraping techniques can be used for these purposes, in principle, the email associated with a Trello account is private information to which only the user in question should have access, and that is where the relevance of this information leak lies.

API configuration

Most SaaS (Software as a Service) platforms employ API (Application Programming Interfaces) to provide information to users and developers about their features, functionality, statistics, and usage.

Most organizations protect the abuse of these APIs mainly through two techniques that may or may not be used in a coordinated manner:

Authentication: only users with access credentials can obtain information from the service and often limited to their own use.
API usage limits (rate limiting): The definition of temporary limits on the use of the interface by a user in the terms and conditions of the service. Normally this limitation is done by IP or other data that allows to determine the origin of the requests.

The absence of adequate anti-abuse measures in the Trello API is precisely the root cause of the information leakage detected.

What happened in the Trello incident?

The actor under the pseudonym emo discovered that a Trello public API endpoint, which did not require authentication, allowed obtaining user profile information not only through their Trello username or Trello id but also through an email.

The attacker built itself a list of more than 500 million potential emails based on publicly available or publicly available information from previous data leaks and started requesting profile data associated with the Trello API.

The attacker used one of the many proxy services available on the Internet to launch the queries from different IPs and not be affected by the rate limiting protections discussed above, in order to avoid detection and exclusion from accessing the API.

Screenshot of the information posted by emo in the forum

After passing all emails through the X (Twitter) API, the attacker ended up obtaining the profile and email data of more than 15 million users and put them up for sale on January 16, 2024. Simple but effective.

Information regarding this attack has been reflected on the well-known security breach portal HaveIBeenPwned.

Impact

It is not the first time that a public API endpoint has been used to build a dataset of a certain service. Twitter had a similar problem in 2021, when attackers exploited a bug in its API that allowed users to see if a certain email or phone number was associated with this social network. Twitter fixed that bug in January 2022, but by then, it was too late, and a data breach of more than 200 million profiles occurred.

We could argue that the impact of the incident is low, since no passwords or relatively sensitive user data have been leaked, but, although it can be seen from that perspective, on many occasions these databases of services associated with a particular user are used in campaigns of greater complexity based on the OSINT (Open-Source Intelligence) information available.

An email, for example, can be used in future credential stuffing campaigns such as the one used in the attack against 23andme that we recently wrote about in this blog.

Another potential risk of this type of private information collection is its use for email phishing campaigns to users who have been detected as having a Trello account. This type of campaign tends to have a much higher success rate because the user receives an email from a service they use, which makes them less likely to be suspicious.

Conclusions

It is important to perform an API bastioning or even hacking exercise prior to the publication of an API by a cloud service provider in order to detect its deficiencies and potential cases of misuse or abuse of the interface.

Providing relatively sensitive information, such as email, of a user's association with a service publicly or without authentication should be avoided, as such data can be used to gather information in discovery phases by an attacker.

A classic example of this is the password recovery interface, sometimes services change the message depending on whether the user exists: "a message with password recovery information has been sent to your email" or does not exist: "the user is not registered", this allows the construction of a user database through simple brute force.

The reputation of an organization exposed to the Internet is a high and sensitive value.

This type of error is fortunately becoming less and less frequent and services are opting for generic password recovery messages along the lines of: "If the email is in our systems, you will receive a link to reset your password".

In short, the reputation of an organization exposed to the internet is a high and sensitive value. It is very difficult to build and, as we have seen in this article, very easy to erode even without being subject to a complex attack. This is why organizations should strive to conduct secure development cycles and perform security testing prior to releasing an API to production.