5 ms·
> Adam says the attacker(s) had access to privileged credentials that were previously stored in the LastPass account of a Ubiquiti IT employee, and gained root
by meepmorp 6y ago
> Adam says the attacker(s) had access to privileged credentials that were previously stored in the LastPass account of a Ubiquiti IT employee, and gained root administrator access to all Ubiquiti AWS accounts, including all S3 data buckets, all application logs, all databases, all user database credentials, and secrets required to forge single sign-on (SSO) cookies.
A root user user breach, seemingly on the organization main account. Ouch.
I wonder if MFA was set up, with the TOTP creds also kept in LastPass.
- liaukovv 6y agoWhat is the right way store credentials to something like this? Hardware keys?
- meepmorp 6y agoI use a Yubikey, personally.
- NovemberWhiskey 6y agoFor AWS root account? Generate a long random password, print it out and then lock it in a safe without allowing anyone to see it. Turn on 2FA and then lock the second factor in a different safe. There’s virtually never a need for the root account and it’s impossible to attenuate (by design).
- dmlittle 6y agoThis is a lot harder to do if you have lots of AWS accounts and create new ones over time on-demand (e.g. AWS account per team).
- NovemberWhiskey 6y agoUse Organizations. If you’re creating new standalone independent accounts for teams you’re just seeking yourself up for some kind of billing/security/governance catastrophe down the road.
- dmlittle 6y agoI was referring to the root accounts in your organization. The blast radius is more limited, but still a root account that has access to everything within that AWS account.
- time0ut 6y agoYou can restrict what the root account can do in a member account using SCPs as an additional safeguard as well.
- ericopf 6y agoPrinting out the AWS root password and putting in a safe is almost useless. Root password can be easily reset without MFA by having access to the email associated to the root AWS account. MFA is the important one to keep it safe for AWS root accounts, set for the master AWS account and lock root access for all member accounts via SCPs.
- ak217 6y agoThe root account credentials should be used to create a privileged IAM user and then physically locked away in a box after setting up a hardware MFA device (plus a backup MFA) for the root account: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi... The privileged IAM user should then be used to administer other IAM users and roles. All IAM users should be required to have hardware security keys like Yubikey.
- liaukovv 6y agoBut how fast a determined attacker will be able to utilize acquired physical key? Is something like kidnapping in the threat model for companies like ubiquiti?
- ak217 6y agoThose kinds of fanciful things are not commonly in threat models because they don't happen. The threat models address things that are likely to happen, which are all variations of someone's device getting compromised.
- mywittyname 6y ago> Is something like kidnapping in the threat model for companies like ubiquiti? I doubt it. That's going to raise some blinking red flags on the radar of organizations you don't want to be on the radar of. Not just three-letter federal organizations, but three-letter news organizations too. The current situation is Yet Another Security Breach that will be forgotten about in 15 minutes. But a kidnapping is interesting! People will be making documentaries and shit about that. It's so much easier and cheaper to bribe people than it is to kidnap them.
- deleted 6y ago[deleted]
- the8472 6y ago> (plus a backup MFA) IAM doesn't even let you register more than 1 MFA device.
- jrudolph 6y agoAWS root user accounts are kind of an achillis heel in every enterprise setup using AWS. What you typically do is MFA (bare minimum) + sharded secrets. This means you need multiple people to use the root user account. You can also hook in additional audit controls eg by automating cloud watch and sending notifications about any root user login. Alternative is that you throw away the password and vow to never use it, or set up an account recovery process (all of this may not be a great idea as it can fail when you need it most). The situation is somewhat more relaxed with GCP Billing Accounts and Azure EA Accounts, though they have better separation of concerns than AWS (billing vs. workload access). Nonetheless, never give these passwords to finance department lest they store it in an excel sheet on a SharePoint. Access to these credentials allows anyone to suspend billing for an entire enterprise... not sure what controls the providers have in place to verify any of this before initiating automated shutdown of all workloads.
- aaomidi 6y agoHardware keys should be used to store stuff like: - private keys for ssh, gpg, vpn auth - 2fa for sudo access, password manager access, etc
- isclever 6y agoThis boggles me when I see this option in any password manager (and I think every single one has this 'option'). Why do password managers let people store TOTP next to the password, this completely invalidates the 2FA of TOTP if your password manager get broken into.
- Xavdidtheshadow 6y ago> this completely invalidates the 2FA of TOTP if your password manager get broken into I think that's the big "if". If you assume the password manager is secure (which something clearly wasn't in this case, but that seems like an outlier), TOTP secret in the password manager still secures the account. Is such a setup as protective as a separate storage method? No, but it's leagues more convenient. A cloud-based PW manager also solves the problem of a lost/broken/new phone causing you to lose all of your 2FA setups. Some 2FA apps do as well (Authy, iirc), but trust me when I say people lose 2FA codes _all the time_. And then 2FA needs to be disabled by support, which is its own can of worms. The best security measures are the ones people actually use. If not having to use a separate app is the convenience people need, then I think it's totally worth it.
- MAGZine 6y agoYou know what's also convenient? 1FA. Which, incidentally, when you store you TOTP secrets with your passwords, is what you have.
- amarshall 6y agoI mean, if the password manager’s store is compromised, then sure, okay. But if only the application password is compromised then it’s still 2FA since the attacker cannot authenticate with just the password.
- MAGZine 6y agoI see what you're saying, but I disagree. The F in 2FA is factor. Satisfying one login request from one factor (password vault) is 1FA. This is why the second factor is normally something that isn't your password vault (historically your head, now a piece of software): a hardware key, a recovery code, etc. A slightly more generous interpretation is 1.49A (rounds down), because someone with a reused username/password combination. But if you're using a vault with a sophisticated factor, the venn diagram of "people who have your password," and "people who also have your master password," are pretty tight, except for cases where the provide has been breached (all bets are off). Don't dispose of the second factor for convenience.