For many, however, the question has been whether Snapchat did enough to protect its users by securing against unaffiliated apps on a technical level. The biggest issue is that Snapchat has no official API, but its unofficial one is an open secret widely circulated on the web. That means Snapchat is reliant on other companies like Apple and Google to ultimately police which apps are safe and available. Since 2012, security researcher Adam Caudill has been warning that the company's API had several serious security flaws, something numerous other researchers have seconded.
We spoke with a developer, Alex Forbes-Reed, who says he had no trouble recently reverse-engineering Snapchat's API for his own application, and he suspects it was easy for engineers at SnapSaved, the source of the allegedly stolen photos, to do the same thing. (SnapSaved has acknowledged that it was hacked, although it disputes the amount of data that was stolen.) What follows is an interview with Forbes-Reed about his experience building an unofficial Snapchat app.
How did you reverse-engineer the Snapchat API?
I installed the official Snapchat app on my iPhone, set up an application called Charles on my laptop (this is a network sniffer, it allows me to monitor all traffic going though my home network), and installed a custom certificate (created by Charles) on to my device. That certificate signs all the "secure" https traffic going through my device again, which allows Charles (on my PC) to monitor the encrypted traffic and see what's going on inside it.
Then I started using the application like usual, and inside Charles' UI, I can see the requests the application makes, and what it sends and receives in each of those said requests.
"The second that image goes to the Snapchat servers, it's no longer private."
What protections does Snapchat have in place to prevent that?
Like I previously said, all traffic is https (already better than Instagram, where a friend of mine Stevie Graham found a way to exploit it via a single http endpoint), but they have a binary pattern that is used to generate a unique key for every request. The issue is this binary pattern is stored in the application, and is always the same for every user — also someone had already posted it online so I didn't even need to look into the iOS executable to extract the key — so at this point, I was able to just start sending requests to snapchat and it had no idea the requests were not coming from the official clients.
What app, or kind of app, were you creating?
It is a third-party Snapchat client for Windows Phone — doesn't have any features Snapchat doesn't want, so you can't save snaps, etc.
What could Snapchat have done to prevent you from doing this?
In terms of accessing the API, there isn't much they could have done. Maybe if they moved towards using OAuth, it would have slowed down researchers, but it wouldn't have stopped them. If you look at Windows Phone' store for example, it's lacking a serious amount of first-party apps, but people have made third-party ones anyway. Every company is a victim to this potential attack vector.
"There are still exploits in the API, and it's up to Snapchat to fix those before they can be exploited."
Would it have required a fundamentally different architecture from the start?
There are ways Snapchat could clean up their API, definitely. Version it, so they could update the API without breaking previous versions of the application — currently they can only hack on new endpoints / variables. Also, currently every snap, it encrypted with the same AES key — there isn't much that can be done about this as it would break support for older clients. Add rate-limiting to accounts, so one account can't spam messages and snaps. (This would cut down on that ghastly snapchat advertising spam.)
All that being said, if you compare the current state of Snapchat's security to what it was even six months ago, it's improved a lot. They have patched a few major issues — involving getting phone numbers from users, and mass registering account. But there are still exploits in the API, and it's up to Snapchat to fix those before they can be exploited.
Are third-party apps — like the ones allegedly hacked — inherently less secure than the official Snapchat app? If so, why?
Yes, by their very definition. When something isn't first-party, you have no guarantee that the code you can't see isn't doing something malicious. In the case of Snapchat, any third-party application could be saving your account's authentication token and remotely pulling snaps from your account. Or collecting lists of your friends for spam. Or getting access to your email address and phone number and selling it on. With first-party clients, everything it does is in the terms of service, and you can generally trust companies to not break those, as the risks are huge.
With third-party apps, breaking the terms of service isn't risky at all. I could publish an app to the App Store that breaks my own terms or conditions, and the worst thing that will happen to me (depending on severity) will by my application gets pulled from the App Store. Hardly punishment at all.
What do you think is the best solution / approach for app developers who want to protect their users, but also foster an ecosystem of third-party apps?
Make it open. If Snapchat went the way of Facebook, Twitter, and hell, even Yo!, all third-party apps would have their own authentication tokens, and if an app was caught doing something malicious, they could revoke the tokens and that application would be dead. Right now, all they can do is ask Apple / Google / Microsoft to take it down — which takes time and still means the app could cause issues to end users. They would also be able to see which apps were doing what and those analytics can show Snapchat if an application is doing something that looks malicious.
Russell Brandom contributed to this report.