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

Kubernetes clusters being hijacked to mine cryptocurrencies

blog.binaryedge.io

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Kubernetes clusters being hijacked to mine cryptocurrencies

#61

Post by raverbashing »

TheDong wrote: post #60
barrow-rider wrote: post #59

Earlier quoted context omitted.

> "systemd" is always spelled lowercase. The 'd' doesn't stand for something and is never capitalized. I thought the 'd' was a holdover from "daemon", as in initd or setsid, as a general name for a background process. systemd is a little more than just a background process but it's sort of the same idea. From the wiki page: "In a strictly technical sense, a Unix-like system process is a daemon when its parent process…

From their documentation [0]: > Yes, it is written systemd, not system D or System D, or even SystemD .... [You may also, optionally] call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?). The 'd' is a pun on both daemons typically being postfixed with 'd' and on the roman numeral for '500'. It does not directly stand for either t…

While naming trivia is interesting, it is a fact that systemd has had its fair share of security problems. And while it is a fact that OpenSSH is more mature, systemd has some issues with recognizing security failures as such https://www.reddit.com/r/linux/comments/6mykng/that_systemd_...

Re: Kubernetes clusters being hijacked to mine cryptocurrencies

#62

Post by TheDong »

raverbashing wrote: post #61
TheDong wrote: post #60

Earlier quoted context omitted.

From their documentation [0]: > Yes, it is written systemd, not system D or System D, or even SystemD .... [You may also, optionally] call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?). The 'd' is a pun on both daemons typically being postfixed with 'd' and on the roman numeral for '500'. It does not directly stand for either t…

While naming trivia is interesting, it is a fact that systemd has had its fair share of security problems. And while it is a fact that OpenSSH is more mature, systemd has some issues with recognizing security failures as such https://www.reddit.com/r/linux/comments/6mykng/that_systemd_...

That is a perfect example of security FUD around systemd.

The attack vector is what? Someone manages to convince an administrator to write a service that has "User=0foo" in it?

If an attacker has access to write into `/etc/systemd/system` then they already have root on the system.

If an attacker can cause an administrator to write a systemd unit and the administrator isn't checking that it's reasonable, the attacker could just have the `ExecStart` line run a 'sploit and not have a `User` line at all.

Seriously, what is the attack that you imagine where this has a security impact?

As Poettering said on that issue, no one should be running system services as usernames starting with numbers, and that's questionably valid in the first place.

People still have blown it out of proportion because it's systemd.

Note that a similar issue exists in the old sys-v init scripts: they run as root, and if you convince a person writing a sys-v init script to exclude the `start-stop-daemon -u username` flag, then the daemon will run as root. Basically identical, but never assigned a CVE because no one seriously considers "I talked my sysadmin into running something as root" by itself a privilege escalation.

Re: Kubernetes clusters being hijacked to mine cryptocurrencies

#63

Post by rescbr »

nineteen999 wrote: post #58
ownagefool wrote: post #50

Earlier quoted context omitted.

It's more complicated that that. Whilst some people are probably jumping on kubernetes for the hype, there's a lot of things it makes really easy, especially for less experience teams. For example: - You want to spin up ephemeral environments to test PRs end2end. Sure, create a namespace, deploy your charts and run your tests. You want to do that with ansible, sure you can, but it's harder. - You org is running apps…

Can I ask because I'm genuinely interested - what on earth do you do for third-party applications (for eg. closed source) that have to be integrated into your environment that don't come pre-packaged in a convenient container? Do you containerize these yourselves, whether or not the vendor says that will support that? Or does it get pushed to some other team that manages whole VM's/AWS instances that are not containe…

> Do you containerize these yourselves, whether or not the vendor says that will support that? Or does it get pushed to some other team that manages whole VM's/AWS instances that are not container hosts.

Working with large enterprises, I've seen both. If there's a good business case for the risk vs rewards (i.e. containers providing something technically useful which can be translated directly into revenue) and a good engineering + management team, some companies will actually risk it.

There's also the factor of how good the company's relationship with the third-party vendor is. Some companies have the weight to make the vendor support the unsupportable.

Re: Kubernetes clusters being hijacked to mine cryptocurrencies

#64

Post by justicezyx »

bonesss wrote: post #52
justicezyx wrote: post #21

Earlier quoted context omitted.

Let's be honest, pretty much every new tech got hyped initially. K8s is no doubt hype, otherwise it won't enjoy the explosive growth. That's not subjective, at least IMHO

It's the delineation of 'hype' and 'excitment' that is tricky. If magic CPUs that were 10x better showed up tomorrow we'd all be justified in being very excited. But running with hype around the next Zune? ... that's not excitement backed with meaning.

Then we should agree to disagree.

Re: Kubernetes clusters being hijacked to mine cryptocurrencies

#65

Post by ownagefool »

nineteen999 wrote: post #58
ownagefool wrote: post #50

Earlier quoted context omitted.

It's more complicated that that. Whilst some people are probably jumping on kubernetes for the hype, there's a lot of things it makes really easy, especially for less experience teams. For example: - You want to spin up ephemeral environments to test PRs end2end. Sure, create a namespace, deploy your charts and run your tests. You want to do that with ansible, sure you can, but it's harder. - You org is running apps…

Can I ask because I'm genuinely interested - what on earth do you do for third-party applications (for eg. closed source) that have to be integrated into your environment that don't come pre-packaged in a convenient container? Do you containerize these yourselves, whether or not the vendor says that will support that? Or does it get pushed to some other team that manages whole VM's/AWS instances that are not containe…

> Can I ask because I'm genuinely interested - what on earth do you do for third-party applications (for eg. closed source) that have to be integrated into your environment that don't come pre-packaged in a convenient container?

Depends what it is. I've taken a number of apps and wrapped them into docker containers and then written a helm chart. Some orgs get a bit skittish over "vendor support" but this usually only matters when they think it's a key product.

The point is, once you have a fleet, you should manage everything the same. If you're off building other pet services, you're going to have capacity problems.

> None of which matters one jot, if one cannot properly manage ingress/egress filtering on one's API endpoints, or a reasonable level of password/credential security. One will be used for cryptomining or worse, as per the fine article.

I mean sure, but I did say use a managed service, which will come with auth. Similarly I wouldn't recommend you host services on any cloud or network facing the public, without a professional involved.

For example AWS is easy to get wrong all the same. One of my current client is busy hiring developers with no experience to put services on AWS, and they came up with no encryption, no auth, no monitoring, misconfigured IAM. What's really the difference between that and kube?

Re: Kubernetes clusters being hijacked to mine cryptocurrencies

#66

Post by honkycat »

TheDong wrote: post #37
honkycat wrote: post #16

Earlier quoted context omitted.

I can't imagine a good reason to expose ANY of my services to the public internet. Aside from a rest-api that drives our application, where that is the feature of course. With software like google IAP, and many similar products, it just seems silly.

May I recommend reading up on beyondcorp [0]? Google has moved its internal stuff to the beyondcorp model, and it honestly seems like a better approach if you really care about security and have a big enough security team to make it work. [0]: https://www.beyondcorp.com/

Thank you for the suggestion! :)

Google I(dentity)A(ware)P(roxy) is actually a hosted beyondcorp implementation! But I probably should have explained that in my original comment.

Re: Kubernetes clusters being hijacked to mine cryptocurrencies

#67

Post by nineteen999 »

cbzbc wrote: post #54
nineteen999 wrote: post #9

Earlier quoted context omitted.

I don't assume that at all. I mentioned Docker explicitly and people are pulling Docker containers from untrusted sources with malware pre-installed, because they lack the experience that would tell them that pulling untrusted Docker containers and running them is a bad idea. https://threatpost.com/malicious-docker-containers-earn-cryp... From the article itself, although they mention the CVE at the top, the real poi…

Leaving aside NoSQL db's - there's also a ton of normal SQL databases wide open, I don't think hype is necessarily the issue there.

Sure, maybe your average garden variety Postgres or MySQL instances, and probably some MS-SQL as well. Companies that have a large investment in commercial RDBMS (eg. Oracle, DB2, etc) tend not to be so careless in my experience.
Post reply on HN