Security Incident – DNS Breach | Hacker News Reader

Security Incident – DNS Breach

coinhive.com

35 pointsponytech49 comments

A great example of folks either re-using passwords, or simply not being aware that their credentials have been included in a previous leak/breach.

For an idea of a timeline, and a useful reminder to check your own personal accounts (and those dreaded shared accounts internally):

  - Feb 15 2014 - Kickstarter breach occurred 
  - Oct 08 2017 - HaveIBeenPwned import the dump, suggesting it is publicly available, or at least being shared around.
  - Oct 24 2017 - Coinhive suffer their DNS breach.

Services such as Troy's HaveIBeenPwned are an excellent resource, and I can whole heartedly recommend signing up for the 'Notify Me' function: https://haveibeenpwned.com

I recently released something similar for corporate environments, allowing businesses to produce pseudo-users to insert into their user base. These 'canaries' are unique to them & come with real email addresses and phone numbers, so should they ever be contacted you can be pretty sure you've suffered a breach of some kind. We of course also check the usual suspects (Pastebin, Tor) for any similar evidence of a breach. Can see some more details here: https://breachinsider.com

Cloudflare will not let you have individual users without the (unspecified) “Enterprise” pricing plan. Even on the Business plan, we get to copy/paste one password around the team. Great for security.

Every other service (especially that critical!) we use gives it away with the actual service. I really dislike this about Cloudflare.

Enterprise pricing starts at $5k per month.

Have you thought of using a group password manager like 1Password, Dashlane, etc so you're not copy and pasting a password around the team? Just a suggestion :)

Good advice for password management but that doesn’t change the fact any internal malicious actor can take the password and be very difficult to identify

Very true, but still better than pasting a password around?

That only addresses one (and arguably the smallest) of the various issues with a shared username/password.

Isn't it bad to have passwords in plain text though? Sure, it's a small issue, but it definitely exacerbates the problem. I don't understand why this is earning me downvotes....

You're proposing a band-aid for a gaping wound.

I love 1Password, but it doesn't solve the auditing issues inherent in a single shared account. It doesn't stop an angry employee from changing the email and password to lock everyone else out.

It's upsetting that Cloudflare, with their otherwise good approach to security, apparently puts multi-user accounts behind a $5k/month paywall.

True. I agree with you!

We do use Dashlane and GPG for sharing secrets. In this article’s case I would bet that nobody changed the account’s password because (i) it’s no one’s responsibility (ii) they do not want to disrupt someone else’s workflow.

Nice. Didn't mean to insinuate that you weren't. Yeah it's definitely not the best thing but some people really do copy and paste passwords around!

You should have mandatory 2FA authentication for this sort of things.

How would multiple people share the second factor?

We have a two-man rule for such accounts: one person (or one group) is responsible for the password, and the other has the 2FA secret on their Yubikey. The other rule is to not use these accounts; as an example use use root AWS accounts once or twice a year when we need to fill in their forms.

How about just do it?

Ever shared a USB key or a company phone. There isn't much to describe.

I guess if all the people who need access are in the same physical location that works.

By sticking the same base code into Google Authenticator or similar?

I didn't think that was possible at least with Google accounts. But now that I think about it, if you set up both devices from the same QR code (instead of running through the process twice) it should work. Good idea.

Anyone that hosts javascript for 3rd parties is a target for this type of breach. That Coinhive miner script could easily be embedded into any other javascript file.

Why did everyone stop hosting js files locally? Why not pull content from the same server that is sending html, the speed improvement by using a cdn should be low with the size of libruaries these days.

I wouldn't underestimate the value of the CDN. And updates.

Can you imagine the damage done to a CDN if the attacker would supply extremely long Expire/Caching/key-pinning headers? All clients visiting the malicious server would be cache poisoned for a loooong time.

For extra fun, the attacker could send HTTP 301 redirects from the (temporarily) stolen domain to a different domain. Browsers don't forget those.

Y'all are terrifying me.

Clearing the cache actually clears cached redirections.

Good luck to any victim site instructing the entirety of their userbase to do that. Especially when the users can't access the site to begin with.

Cache can be cleared and they are usually rechecked from time to time.

What's really fun is the HSTS strict transport policy header + certificate key pinning. That cannot be cleared. None of the users who open it will ever be able to open the site again.

> This third party server hosted a modified version of the JavaScript file with a hardcoded site key.

A site key for a user on coinhive or pointed at a different website all together? If it's just a site key it should be dead-simple to close that account:

    <script src="https://coinhive.com/lib/coinhive.min.js"></script>
    <script>
        var miner = new CoinHive.User('<site-key>', 'john-doe');
        miner.start();
    </script>

CoinHive has automatic payouts. They could easily close the account, but they can't get Moneros back.

That's fair, I just expected there to be enough of a delay they would be caught first but maybe not.

We use Okta internally.

As much as I hated it at first, we don't choose any provider that doesn't support single sign on and multiple users.

You can choose a password policy that is different (stricter) than the downstream services.

One more good thing about it is that you have all of your services in one place and you know when you need to change password on one of them or all of them. You can do it with a nice dashboard.

This made managing access a much nicer experience for us and I can imagine will minimize things like that from happening.

Okta's Firefox addon is incompatible with multi-process mode and that kills responsive design mode in Firefox's developer tools. This is remarkable for a change that's been a long time coming. Their site also erroneously says that the apps "require" the addon, but if you click the apps without the addon, it just takes an extra click to confirm the logon. I haven't been very impressed.

I don't actually use Firefox so never experience what you are saying. I do believe you though.

I used okta at my last job and IIRC there was a breach with HipChat that necessitated us resetting our okta passwords as well. It turned out that using okta for HipChat meant that okta just set your HipChat password to whatever your okta password was. It did not leave me feeling very secure.

Yeah.

For us, we have a review process internally for every 3rd party we use. We figure out the auth process and how secure is it etc...

I'd say the internet was better off for a bit, but it looks like the hack just temporarily made Coinhive's malware make money for a separate set of bad actors for a while.

edit: For the downvoters, if you've noticed your CPU fans running while visiting a variety of sites lately, chances are Coinhive's the reason. Non-consensual altcoin mining as a service!

I hate the idea of that just as much as you do, but you can always add the coinhive domain to your blocklist and be fine (just as you do with ad providers). Also, I'd be willing to bet bad Ads are still way more of a cause of CPU spikes/usage than coinhive.

coinhive promotes the option of hosting the files locally on the site domain so a simple block may not work for all.

"uBlock Origin has prevented the following page from loading: coinhive.com"

I can't read what it's about but it looks like it's already blocked.

Anyone would mind to give a summary?

Click the "Disable strict blocking for coinhive.com temporarily" button.

No thanks. I've seen enough zero day to learn to not do that, especially when the only hint so far indicates the site was breached.

sigh uBlock is blocking the site so your computer isn't used to mine coins. It just blocks the whole domain, this is just a blog post.

How is blowing out your visitor's CPU for profit, without an opt-in notification, not malware itself?

Thieves stealing from thieves, IMHO.

Edit: from the downvotes to any comment that's critical of Coinhive I see the Coinhivemind is not fond of simple ethical quandaries.

Well, Coinhive has nothing to do with how certain people implement their lib, they just provide it. It's really up to the site owner to ask for permission to run it instead of forcing it (like ads).

Coinhive could require sites to notify or ask permission, or even build it into the script itself.

They support that using AuthedMine [1].

[1] https://coinhive.com/blog/authedmine

Opt-in, "previous solutions will continue to work exactly as they did", and only because they got blackholed by all the ad blockers in like 24h.

> Edit: from the downvotes to any comment

This breaks the HN guideline which asks you not go on about downvoting in comments, and also (implicitly) the one that asks you not to post insinuations about astroturfing or shillage.

https://news.ycombinator.com/newsguidelines.html

What look like voting 'patterns' on HN are pure Rohrshach: you extract what you project in. That's why comments about them are information-free, which is why the site guidelines ask everyone not to go there. It just puts noise in the signal/noise.

Reply on news.ycombinator.com