Hetzner client data exposed after attack

[Newsfeed]

Hetzner client data exposed after attack

Hetzner has sent a security alert to customers following an attack on the provider.

The company stated that online platforms have been under severe attack in 2018, and despite its “best efforts to stay one step ahead”, a security breach has taken place.

 

[KERU]

Second serious attack on Hetzner. They really need to up their game.

 

[ArtyLoop]

Second serious attack on Hetzner. They really need to up their game.

Guess profit trumps spending on security and hiring the right people to do it.. once again..

 

[quovadis]

So what is the reason for not encrypting sensitive client data?

You can't encrypt everything. I would however love to know who their "cyber security specialists" are - I think they need a refund.

 

[Nobody Important]

After next month-end when people start threads about mysterious debit orders that they have to reverse, just ask yourself if you are/were a Hertzner client.

 

[Temujin]

Again

Third time lucky maybe?

 

[The_Librarian]

wheeeeeeeeeeeeeee, here we go again

 

[kissingmybbgoodbye]

I am seriously considering leaving them now, probably won't be to long before the next breach

 

[quovadis]

What are you talking about? Explain please. You can indeed encrypt everything, but I'm advocating for client's personal data to be encrypted. It's not hard.
Here's a thought. How about:

• Name and email address
• Phone number
• Address details
• Debit order bank account details
• Identity number
• VAT number

I'm assuming the attack would've been from a frontend vector as if this was via a direct database connection it would've been a massively stupid implementation. If you have access to the frontend then you would have access to decrypt the encrypted data in the first place. Thus impractical.

 

[MrGray]

What are you talking about? Explain please. You can indeed encrypt everything, but I'm advocating for client's personal data to be encrypted. It's not hard.
Here's a thought. How about:

• Name and email address
• Phone number
• Address details
• Debit order bank account details
• Identity number
• VAT number

The problem is that at some point in their process that info has to be decrypted and used. So depending on where the breach is, encryption might be moot. For example - the process that runs monthly billing will contain all of that info and will actually create pdf invoices, etc that need to be emailed, etc etc. So there is probably not a lot of point in encrypting it at source, but rather focus on securing all the touchpoints.

 

[quovadis]

What does that have to do with not being able to encrypt info? No doubt it could have been from a front end, but there are a lot of assumptions here... but saying that encrypting data at rest is a waste of time is crazy.

I think you're missing the point. I never said it was a waste of time.

 

[quovadis]

Of course there are a number of attack surfaces to lock down, but as above - how is neglecting one vector to focus on another helpful? Cover all your bases, including attacks from inside. I wonder if they have software for DPI on their own systems.

If you cannot understand my or garp's points then you're misunderstanding the issue.

 

[quovadis]

Are you saying your points are the same?
i.e. "So there is probably not a lot of point in encrypting it at source, but rather focus on securing all the touchpoints. "
That's what I'm assuming here. Help me out.

Data will be decrypted at some stage. If you have access to the data at that stage, you can encrypt the database, have a firewall, dpi, dpi-ssl, unified threat management or whatever in front of the database and it doesn't matter. The data is still exposed at some point.

 

[quovadis]

We've established that, but it doesn't answer the question about encryption being overlooked.
I made an assumption that data wasn't encrypted at rest. Of course we don't know this and it's pure speculation, as you rightly point out, it's not the only way to get data. I agree with that.

Your response was 'you can't encrypt everything'. It's feasable that it was only their invoicing / accounting system that was breached... but just because there's an inherent weakness in one area does not mean you can or should leave the door unlocked in another. All I'm saying is that encrypting data at rest and in transit is as important as dealing with other areas.

I'm not advocating for a non-holistic approach. You can have a completely unencrypted database and still have a secure solution if implemented and secured correctly and it's not "leaving the door open".

My statement for "You cannot encrypt everything" as I stated, is because:

1) You reduce the ability for a database to be queried in an efficient manner.
2) You cannot dictate to your software provider (whether its an accounting system, marketing system or admin system) that they should encrypt your data when and how you see fit.
3) The benefit of doing so is technically worthless if exposed at any other level which has been exploited.

 

[MrGray]

Are you saying your points are the same?
i.e.
That's what I'm assuming here. Help me out.

I'm referring to data that's going to be constantly accessed for statements, newsletter and billing runs - sure, I'm not advocating that it's necessarily held un-encrypted but the point is that so many processes are going to be accessing it and pulling data from it so frequently that encrypting it becomes a marginal benefit. It seems the default position is going to have to be to encrypt entire databases now, anyway, and that's fine, but the point is that this data could then be breached at multiple points - from a mail server queue with statement emails (yes, the attachments can be encrypted, I know) to reports sitting on on a hard drive, to the CMS, to numerous API's and interfaces that need to access that data - the extract into the billing/accounting system etc etc etc. Heck, when you log in to view your own account on KonsoleH, you need to view and edit that info so the website data layer obviously needs to decode it as well. Obviously passes must be hashed, but there will be so many things decrypting your data constantly that will all, by definition, contain the decrypting mechanism that ultimately it's not much more secure than requiring credentials to the database. So my point was just that all of those avenues have to be completely locked down before encrypting the db makes much difference. I would, of course, assume that the backups are encrypted anyway.

 

[quovadis]

<Snip>

Sweevo, with all due respect, if you are going to engage on a forum then do so without editing your posts to add padding to your position, simply add to the thread.

 

[internetless]

As far as I recall from last year's breach, they don't even hash passwords. I haven't seen any indication that it has, but truly hope they have done at least that!

 

[internetless]

I am seriously considering leaving them now, probably won't be to long before the next breach

I moved a bunch of stuff last year, but then thought I'd give them another chance and leave some stuff there. No longer....

 

[quovadis]

It's becoming more and more important to separate and lock down the data layer and address CRUD using an API.

You still have access to the data via an API?

I would hope admin interfaces are only available over a secure VPN or within the intranet.

An admin interface is rarely the vector but agreed.

 

[internetless]

As far as I recall from last year's breach, they don't even hash passwords. I haven't seen any indication that it has, but truly hope they have done at least that!

Oops, I do now recall them saying that they were going to address this, and I see that you can no longer see plain text passwords in konsoleH. Thanks Hetzner.