On New Year’s Day of 2014, the usernames and phone numbers of approximately 4.6 million Snapchat users were published on the internet, likely using a technique inspired by Gibson Security’s analysis of SnapChat APIs. Predictably, Snapchat issued a response downplaying the incident, implying that their application was abused in violation of their terms of service. While they are technically correct that they were abused rather than hacked, their application was nonetheless attacked and there are still some ramifications that arise from 4.6 million users having their data published on the web. Additionally, allowing arbitrary users to convert phone numbers into usernames provides penetration testers with an additional source for information gathering.
But it’s not sensitive data!
One might be quick to dismiss the significance of the 4.6M phone number/username combinations released on the web. After all, it’s JUST phone numbers and usernames… No passwords, credit cards, or any other confidential were obtained. Additionally, whomever released the list redacted the last two digits of each phone number, limiting the usefulness of the dataset. But, there is enough data there to do some analysis, and Snapchat’s API still allows for phone number and username harvesting. We’ll break each of these points down separately.
4.6 Million Usernames
Even without passwords, allowing arbitrary users to harvest usernames can cause some serious issues. First, it allows us to verify whether or not a user exists in the system, giving us a nice clean list of accounts that we can now use to bruteforce passwords; no need to waste time trying to guess usernames.
However, in the spirit of
laziness working harder, why not use previous data breaches to connect usernames to passwords? Users tend to have a pretty bad habit of reusing the same password across many different accounts. As an example, let’s compare these usernames with the data from the Yahoo data breach of 2012, where 400K+ passwords and usernames (in the form of email addresses, including gmail, hotmail, etc) were stolen and released on the internet. For the sake of analysis, I extracted everything to the left of the ‘@’ of each email, giving me a list of potential usernames. I then compared the Snapchat usernames to the Yahoo usernames to see how many there were in common.
A total of 3893 unique usernames existed in both datasets.
While some of these matches may just be coincidental, others are likely the same user on both services. For example, a username of “John” in both databases probably aren’t the same user as the name is just too common. However, we can be reasonably assured that a username of “RainbowPony1996″ in both databases is the same person. (Both “John” and “RainbowPony1996″ are made up examples, and not from the databases). Regardless, if we wanted to compromise Snapchat users we now have 3893 username/password combinations to try. Maybe one of the users happens to be an admin or developer, which might give access to additional functionality in the applications. None of the 3893 credentials were actually used to try to log in, as that would be considered unauthorized access.
For a penetration tester, Snapchat’s API (specifically the “Find My Friends” functionality) can be useful as we try to compromise user accounts for a client’s network or applications. Let’s say, for example, that we were able to harvest a list of mobile phone numbers associated with our client’s employees. This can happen by getting access to an office roster, online directory services, email signatures, etc. We can then use the script developed by Gibson Security to check to see if any of those phone numbers are associated with Snapchat usernames. If they are, we can check to see if those usernames were involved in any other data breaches where passwords were exposed, hopefully providing us with a list of passwords used by some of our client’s employees. It is very likely that the Snapchat username and the corporate username are different, but we know the name of each user and can pretty easily guess the username (firstname.lastname, first initial last name, etc).
With all of this information in hand, we now have some user credentials that we can use to try to gain access to the client’s applications and infrastructure. If we are lucky, some of the users will be reusing the same password across both corporate accounts and the compromised services, and will gain access. If we are really lucky, they will be admin or some other privileged user.
While the techniques described above depend a bit on luck and may be of limited usefulness, they are yet another tool in the pentester’s toolset for open source intelligence gathering and user attack vectors.
The bottom line is that allowing arbitrary username enumeration is bad, no matter how you look at it. If you want to allow user lookups in your application, assign an arbitrary token or other identifier to each user and use that for your “Find My Friends” functionality. Companies who develop web applications must take care to protect all of their users’ data, not just the sensitive stuff. Allowing access to usernames and then hiding behind the “they violated our terms of service!” argument is unacceptable; do more to protect your customers*.
*We could be cynical and say “but they are using the service for free, they aren’t actually customers!” Ok, fine. If the users of your free application are actually your product (for ad revenue, etc), you still have to protect your product…