Crowdfunding site Patreon is the latest in a long line of data breaches.
On 30 September 2015, Patreon founder Jack Conte published a post on the company’s website, fessing up to the incident.
Apparently, the breach was the result of a debug version of the website that was accessible to the public.
According to Conte, Patreon has now shut down the offending server and moved all non-production servers behind a firewall.
→ Here on Naked Security and in Sophos podcasts, we talk about network segregation a lot, especially where development and test servers are concerned. Development servers often either have monitoring features enabled that are not suitable for public exposure, or have unfinished, perhaps even untested, configurations. After all, something that’s “under development” is, by definition, not yet properly finished.
The silver lining is that password hashes seem to have been stored safely:
We protect our users' passwords with a hashing scheme called 'bcrypt' and randomly salt each individual password. Bcrypt is non-reversible, so passwords cannot be "decrypted." We do not store plaintext passwords anywhere.
Bcrypt, as you will remember from the Ashley Madison breach, is designed to make each password guess slow enough that attackers simply can’t try enough to get anywhere, except perhaps for users who chose really obvious passwords that are right at the top any cracker’s “try these first” list.
But it wasn’t just password hashes that were stolen:
We do not store full credit card numbers on our servers and no credit card numbers were compromised. Although accessed, all passwords, social security numbers and tax form information remain safely encrypted with a 2048-bit RSA key.
This part of Conte’s statement doesn’t have the clarity of the comments about password hashing.
Databases aren’t encrypted using RSA, because it’s too slow.
When you use RSA encryption, you encrypt your data with a cipher such as AES using a randomly-chosen symmetric key, and then encrypt just that key using RSA.
Also, of course, the key has to be accessible to the database server while it’s running, so we have to take it on faith that attackers didn’t make off with it at the same time.
Nevertheless, the fact that some of the data was encrypted reflects well on Patreon, breach or no breach.
Encryption isn’t an excuse for you to lose important customer data, but it can seriously reduce the damage if you do.
(With hashed passwords, there is no key that can decrypt the passwords, so there really is no way back to your password without going forwards from a sequence of guesses until you hit the jackpot.)
Unfortunately, there’s a third part to the breach, which only gets mentioned in a single sentence near the top the notification:
There was unauthorized access to registered names, email addresses, posts, and some shipping addresses.
According to reports, that was quite some list of names, addresses, private posts and so on that was spilled – close to 15 gigabytes.
One analyst suggests that the data includes more than unique two million email addresses together with “all the campaigns, supporters and pledges.”
One saving grace for users exposed in this incident is that they will have a lot less explaining to do than users in the Ashley Madison incident.
Unless they’ve privately supported something that is at odds with their public pronouncements, of course…
LINUX SERVER SECURITY – LEARN MORE
Malware on Linux – When Penguins Attack
(Audio player not working? Download MP3, listen on Soundcloud, or read the transcript.)
3 comments on “Patreon crowdfunding site hacked – all it takes is one mistake…”
Why was a dev version of the webapp linked to production data (presumably a clone of the production DB)?
Not only that, but why weren’t the servers behind a firewall to begin with? The world may never know…
Very well written article.