This week, we have news of a record four API security related incidents. The first comes from Troy Hunt on a leakage on the new Spoutible social media site, with the second big ticket item being the leakage of 15 million profiles on Atlassian’s Trello. There’s also a report on the leakage of over 18,000 API tokens and the leakage of Office 365 accounts via a misconfigured server. We also feature a guide on implementing basic authentication on Spring Boot.
Vulnerability: Vulnerabilities in Spoutible API
The first vulnerability this week comes to us from the founder of Have I Been Pwned, Troy Hunt, and features several significant vulnerabilities in the API of the new Spoutible social media platform. In Troy’s own words, “No way! No way!” — this is almost a case study on how not to implement an API. Let’s dig in — fasten your seatbelts.
The Spoutible API offers a standard service endpoint allowing a user to retrieve basic account information; in Troy’s case, this is:
https://spoutible.com/sptbl_system_api/main/user_profile_box?username=troyhuntAs expected, this endpoint returned some basic metadata such as name, id, and profile. Troy also noticed that it returned several PII fields, including email and phone numbers. Given that this endpoint took a username as a parameter, it meant that an attacker could scrape the emails and phone numbers of any user at will.
Whilst that’s already a significant issue, it gets much worse. He noticed that it also returned the Bcrypt password hash — no way, I hear you say. He verified that the hash did match his (deliberately weak) password. Whilst not quite as bad as exposing the password directly, this is the next best thing. Bcrypt is vulnerable when used to hash weak passwords, and since Spoutible allowed passwords as short as six characters, it was possible many user passwords were susceptible to being cracked. One can only speculate as to why the API developer felt that returning the Bcrypt hash was a good idea or even remotely useful to anyone other than a hacker.
He then discovered that the API returned several 2FA values, including the secret (which would allow the regeneration of a new valid 2FA code) and a Bcrypt hash of the backup code. Since the code was only six digits, this was easy to reverse engineer using a Bcrypt cracker. Incredibly, there is one more little “No way” moment. He also discovered a value called em_code, which turned out to be the validation code when resetting a password via email. The API was literally providing the information necessary to perform an account takeover.
Troy reached out to the founder (ironically on Twitter) to alert him of these vulnerabilities, and within four hours, the API had been redacted to eliminate these sensitive fields. The founder released a public statement detailing the incident, which is available here.
This is a rather epic example of API 03:2019 — Excessive data exposure. The obvious advice is to ensure that your API never returns any sensitive or security-related information.
Breach: 15 million user profiles scraped from Trello
The other big news this week is the leakage of PII (usernames and emails) from the Atlassian-owned Trello platform. The breach is believed to have affected over 15 million users and potentially opened up opportunities for spear phishing attacks. Atlassian committed to improving its API security but stressed that no other user profile data was divulged.
An attacker discovered that they could abuse an API that allowed for the sharing of Trello boards by submitting a target user’s email address. The API would then return a list of all boards associated with that email, which allowed them to associate usernames with the corresponding emails. Trello has since moved to restrict access to this API, and it can no longer be used to query arbitrary user profiles. Atlassian also intimated that all impacted emails had previously featured in breaches and thus were already in the public domain. Troy Hunt’s own research seemed to indicate this was the case based on Have I Been Pwned data extracts.
If you are a Trello user, I would suggest checking if you (like I was!) are on the list.
The lesson here is to be wary of public, unauthenticated APIs that allow the enumeration of parameters, as they can easily be weaponized against you.
Vulnerability: Over 18,000 API secret tokens leaked
The next article features the findings of the Escape Tech security research team on the prevalence of leaked API secret tokens. By analyzing over 189 million URLs, they found over 18,000 exposed API secrets, of which 41% were deemed to be highly critical, leading to financial risk to organizations.
The article describes the methodology used in the research, and the details will appeal to the technically minded. In determining the URLs to parse, they picked a set of popular domains and spidered out from the domain roots. They avoided parsing any government, educational, and health-related domains. The researchers acknowledge that their dataset is relatively small and may not be entirely representative.
The statistics are impressive — over 189 million URLs were scraped in 69 hours with 150 concurrent processes. The whole scanning engine was built by a single engineer in three days. Once the data was collected, it was sanitized using pattern matching and custom heuristics. Upon discovering a potential positive finding, the team reached out to the owner to alert them. The researchers emphasized the importance of reducing false positives to prevent unnecessary panic.
This is an illuminating piece of research and adds weight to many expert opinions that token leakage is emerging as a top threat to API security.
Vulnerability: API leakage reveals Office 365 account details
Our final vulnerability this week features some excellent research from Eaton Zveare detailing his work in identifying a vulnerable API that allowed access to an Office 365 account (and, with it, 650,000 sensitive emails).
The researcher discovered that the Toyota Tsusho Insurance Broker India (TTIBI) provided a mobile application for calculating car insurance premiums. By analyzing the application behavior, he determined that the client sent an API request to the server to send an email using a standard “no-reply” service account email. Seeing that the API call used Bearer Authorization, he assumed that attempts to subvert this API would be unsuccessful without a token. To his surprise, he discovered that the API responded with a success status and also an email sending log. In the log, he found a Base64-encoded password for the associated email account. No way, I hear you say.
Using this password and the email address, he could use the Office 365 portal to access the email account and the 650,000 emails in the mail folders. Six months after his disclosure to TTIBI, the password had still not been changed, and he could still access the account.
This is a great example of two OWASP Top 10 API security blunders that are often associated with one another — API 02:2023 — Broken authentication and API 03:2019 — Excessive data exposure.
Guide: Securing APIs with Spring Boot
The Spring Boot Java-based framework is among the most popular for implementing APIs, and this guide provides details on how to implement basic authentication. Although basic authentication is not a preferred mechanism for API authentication, this guide illustrates many of the important techniques to enable authentication mechanisms on Spring Boot.
The steps are relatively simple and include:
- Adding a custom controller that provides the endpoint to be secured.
- Add a Basic Auth configuration class.
- Add a filter, password encoder, and authentication endpoint.
If you are new to Spring Boot, this tutorial is an excellent starting point to learn the basics of authentication.
Article: Protecting APIs from BOLA, BOPLA and BFLA
Earlier this month, 42Crunch hosted Philippe de Ryck in a popular webinar on the top things you need to know about API security. To accompany this webinar, they have published a blog post that provides nuggets from the discussion around protecting against the following pervasive API threats:
- Broken Object Level Authorization (BOLA)
- Broken Object Property Level Authorization (BOPLA)
- Broken Function Level Authorization (BFLA)
As ever, Philippe’s advice is worth heeding when it comes to securing your APIs.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
