Hacker News Reader

Comment by _Adam | Hacker News Reader

The powershell script is a minor part of the screw up. The real issues are multitude...

1) hardcoding actual production credentials in a script at all. Seriously what the fuck.

2) Thycotic not enforcing MFA for the keys to the kingdom admin account. Even my cellphone provider has better security.

The root cause is likely the assumption that the VPN is sacred. This needs to die asap - your internal network should assume the VPN is wide open and secure everything accordingly. Defense in depth not eggshells.

View on HN

So, on that, it is surprisingly difficult to get rid of hard coded credentials and funnily vendors like tychotic and hashicorp are supposed to prevent that by having some api thing that integrates with scripts.

That said, tychotic,cyberark and pals that manage credentials almost always need domain admin. I think just moving to full AAD and azure key vault might be better but realistically this is the nature of the beast. If I had to guess the "network share" is probably a GPO on a DC that is used by tychotic, anything short of that is ridiculously bad. GPOs are shared to all machines so they can be pushed to them so you see creds in there sometimes if scripts need them, the thinking being "if the bad guys are in the network we have bigger issues" (again with the perimeter centric intuitive security mindset).

the cute answer to all this is always: how do people think your service accesses the secret vault? its anlther credential.

the real issues are tougher, like why does this one cred have access to all these other creds, and how or if they were auditing usage of that cred from authorized client devices.. but all of these problems take a lot of effort and care to solve. and as history has shown, you only have to mess up once.

I agree but an api key for a PAM service will get you constrained access (ideally) to a specific resource instead of a kerberos ticket you can take with you as part of your ticket collection. It's supposed to be better but granting the resource permission like GCP does is probably better (but messier too).

for sure; the real failure in this setup was again, having a single credential with access to so many other critical secrets. I have yet to see a secret vault that had good analytics for this kind of thing - it assumes you have designed your secret hierarchy and permissions appropriately.

ideally, there would be a warning for identities with access to too many secrets.

I'm curious what's the alternative if the script must have those credentials to do its job.

Environment variables are an easy first pass at ensuring a script at rest isn’t dangerous.

encryption based authentication (keys or certs) that can be revoked.

welcome to 1996.

As sibling points out: Don't authorize the script, authorize whoever is executing the script.

Besides what the sibling comments said, it's very unlikely to that any script needs keys to the kingdom. Credentials should be created with limited access, just enough for the script to do its thing.

Not for PAMs like tychotic their service accounts are domain admins

As another commenter pointed out: you authorize the executor of the script, not the script itself.

Consider how an AWS instance runs code that is able to ... talk back to the rest of the AWS system.

For code that is not being directly run by a tethered meatball, use some form of workload identity [1].

When you are talking to another system that that can't understand your workload identity (legacy apis, etc.), keep those credentials in a tool like Vault[2], Secret Manager[3], etc. That system can/should handle credential rotation wherever possible, but it also ensures that the workload running the script is authorized to access the credentials in question. This is far superior to passing via env vars, but even that is better than hard-coding in the script itself. Oh, and using a memory-backed mount that contains those vars is better than env vars because there's less risk of leaking those when you fork.

Key points:

- externalize all secrets

- prefer workload identity

- prefer a workload identity aware secret store / manager

- fall back to fs mounted secrets and then env vars

[1] https://spiffe.io

[2] https://www.vaultproject.io

[3] https://docs.aws.amazon.com/secretsmanager/latest/userguide/...

edit: formatting now that I'm on a desktop

Stuff like...tychotic helps prevent that :P

Reply on news.ycombinator.com