Another API Security Breach: Life360
It’s not always Logical
Another day, another API breach in the news. The latest breach occurred on the Life360 platform where an advisory was able to gleam 400k user phone numbers, based on the article written on Bleepingcomputer.com.
Known only by their 'emo' handle, they said the unsecured API endpoint used to steal the data provided an easy way to verify each impacted user's email address, name, and phone number.
"When attempting to login to a life360 account on Android, the login endpoint would return the first name and phone number of the user; this existed only in the API response and was not visible to the user," emo said.
"If a user had verified their phone number it would instead be returned as a partial number like +1******4830."
In other words, the attacker was able to take advantage of the API providing too much information. I’m sure that the Android development team never thought that someone would use an emulator or proxy to look at the actual traffic being returned by the API. Instead, they figured that by not displaying this information in the app, though it was in the API, they would be secure. Security by obfuscation is not good security. This would be classified as an OWASP API Top 10, #3 attack “Excessive Data Exposure.”
Breaches like this happen more often than we care to admit. Often, mobile apps leverage their environment limitations to hide data instead of preventing that data from being released in the first place. In a very similar case, an app called 3Fun (more info here) exposed the location and private pictures of its users through their API, though the mobile app did not show this information.
Salt Detection
In this specific situation, I asked our VP of security research, Yaniv Balmas, what would Salt have been able to detect.
Yaniv stated that Salt could detect one of several opportunities, but the most relevant ones would probably have been parameter enumeration (specifically enumeration that also returns sensitive data). He also stated that since this would be seen by Salt as a unique activity for this attacker that deviates from the normal user behavior, it would have triggered a Single-ID BOLA alert.
The capability of Salt to detect and correlate this type of activity is not something easily done. It's like trying to find a needle in a stack of needles in a stay of hay in a barn full of hay. Our unique architecture and patented detection modules are the reason why we help some of the largest enterprises protect their APIs.
If you would like to learn more about Salt and how we could provide you with API discovery, governance, and protection, please contact us, schedule a demo, or check out our website.
