Back in 2010, I published an article called The Nine Circles of Responsible Vulnerability Disclosure Hell where I talked about the general problems frequently encountered when trying to point out security flaws in applications and services that are used by a lot of people. Basically, it was a mild rant about the various hoops any security practitioner has to jump through when he discovers a vulnerability, especially if it’s in a public or widespread application.

Since then, the earth has kept on spinning and we’re dealing with what are essentially the same issues, but in a new playing field. Android and iOS, being two major mobile operating systems, provide easy access to millions of apps via their respective online stores. Apps have never been such a huge part in everyday life. Apple frequently publishes the most popular apps from various countries, but if you need proof, take a look at your Facebook feed or just get on a train and watch what people are doing on their phones.

Since I wrote that piece in 2010, I also changed my attitude towards certain things – or at least I’m trying to. I try to spend less time being angry or frustrated and more time getting actual work done. So today, I generally don’t care too much about ignorant corporations not responding to emails containing significant vulnerabilities in their products anymore. I choose not to waste my time by trying to argue with someone who is not willing to listen.

However, that does not mean that those corporations got any wiser since then. Recently, a mobile application called SnapChat made the news quite often. Before anything else, the concept of SnapChat created quite a bit of turmoil: Users can send messages and pictures to each other that will self-destruct after a certain time. Which, who would have thought, was primarily used for sexting, a word combination of sex and “texting” which is apparently fairly common among today’s teenagers and tweens. Whatever floats your boat, I guess.

The first problem SnapChat encountered was fairly obvious: The general concept of self-destructing pictures is pretty ridiculous on a device that can take screenshots using a simple button combination (we have successfully compromised a similar system back in 2011). SnapChat countered that problem by letting the user that sent picture know, that the receiver has taken a screenshot. Which, I’m sure, has led to some interesting conversations about trust and whatnot. Despite these problems, SnapChat kept growing and became a pretty popular app in general. Up to the point where Facebook tried to buy SnapChat for a whopping three billion US dollars and got turned down.

It’s no secret that attentive security-minded folks – both the malicious and the professional kind, as well as the combination of both these attributes – are more likely to take interest in popular applications with a large user base rather than some small utility nobody really uses. So back in July, a group called Gibson Security located in Sydney, Australia, has taken an interest in the inner workings of SnapChats Android application.

And of course, they didn’t have to look too hard. I won’t bother you with the details, which can be found online in a recently posted full-disclosure document, but GibSec didn’t just find some unsettling information about the encryption being used, which would allow SnapChat to intercept and store pictures being sent. On no, they also found a bug in the SnapChat API, namely the function find_friends that allows the application (or any HTTP client, really) to check if a phone number is attached to an account.

Why is that a bad idea? Well, phone numbers are a fairly uniform construct and only have a limited amount of complexity. Take Swiss cellphone numbers: In Switzerland, we currently have four common prefixes, 079, 078, 077 and 076, followed by 7 digits. Following that logic, it would take thirty million requests to enumerate every single Swiss cellphone user and find out his username. That sounds like a lot, but frankly, it’s really not.

While I think GibSec has done a great job finding and documenting the issues of the SnapChat app, one should keep in mind that this is really a fairly trivial bug that is mainly caused by sloppy programming and the associated lack of clear secure development policies. Without a doubt, someone else would have found and exploited that bug at some point. But GibSec did not. They contacted SnapChat back in August. They provided the details of the problem and even offered help in fixing it. But SnapChat didn’t listen, so GibSec turned to the public, providing all the information on the flaw, probably hoping to create larger public pressure for SnapChat to deal with the issue. Still, nothing happened. Until something else happened right at the end of 2013.

On December 27th, SnapChat finally reacted to the full-disclosure document GibSec put online. In blog post, they implied GibSec wouldn’t honor responsible disclosure and that the bug being reported was already mitigated. On New Year’s Eve, most likely challenged by the cynical blog post SnapChat had posted before, snapchatdb.info provided a database containing 4.6 million usernames with the associated US phone numbers, two digits being censored to protect the victims up to a certain degree. For obvious reasons, this causes some serious turmoil and quickly got picked up by media outlets and on various social media channels.

Here is a piece of advice: Ignoring something does not make it go away. Especially if you’re vulnerable to an exploitation mechanism that is that easy to pull off, fixing this vulnerability should be a priority, especially if your user’s personal information is at stake. Claiming that you fixed something will most likely inspire someone to prove you wrong. And that’s exactly what happened here.

SnapChat reacted again on January 2nd, providing some insight on the incident in a blog post. Again, the writing mostly implies that somebody is bullying them and deliberately puts their users at risk. Not with one word does SnapChat acknowledge, even after the damage is done anyway, that any part of the responsibility for what happened could be with them.

Finally, last Thursday, almost half a year after the discovery of this bug, SnapChat finally announced the update that would allegedly fix this issue for good. They even issued an apology to their users, of questionable sincerity, but I guess 4.6 million users will just have to take what they can get.

The conclusion of all this is clear: Despite all the changes our world is undergoing, we need strong disclosure processes more than ever. The more integral technology becomes in our life, the higher the risk of a vulnerability actually hurting people becomes. As security professionals, I consider our ethical obligation to care about vulnerabilities affecting the general public. However, I don’t necessarily see it as our obligation to help the people who cause those vulnerabilities, but the people who are affected by them.

Full-Disclosure is not the best first move. But as a last resort, it will always an have its place. Rightfully so.

About the Author

Stefan Friedli is a well-known face among the Infosec Community. As a speaker at international conferences, co-founder of the Penetration Testing Execution Standard (PTES) as well as a board member of the Swiss DEFCON groups chapters, he still contributes to push the community and the industry forward.

Links

• http://blog.snapchat.com/post/71353347590/finding-friends-with-phone-numbers
• http://blog.snapchat.com/post/72013106599/find-friends-abuse
• http://blog.snapchat.com/post/72768002320/find-friends-improvements
• http://blog.stfn.ch/2010/08/the-nine-circles-of-responsible-vulnerability-disclosure-hell/
• http://gibsonsec.org/snapchat/fulldisclosure/
• http://mashable.com/2014/01/06/snapchat-facebook-acquisition-2/
• http://www.cnn.com/2014/01/01/tech/social-media/snapchat-hack/
• http://www.handelszeitung.ch/bildergalerie/die-beliebtesten-iphone-apps-aller-zeiten
• http://www.snapchatdb.info/