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.
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 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.
ideally, there would be a warning for identities with access to too many secrets.
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
[2] https://www.vaultproject.io
[3] https://docs.aws.amazon.com/secretsmanager/latest/userguide/...
edit: formatting now that I'm on a desktop
welcome to 1996.
If you use 1Password and say Authy (Assuming your Authy pass isn't in 1Password) or Google Authenticator. Then all services with MFA wont be compromised if the 1Password masterpass is...
Not quite. An attacker would need either your account password AND an already authorized device, OR they would need both your account password AND Secret Key. If you have 2FA enabled for your 1Password account, and the attacker doesn't have one of your authorized devices, they would also need your second factor (TOTP or hardware key).
Additionally our Principal Security Architect, Jeff Goldberg, wrote some thoughts on this subject, here: https://blog.1password.com/totp-for-1password-users/
- Ben, 1Password
Then I was like "1Password will sync these to my new phone so I never lose access to everything again? Fine."
I also started to get questions from my wife around how she could access things in the event of my death and it seemed having a 1Password printout in a safe deposit box she could access - and having that include the MFA too - was a good idea.
My master password in 1Password is quite secure (A long obscure sentence and with special characters etc.), I have it auto-lock pretty quickly (thanks TouchID!) and I guess that will have to be enough unless I shift to something like a Yubikey on my keychain for things down the road...
Not every little SaaS needs MFA.
Relevant xkcd: https://xkcd.com/538/
If you really really want one user to control everything, maybe they should work on a desktop station with a guard at the door.
Block unknown executables on company machines. Google developed Santa to protect themselves: https://github.com/google/santa
> and that's all it takes to steal cookies and tokens post-mfa,
Make post-MFA cookies and tokens short-lived. Require MFA re-authentication at least daily.
> or why even bother with that, if you're running code just make it a reverse shell.
All outbound connections should be strictly monitored, especially from production servers, which should have no ability to connect to the Internet at all. With modern dependency management, that's harder for build servers, but still doable.
The big screw up here is powershell script on a network share. A cheap pentest would have uncovered something like that.
Modern security is not perimeter focused where you try to keep the bad guys out. Yes, you should do MFA,firewalls,vpns the whole schtick but(!!) your presumption should always be that threat actors already have a foot-hold in your network. This is very important because it helps you focus on basic things like scripts and gpos with creds in them but also you treat internal devices the same as internet exposed devices. It's sort of what the whole "zero trust" thing is about as well. In other words, host/user compromise is a given but lateral movement should be at least as difficult as breaching the perimeter.
But my prediction is, just like top commenters here, they will slap MFA on it and of course cleanup scripts with creds and call it fixed until the next compromise. Oh and FYI, MFA on VPNs is a PITA, that's rarely done for good reason, instead you use device certificates in addition to passwords which is what the recommendation should be not yubikeys or webauthn (vpn!=web??) because VPNs need to reconnect and you can't have people insert a yubi each time their connection drops. Ideal setup would have 7 day valid (or however long is reasonable for users to disconnect their PC and remain out of office) mutual-auth certs+ocsp getting conditionally reissued new certs to remain connected (compliance stuff like patching, unapporoved software,security alerts for the device). If you think about it, you typically issue users two yubikeys not just one so if the backup gets stolen you have a problem depending on how easy it is to social engineer users or reset their password with a good yubikey but a stolen laptop means certs+password revoked immediately.