Leaky Spoutible API Exposes User Data: What Went Wrong?

At FireTail, we usually say that two or more things need to go wrong in order for attackers to be successful. So what went wrong with Spoutible's leaky API? Basically, everything.

Into The Breach

Spoutible, a social platform birthed in the wake of Elon Musk's tumultuous takeover of Twitter, found itself at the center of a data security storm. Security consultant Troy Hunt was alerted to a vulnerability in Spoutible's API, revealing a cascade of personal data that left users vulnerable to account hijacking and privacy breaches. In total, more than 207,000 users were exposed by this unsecured API.

The Anatomy of the Flaw

As mentioned, there were a whole litany of failures that contributed to the severity of this vulnerability. We've zeroed in on 4 of the biggest...

1. Authorization Oversight

The vulnerability stemmed from a glaring lack of authorization checks within Spoutible's API. By simply accessing a URL with a victim's username, attackers could access a treasure trove of sensitive information. The absence of robust authorization mechanisms laid bare the vulnerability to exploitation, allowing unauthorized access to user data with alarming ease. Here's the URL in question:

https://spoutible.com/sptbl_system_api/main/user_profile_box?username=[USERNAME]

So, anyone could view the details of another user, just by providing the victim’s username to the URL. The results included:

id
username
fname
lname
email
email_conf_code
password2fa_secret
2fa_enabled_at
2fa_backup_code
ip_address
country_id

Note that em_code is the password reset code. This means that an attacker doesn’t need to crack the password hash, just use this code to change the victim’s password.

2. Excessive Data Exposure

Compounding the issue was the API's tendency to indiscriminately expose sensitive information. As shown in the list above, password hashes, 2FA backup codes, and IP addresses were all freely accessible to anyone with the know-how to exploit the flaw. This excessive data exposure is mind-blowing. The enormous magnitude of the disaster could have been avoided if the API wasn’t unnecessarily returning such sensitive information.

Even without the authorization issue, things such as 2fa backup codes, secrets, ip addresses and particularly password hashes should never be handed to the end user like that. Also, this indicated that all of the validations and information is being handled on the client-side. Crazy.

3. Lack of User Security Oversight

To add to this comedy of errors, Spoutible also lacked a fundamental feature that might have helped users spot unauthorized access to their data: an active session overview. This would have allowed the user to see if there were any active sessions for their account on other devices. But this was another security feature Spoutible lacked. There was no way for a user to know if someone had broken into their account...except that is, until they were unable to log in because someone changed their password :(

4. Elusive Detection

The public-facing nature of the vulnerable API made detection of abuse extremely difficult. It's a vital part of the application, with the endpoint being routinely requested during user sessions. As such, distinguishing legitimate traffic from malicious exploitation would have been really hard.

Learning from the Spoutible Saga

The incident is yet another stark reminder of the critical importance of robust API security practices. From authorization controls to data exposure policies, organizations need to adopt a proactive approach to protecting their APIs against exploitation. As the digital landscape evolves and APIs grow evermore prevalent, API security should be a top priority for infosec teams everywhere.

This great white whale of an AI misconfiguration was first reported to Tony Hunt of Have I Been Pwned. You can check out his brilliant and detailed analysis here.