Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gigabytes of user data from hack of Patreon donations site dumped online

arstechnica.com

Post reply on HN
Print view View original

61–70 of 151 posts

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#61

Post by JulianMorrison »

mpeg wrote: post #50
JulianMorrison wrote: post #41

Earlier quoted context omitted.

Yeah. I feel like an ideal architecture would be to use NSQ and transmit not queries, but a minified JSON bundle of query "name" with query parameters. Then have stateless DB service nodes preloaded with canned, named queries on secured VMs whose only access to the outside world is NSQ. Bonus, you can tap off DB requests with an ephemeral channel and log them.

That sounds like SOAP + SQL Server stored procedures (full replication mode to log db requests, then monitor any SQL queries). I'm assuming other vendors have similar set ups. I've ran systems like that, and I'm glad things are a lot easier to maintain now (stored procs are a pain in the ass, whether they exist in the database or in the app layer). Query injection is solved by parameterising queries (never sanitising…

Your SQL is going to be "stored" one way or another, whether it's implicitly in the internal workings of an ORM, explicitly in code or mybatis style config, or explicitly in the DB. I think isolating it into data workers, and making them feed off a high throughput message queue (hiding restarts), minimizes the amount of redeploying needed.

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#62

Post by icebraining »

Udo wrote: post #53
icebraining wrote: post #42

Earlier quoted context omitted.

If the frontend layer needs to access the data anyway, how does that separation help? And why is it easier to monitor for unusual activity?

> If the frontend layer needs to access the data anyway, how does that separation help? It helps in multiple ways. Since you define the data API yourself, you can tailor it tightly to only the exact operations you need. This makes it more difficult to flat-out drain everything (or even query everything, depending on your app). It's also another layer of insulation. The fact that it's another, non-standard access prot…

> Since you define the data API yourself, you can tailor it tightly to only the exact operations you need. This makes it more difficult to flat-out drain everything (or even query everything, depending on your app).

Considering that the database was designed specifically to support the website (so it's not supposed to have unrelated data), and that the frontend intermediates all access to the data, wouldn't the sum of the operations require access to all data? Why would you have data that was not needed by the website?

> If I'm an attacker, I'll probably have a harder time figuring out how the custom data layer works

This is just security by obscurity, except if the attacker has access to the client code, it's not even very obscure. Finding all calls to the backend API is a trivial task nowadays.

> Because you know what the legitimate access patterns of your app look like, you can raise flags programmatically.

Why can't you do that from the database logs? A query is just like an API call - you can raise flags if the frontend makes queries outside of a known pattern (ie, non-recognized queries or in an unexpected order).

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#63

Post by greggman »

callesgg wrote: post #31

So what of importance is in their database that one could not find by otherwise searching the web? From the email i received from patreon i reckon the only actual private thing is the exact sum i pay to who. Some find addresses to be private, but at-least in my case any one can find where i live by looking on the local yellow pages website.

There are plenty of adult content artists that some people might rather not have others know they're supporting. Especially if that adult content is out of the ordinary.

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#64

Post by icebraining »

raesene4 wrote: post #57
icebraining wrote: post #52

Earlier quoted context omitted.

I don't think it's actually that bad; for example, Patreon said that they don't store CCs and that they correctly hashed passwords, and as a consumer myself, I did take that into account. Obviously less knowledgeable consumers don't know what "bcrypt" is, but that's true of any product - you can't judge what you don't know how to judge.

so with two patreon style sites both of which say "we take security seriously" , until they have a breach, how would you judge which one would take better care of your data? The information (AFAIK) about their security mechanisms only got released as a result of the breach, so even assuming you knew what the terms were and how to judge good security from bad, you wouldn't have the information until the site got compr…

The information that they didn't store CC cards was available in FAQs previously: https://patreon.zendesk.com/hc/en-us/articles/203913779-Do-y...

The password hashing algorithm wasn't, but then again an informed consumer uses unique passwords for each site, so that's less relevant.

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#65

Post by Udo »

icebraining wrote: post #62
Udo wrote: post #53

Earlier quoted context omitted.

> If the frontend layer needs to access the data anyway, how does that separation help? It helps in multiple ways. Since you define the data API yourself, you can tailor it tightly to only the exact operations you need. This makes it more difficult to flat-out drain everything (or even query everything, depending on your app). It's also another layer of insulation. The fact that it's another, non-standard access prot…

> Since you define the data API yourself, you can tailor it tightly to only the exact operations you need. This makes it more difficult to flat-out drain everything (or even query everything, depending on your app). Considering that the database was designed specifically to support the website (so it's not supposed to have unrelated data), and that the frontend intermediates all access to the data, wouldn't the sum o…

> wouldn't the sum of the operations require access to all data

How you can access the data matters, and typically not all data (nor all views to that data) are required to run the app. Some info should only ever travel one way (typically from the web server to the backend, like passwords, analytics, or payment data). There are whole categories of information that do not ever need to be queried in bulk by a legitimate user.

> This is just security by obscurity, except if the attacker has access to the client code, it's not even very obscure.

It's not like this approach in any way relies on that obscurity, but as a measure to increase time and effort required by the hacker, I'll take it. Just increasing the time spent figuring out how to query the backend gives site operators additional opportunities to spot that something is wrong. Compare this to the immeasurably small effort required to dump all SQL tables into a text file.

> Why can't you do that from the database logs?

Typically logs aren't analyzed in real time, and I'd hazard a guess in most cases they're not even analyzed at all. Most databases don't even keep an access log by default, and in many cases it's hard to implement one that is useful.

> A query is just like an API call - you can raise flags if the frontend makes queries outside of a known pattern

Theoretically: yes, practically: no. In case of SQL databases, this would practically mean communicating with the DB exclusively through stored procedures (or event handlers/filters in case of document databases), which is a poor man's version of what we're talking about in the first place. In practice, almost nobody uses their database in this way, because it's really painful and does not even offer that much protection.

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#66

Post by dspillett »

RyanZAG wrote: post #38
dspillett wrote: post #17

Earlier quoted context omitted.

> the problem is, if you intend to use the data within the application, you need to be able to decrypt it ... which requires the encryption keys to be know at the point of use - but it doesn't mean that they need to be kept with the database. It doesn't necessitate asymmetric encryption either. If you keep the keys in a different location, completely away from the database server(s), then a compromised database or ba…

As others have said, this appears to be a total dump of the system and not just the database. It looks like the encryption keys were not kept with the database, but all of the SSL keys and everything are included inside the full dump. Seemingly it was another server with the keys that was dumped too. The only way to protect against this would be some type of hardware key store with limited access to all employees and…

If the keys are only ever held in memory then getting a dump of all the stored data from all the database and font-end servers would not reveal the keys.

To achieve that you would need human interaction to bring up a new box (or after an existing box is restarted) in order to hand over the keys (if the server could request the key from somewhere on the local network, then perhaps so can an attacker if they get access to run arbitrary things rather than just getting access to the filesystem or a copy thereof) which might be impractical for some environments, but it is possible.

For instance when my offsite backup server reboots it can't access the encrypted volumes until I login to mount them manually, sending the keys over SSH in such a way as they don't get stored.

The weak point then becomes the humans and the process they use to transmit the keys from the keystore to the servers.

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#67

Post by BurningFrog »

icebraining wrote: post #64
raesene4 wrote: post #57

Earlier quoted context omitted.

so with two patreon style sites both of which say "we take security seriously" , until they have a breach, how would you judge which one would take better care of your data? The information (AFAIK) about their security mechanisms only got released as a result of the breach, so even assuming you knew what the terms were and how to judge good security from bad, you wouldn't have the information until the site got compr…

The information that they didn't store CC cards was available in FAQs previously: https://patreon.zendesk.com/hc/en-us/articles/203913779-Do-y... The password hashing algorithm wasn't, but then again an informed consumer uses unique passwords for each site, so that's less relevant.

Many informed customers - perhaps most - use the same passwords on many sites because it's too hard to remember hundreds of passwords.

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#68

Post by BurningFrog »

Udo wrote: post #32

There is a lot we can do as programmers to make data leaks of that scope a lot harder to pull off. I think web apps of a certain magnitude should not be talking directly to the database, they should be talking to their internal data API that resides on a different server. The reason for this is that a completely separate data layer is easier to lock down, and also way easier to monitor for unusual activity. Ideally,…

This sounds like a fair amount of added complexity for unclear benefits in security.

Also, if someone hacks into the DB server, it is all meaningless.

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#69

Post by rasz_pl »

callesgg wrote: post #31

So what of importance is in their database that one could not find by otherwise searching the web? From the email i received from patreon i reckon the only actual private thing is the exact sum i pay to who. Some find addresses to be private, but at-least in my case any one can find where i live by looking on the local yellow pages website.

You can look up who sponsored Lara banging a horse for example.

Re: Gigabytes of user data from hack of Patreon donations site dumped online

#70

Post by caio1982 »

dublinclontarf wrote: post #22

I'm wondering what their setup is? Are they running on their own machines? AWS? Heroku? From looking at their careers the use PostgreSQL/MySQL, Python, Scala, Ruby, Node. I am assuming because of the nature of the breach that they are running their own servers (either on AWS or their own machines), it's a completely compromised server which had access to everything.

It doesn't tell you everything but it helps: http://builtwith.com/patreon.com
Post reply on HN