alert Epik Had A Major Breach

[DaveX]

Just read this. Looks like Epik may have been hacked and sensitive data compromised...

Read here:
https://domainnamewire.com/2021/09/14/hackers-claim-significant-epik-breach/

Thought I would share this.

 

[Jurgen Wolf]

what exactly happened

DDoS happened at least.
Was dataleak or not - only review of torrent can say.

 

[Mr Wash]

Still hanging on 5.8% ... for hours. The examples doesn't look like there's something "important". You can easily collect SSH dnssec and other public keys and in-out dn transfer/movement data . That's mostly "good-natured" data.

It is private keys. No, that is not "good natured" data. And SSH has absolutely zero to do with DNSSEC.

 

[Mr Wash]

My CS team confirmed, - it is known that the Archive (is) is being used as a disinfo hub for .... years. The easiest way was/is to manipulate screenshot metadata (f.e. jpg/png source code) but also there's injecting the fw code (no further info) ...

This is inaccurate. Your "CS team" is wrong.

 

[Paul]

I would really like to hear from who I think are the two of the top smartest people on these topics on this forum, @Paul @Michael

It does appear to be real. There's an awful lot of data and I don't have time to comb through it all right now, but here's what I've seen so far for Anonymize users, which is a smaller, more approachable dataset than the registrar data:

1. Passwords hashed with MD5
2. Plaintext passwords (appears to be a small subset, possibly staff)
3. PII, including full physical address, name, email, and phone number

There is probably quite a bit more data--this is just what I've glanced at so far for Anonymize.

The data does not appear faked or generated. There is accurate information that I would not expect to be public or widely known. cc @Lox

We're anticipating a significant increase in credential stuffing attacks as a result of the weak password hashing.

 

[Lox]

This is inaccurate. Your "CS team" is wrong.

Don't know. It can be t they're wrong. I'm not going to bother them w further q.

Regards

 

[Finest]

1. Passwords hashed with MD5
2. Plaintext passwords (appears to be a small subset, possibly staff)
3. PII, including full physical address, name, email, and phone number

Cleartext and MD5!! This is the best they could do?!

 

[eternaldomains]

This is really bad news. There shouldn't even be a single plaintext around.

If there's still anyone who hasn't changed pw just because you didn't dare log in, you better change it NOW.

 

[Paul]

My personal stance on this:

Companies are going to get hacked; that's just the way it is. While there are clearly security lapses visible in the data, that's no different from any other company. Maybe it was hacktivism, maybe it was a disgruntled customer, maybe it was just someone who thought it was fun--it doesn't really matter.

Epik is going to be facing a lot of criticism in the coming days, both for falling victim to an attack and for issues with the data that has been leaked. There are going to be more eyeballs on their security practices than they could ever hope to have otherwise. Keep that in mind when you're reading about how they failed to secure X or didn't follow best practice Y.

That being said, some of the mistakes here do appear egregious, and I would hope that a company of their importance would learn their lesson and hire security professionals in the future.

Cleartext and MD5!! This is the best they could do?!

That's what I'm seeing, but I can't easily verify the passwords + hashes themselves haven't been tampered with--although, based on the rest of the dataset, I have no reason to doubt their authenticity.

This is really bad news. There shouldn't even be a single plaintext around.

It's quite possible that the plaintext passwords are intended for outbound authentication--that is, authenticating to third-party services. In that case, they would need to be plaintext, or at least use reversible encryption (as opposed to hashing, which is one-way).

 

[NickB]

......

My personal stance on this:

Companies are going to get hacked; that's just the way it is. While there are clearly security lapses visible in the data, that's no different from any other company. Maybe it was hacktivism, maybe it was a disgruntled customer, maybe it was just someone who thought it was fun--it doesn't really matter.

Epik is going to be facing a lot of criticism in the coming days, both for falling victim to an attack and for issues with the data that has been leaked. There are going to be more eyeballs on their security practices than they could ever hope to have otherwise. Keep that in mind when you're reading about how they failed to secure X or didn't follow best practice Y.

That being said, some of the mistakes here do appear egregious, and I would hope that a company of their importance would learn their lesson and hire security professionals in the future.



That's what I'm seeing, but I can't easily verify the passwords + hashes themselves haven't been tampered with--although, based on the rest of the dataset, I have no reason to doubt their authenticity.



It's quite possible that the plaintext passwords are intended for outbound authentication--that is, authenticating to third-party services. In that case, they would need to be plaintext, or at least use reversible encryption (as opposed to hashing, which is one-way).

I'll be honest most of this talk (hashed with MD5, Pll etc etc) is beyond me - I am not a technical person....

Any advice you can give on what people should do if they have an Epik account?

 

[Jurgen Wolf]

At least repark your domains elsewhere...
If you are on their landers.

 

[Paul]

Any advice you can give on what people should do if they have an Epik account?

If you use the same password on multiple websites, change it everywhere--and use a different password for each website. Websites get hacked; that's just the way it is. When they do, the passwords eventually leak. If someone can guess your NamePros password based on your password on ArbitraryCompromisedWebsite, you're going to end up with both accounts compromised.

 

[NickB]

If you use the same password on multiple websites, change it everywhere--and use a different password for each website. Websites get hacked; that's just the way it is. When they do, the passwords eventually leak. If someone can guess your NamePros password based on your password on ArbitraryCompromisedWebsite, you're going to end up with both accounts compromised.

Nice one - thanks to your tip in a previous post about using a password generator I'm using (retracted generator name)...all my passwords are different

 

[Finest]

My personal stance on this:

Companies are going to get hacked; that's just the way it is. While there are clearly security lapses visible in the data, that's no different from any other company.

I'm in the security business and I fully understand that some passwords here and there will slip through the cracks and remain unprotected. But to rely on an algorithm that's been compromised for years for mass hashing is utter negligence.

 

[Mister Funsky]

Well, it is clear something happened and I'm sure we will know shortly if it was anything significant...as of now, everything is operating as usual.

Now would be a time to change PIN and password, just in case the fruitcakes were able to get some of that information.

This type of event is just part of existing in a digital world...hacks, attempted hacks and system overloads are part of daily business. I'm sure Epik will take the appropriate steps.

The 'story' will come out eventually as to what happened and if any damage occurred. I will continue to operate as usual buying and selling on Epik.

 

[eternaldomains]

It's quite possible that the plaintext passwords are intended for outbound authentication--that is, authenticating to third-party services.

So, isn't this like, FederatedIdentity.com is the 3rd party, and then Epik.com stores pw in plaintext so that FederatedIdentity.com can authenticate it? And if that's the case, aren't all those Google+FB logins on unrelated websites extremely dangerous?

 

[Jurgen Wolf]

What are real roots (motivation) of these attacks?
Competitors, discrimination, Trumpism etc. or what?
Epik must consider it firstly.

 

[Paul]

But to rely on an algorithm that's been compromised for years for mass hashing is utter negligence.

Yes, and there's going to be no shortage of people pointing it out. So far, I've only looked at the data for Anonymize; it's possible that passwords for other services are using something better.

That being said, all hashing is just designed to buy time. Even if they were using bcrypt or argon2, the passwords would get out eventually. People should be changing their passwords regardless.

The biggest challenge for them in the near-term is going to be locking everything down. Again, I've only glanced at the data, but they appear to have a massive attack surface with a lot of moving parts. I suspect there's no shortage of holes, and there are going to be quite a few people combing through the dataset looking for additional vulnerabilities.

So, isn't this like, FederatedIdentity.com is the 3rd party, and then Epik.com stores pw in plaintext so that FederatedIdentity.com can authenticate it? And if that's the case, aren't all those Google+FB logins on unrelated websites extremely dangerous?

To give you an example, NamePros processes payments through Stripe. In order to authenticate with Stripe, a third-party service, NamePros needs to store a password in plaintext--not your password, just a password, one provided to use by Stripe. There's no way around that.

I don't know what the plaintext passwords I saw were intended to be used for, but there weren't many of them. The user accounts were using MD5 (which might as well be plaintext).

What are real roots (motivation) of these attacks?
Competitors, discrimination, Trumpism etc. or what?
Epik must consider it firstly.

Nobody is going to know until it lands in court. It's also by far the least important aspect of their immediate response, since their priorities should be securing their infrastructure and notifying affected parties.

 

[LOLed]

I'm in the security business and I fully understand that some passwords here and there will slip through the cracks and remain unprotected. But to rely on an algorithm that's been compromised for years for mass hashing is utter negligence.

What else do you suggest for password encryption, if not MD5 with salt? Isn't it impossible to decrypt if they use a random and strong key?

Edited

 

[Jurgen Wolf]

Then why superbuggy Dynadot is not hacked???

 

[Paul]

What else do you suggest for password encryption, if not MD5 with salt? It's impossible to decrypt if they use a random and strong key IMO.

Salted MD5 is not and will never be sufficient. It's entirely possible to crack. (Edit: The passwords I've seen so far in the breach did not appear to be salted anyway.)

Don't try to roll your own crypto. If you're working with PHP, use password_hash and password_verify--as of writing, those will use bcrypt or argon2, both of which are acceptable. If you're working with a different technology, consult the industry best practices. Do not try to come up with your own scheme.