Posters to 4Chan’s /b/ forum continue to pore over the contents of thousands of images taken by users of the Snapchat messaging service that were recently leaked from a third-party website. Meanwhile, the developer behind that site, SnapSaved.com, used a Facebook post to say it was hacked because of a misconfigured Apache server. The statement also gets into the extent of the breach, while playing down reports that personal information from the users involved was also taken.

“I sincerely apologize on behalf of SnapSaved.com,” the developer’s spokesperson wrote. “We did not wish to cause Snapchat or their users harm, we only wished to provide a unique service.”

SnapSaved’s developer said there was no substance to claims by some 4Chan posters that a searchable database of the images stolen from the service’s server was being developed. “The recent rumors about the snappening are a hoax,” the developer wrote. “The hacker does not have sufficient information to live up to his claims of creating a searchable database.” The developer also said that the service actively “tried to cleanse the database of inappropriate images as often as possible…SnapSaved has always tried to fight child pornography, [and] we have even gone as far as reporting some of our users to the Swedish and Norwegian authorities.”

In other words, SnapSaved was apparently manually reviewing the photos that passed through the website.

Unintended consequences

SnapSaved, which ran on a server hosted by HostGator, largely served users in Sweden, Norway, and the United States. It used a reverse-engineered version of Snapchat’s internal application programming interface (API), which allowed Snapchat users to view and download images sent to them by others through the website—and to circumvent the “instant deletion” feature of Snapchat’s own mobile app. The users who sent the images were not made aware that the recipients were using the site to save them.

As Ars reported last week, Snapchat's internal API was exposed over a year ago and incorporated into a PHP library by developer Thomas Lackner. Snapchat tried to get the library pulled from GitHub, claiming the code was in breach of the Digital Millennium Copyright Act, but it remains available. A number of mobile applications have used the reverse-engineered API to allow users to store images sent via Snapchat to their local image collection—but none of these other applications offered Internet storage as an option.

SnapSaved.com, however, did just that, saving images in the file system of their Apache server and indexing them with a database. Because of the configuration of the Apache server, however, someone was able to retrieve the contents of the site’s image store. However, the spokesperson for SnapSaved claimed that the database storing user information was not breached. “As soon as we discovered the breach in our systems,” the spokesperson wrote, “we immediately deleted the entire website and the database associated with it. As far as we can tell, the breach has effected [sic] 500MB of images, and zero personal information from the database.”

Not our problem

Snapchat has yet to comment on its role in the leak, other than to reiterate in statements to the press that its servers were not breached and that the fault lies with the developers of SnapSaved and its users—third-party viewer applications are a violation of Snapchat’s terms of service. Ars made several inquiries to Snapchat regarding the security of the company’s API, but received no response.

Part of the problem is that the encryption keys used to protect Snapchat’s communication channel, and the files transmitted over them, are hard-coded into Snapchat’s apps in a way that can be retrieved relatively easily by anyone trying to reverse-engineer the app’s functionality. The Snapchat API also uses AES in Electronic Codebook (ECB) mode—the weakest form of AES encryption for use with a single key, one susceptible to frequency analysis. While that's wrapped in an SSL session, the keys used to establish that session are also relatively easily extracted from Snapchat's app code.

In June of 2012, while pointing out a number of security issues with Snapchat’s API, developer and security researcher Adam Caudill said that “a crappy but functional Android client that supports saving could be built in a couple hours.” He said unauthorized Snapchat clients were “unavoidable…especially as the service grows in popularity.”

However, other developers of “ephemeral messaging” products like Snapchat have found ways to secure their APIs better (though they may be less convenient for users as a result). Wickr, Silent Circle, and Glimpse combine keys generated by users to encrypt content with AES with “pinned” certificates for Transport Layer Security, complicating the encryption process for the content and making it much more difficult to use a man-in-the-middle to intercept images and text. The additional key generation means their clients are more complex than Snapchat’s and more difficult to reverse-engineer. That doesn’t mean that they’re uncrackable, but it does raise the effort required to crack them by several orders of magnitude compared to Snapchat’s system.

Update 12:24 PM EST:

An individual going by the name "Riot" and claiming to be "an anonymous freelance security researcher" contacted Ars by e-mail offering to sell a full data analysis of a torrent of the "Snappening" files.The files in the dump span a year,from October 3 of 2013 to October 9 of 2014.

"Riot" claims that the contents of the torrent appear to be the full contents of the server, based on timestamps and other data, and includes 88,521 still images and 9,173 videos, totalling 12.9 gigabytes. "It does not appear to be possible to correlate files to snapchat usernames in the majority of cases," he said in an email to Ars, "with the exception of 320 usernames for which files have been saved in a different naming format, specifying the username in each case." Those 320 usernames have been posted to Pastebin.

Update 3:00 PM EST:

An Ars reader has independently confirmed the presence of 3,999 images stored by username in the SnapSaved.com data, though he found 400 usernames in total. "The other 84k images and all 9k videos are City/Firstname/Lastinitial," he wrote—meaning, likely, that those files were stored by specific SnapSaved users in their personal folders based on their site registration data and not their Snapchat usernames.