Uber investigating breach of its computer systems
nytimes.com
nytimes.com
Webauthn, however, binds the authenticator to the domain and port, and requires https as the scheme. If a user gets phished, they cannot be compromised: the phisher's domain will not match and any Webauthn authentication challenge would fail.
So if your workplace is letting you authenticate with SMS codes, push notifications to an app, or 6-digit codes generated by an authenticator app/hardware device, you need to start banging on pots and pans up your reporting chain to get your security team the support they need to make Webauthn + FIDO2 hardware tokens or Webauthn + Mac Touch ID happen.
Not sure how Webauthn works, but as long as it can be stored in the cloud, I'm fine.
Industry is going towards this scheme of physical 2FAs that assume some living conditions appropriate for whoever designs things, without alternatives for people who don't fit that ideal way of doing things. Physical stuff gets lost or stolen. I'm optimizing for when I am traveling from home around the other side of the world, 6 time zones away, and my phone / stuff gets lost.
2FA is already unmanageable at this point: "just use your recovery keys" is what people tell you, but that's NOT a viable solution to the problem. Sorry but my recovery codes are in a safe lock, 10,000 Km away from me, I just lost the purse with my phone, or my device broke, or got stolen, or whatever, and need the damn TOTP code to telework _right now_.
"I absolutely need full access to systems while working on a random device using only my password" means that phishing gives all the keys to the kingdom and that you don't have systems in place to make sure things work when people go on vacation.
Do you? Really?
"Your lack of planning is not my emergency"
Unless you're the founder+owner, I'd expect that tech support at your company wouldn't expedite your access request just because you feel entitled to it.
Will a million dollar sales call fail and/or have to be rescheduled because you didn't have 2FA access? You should accept the responsibility, apologise with whoever it is that you let down and move on.
Of course, companies should give us all the tools we need to succeed. Not cheap out on their budget and then shift the blame on us. This means also giving you multiple devices and tokens, to ensure that you have redundancy (if a device fails you have a backup, if you lose a token you have a backup).
Even then, it can happen that right after a trip you might've realized that you left home and/or misplaced your security token. The professional thing to do is to communicate it to the company right away (so they can arrange to verify your identity and/or to ship something to you) once you discover it when you land. Not ignore the problem until you'd be back at work and in urgent need to attend some work meeting.
Travelling across the world, 6 time zones away is not something that you can do with every job. If your company allows it, that's a perk, but you should also treat it with the due care that requires.
Missing a day of work is small stuff compared to the risk that the whole company runs by allowing their employees auth to be phished. If you have to skip a day (or more!) of work on extremely short notice, it might be an unpleasant conversation with your manager, but it's a conversation that you should have nonetheless. (btw, do you have the phone number of your manager on your personal phone? if you lose your work devices, it's important to still have a way to reach out to them).
Security tokens are cheap, just make sure that you have N+1 (one for each device you need, plus one)
Spoken as someone who has clearly never had any tech duties in the financial sector.
You don't understand what time critical means until a dealer's access stops working / computer freezes 10 minutes before market close. ;-)
That could easily cost millions. That could easily loose the company the entire account.
And god help you if the market moves overnight and you were unable to get the trade on ...
A grovelling apology to the client might help avoid a complaint to the regulator, but you're unlikely to keep their business.
So yes, there will always be genuine need for IT to be able to bypass a user's 2FA, because its certain that user won't be able to wait until you send them a new Yubikey in the post.
And yes, financial companies are also well aware of phishing / SE and take appropriate steps to ID user.
I'm not going to post details in public, but suffice to say, you are over-simplistic and don't understand the context.
Sticking with my example of dealers, let's just say people like dealers are not employed in great numbers in all but the largest financial organisation. Let's also say that there are certain events and certain times of day when the entire dealing desk is, shall we say, "busy and stressed out". There is little scope for a colleague to step in at those times, because everyone is franticly busy on the phones with their own workload.
In terms of 2FA therefore, the "walked infront of a bus" scenario is to (after correct security protocol, which includes, but not limited to, senior board-level management and compliance being told and approving) temporarily bypass 2FA for that dealer. Telling the dealer to pass his work to a colleague is just not going to work.
Of course financial organisations have "walked infront of a bus" plans. But they equally have levels of escalation of plans. Sometimes doing stuff at lower level with the help of the IT department is more than sufficient.
I'm not going to elaborate further.
That just sounds like optimizing for efficiency over redundancy, which is a trade off you can make, but not one that is required. Financial organizations could hire more dealers so you don’t have “little scope” for others to help out. Or they could staff an IT group that is open 24/7 ready to help these traders instantly.
- hire more dealers ($$$$$$$$$) - staff an IT group that is open 24/7 ($$$$$$$$$) - bypassing MFA ($)
Not sure if you are being serious that the other options are comparable to the 3rd for a business
Honestly if they are going to just skip MFA everytime it’s a bother they might as well just not use it
There is no job at uber that could not be done by a coklwague that has access. There is no situation where 10 million delay in uber loses you 100 million dollars
> Unless you're the founder+owner, I'd expect that tech support at your company wouldn't expedite your access request just because you feel entitled to it.
You think corporate IT support doesn't help out users who've forgotten their credentials?
I can assure you, resetting forgotten passwords is probably one of the most frequent things first-tier IT support does. And sorting it out synchronously while they're on the phone is normal - it's not like you can do it asynchronously when they're locked out of all the async messaging systems.
(Of course, the bypass might take an inconvenient form - like calling you back on the phone number HR have on file with you, or a three-way video call where your boss vouches for you)
Ideally, the IT department is empowered to work proactively on effective infosec, for all of the company's real-world situations.
Then the standard for responsibility of each non-IT employee is only good faith compliance with what IT dept. told them -- not to be an IT expert who can reason about infosec tactics and strategy.
(Webauthn by design requires physical hardware tokens, not cloud storage.)
Apple and Google already announced cloud syncing earlier this year, using "passkey" as a friendlier term for end-users. QR codes already allow for cross-ecosystem non-synced use cases, like using my personal Android phone to log in an account with my work Macbook. https://securitycryptographywhatever.buzzsprout.com/1822302/... is a good listen to catch up on the latest developments.
[1]: https://www.w3.org/TR/webauthn-2/#authenticator-model [2]: https://developer.chrome.com/docs/devtools/webauthn/ [3]: https://github.com/herrjemand/awesome-webauthn#software-auth...
If you lose the things you have while on vacation, though, it will be inconvenient (which is what the OP seemed to be against, and what I meant to be responding to). I think for a corporate environment that inconvenience is a reasonable tradeoff.
That's not true. As an obvious reductio ad absurdum, you could just build a fake USB driver that presents as a security key. But more practically, I'm pretty sure that iOS the Webauthn secrets are synced cross-device via iCloud.
Nothing about the spec mandates physical hardware tokens. Software tokens work fine too. https://developer.apple.com/passkeys/
Let's say you are traveling and you lost one or both of your access devices. First immediate step is contact your security hotline and notify them that you lost the device(s). They should immediately remote-wipe/disable said devices.
If you are visiting another branch office of your company, local IT should be able to physically verify you with your government issued ID and your corp badge and issue you a temporary laptop/phone and get you basic access privileges.
If you need high-trust access, it should require more verification steps (your manager has to confirm you are not on vacation and that it is really you who is meeting with the IT shop etc), and more elapsed time (this sucks but it is important to slow things down anytime primary access devices are reissued due to loss/theft).
Obviously, if you are a super critical person and have become a single point of failure, that's bad.
So, wait for a new authenticator device to be shipped to you. Like, if the work laptop broke, you'd presumably have to wait on a replacement for that, too...
Anyway, if a complaint about procedures makes exactly as much sense if you replace the cause with "gets sick and spend a day at the hospital" without losing meaning, then it's not a valid complaint.
For work, I use that as a backup. For personal use, I just leave a cheap Feitian plugged into my desktop. For work, I just leave a slim USB-C plugged into my laptop all the time (if the laptop gets stolen, they still need the first/password factor)
In addition, emergency recovery codes just get copied to a note in my password manager. You don't need to lock recovery codes in a safe--they're only 1 of the two factors. You just need to make sure you don't store them in the same place as the other factor (or, if you do, that place is protected with multiple factors)
But yeah, the face whatevers really must not be the only option.
I have literally never travelled to "another office" in my entire career. But then I've always worked for startups ...
Apple is solving for this exact request with Apple Passkeys; it is just WebAuthn under the hood with cloud backup, multi-device, and sharing built in.
Of course that doesn’t work with my iPhone. So I guess I need a second NFC yubikey that stays on my key chain in my pocket (which I don’t have since I don’t carry keys.). So then I have to remember to register both yubikeys. Then every time I have to login to GitHub or whatever on my phone I have to pull out my keychain (which I don’t have) and tap it on my phone.
I wonder when I can just get a virtual yubikey built into my phone. No extra device. My phone is my device. It kind of sounds like what Passkey is but I don’t want to pull out my phone to auth my laptop.
I really loved the idea and convenience trade off of SoftU2F. Too bad it’s dead now.
Last year, Apple shipped the first version of this: you can enroll your phone (or TouchID-equipped Mac) on sites like GitHub.com and it’ll use the Secure Enclave for WebAuthn secrets. I’ve been doing this since 15.4 came out and it’s great. Prior to that, I used a Yubikey 5 with USB and NFC, which is still handy since that’s where I store TOTP seeds for less secure sites.
Passkeys extend that idea further by allowing you to register once and have it synced rather than having to register every device on every site[1].
That last part is important because AWS has a huge barrier: the number of MFA devices you get is one, which means you either need insecure things like synced TOTP seeds or you have to be comfortable never losing your Yubikey. I have been asking our TAM to prioritize fixing that for years so backups can be a real thing.
1. Over simplified a little - hear Adam Langley at https://securitycryptographywhatever.buzzsprout.com/1822302/... for the right version
Actually, can we mark AWS as insecure? Seriously, it was a bother at the time it was rolled out but now I could say that Amazon is insecure. If they could not bother with this, there are definitely more security holes intentionally hidden from the general public.
(Non-root MFA can be reset by another admin or root so this is most of a concern for the root account)
I fail to see how that can be true. How will they validate that it is you on the phone?
I classed that as more secure since you can't do it remotely and the in-person portion further increases the difficulty.
It's been a little over a year since I've done it but as I recall this is how it goes. You receive an email with a link that takes you to a site that starts a verification process via the phone. You get a number from the site that you are prompted to enter when they call you on the phone. Once that's done you can log into the account with the MFA device and then even remove the MFA device entirely.
The email address I believe can only be changed by AWS (and at least the last time this was an issue for me can't ever be reused for a new AWS account).
The phone number can be changed by anyone with aws-portal:ModifyAccount, which probably means someone with admin access. It is NOT restricted to being modified by the root account.
So if you have a working access to an account with that permission and access to the email you can change the phone number to one you have access to and go through the whole process. Meaning if you have the above permission you really only need access to the email.
Link to the documentation for this flow: https://aws.amazon.com/blogs/security/reset-your-aws-root-ac...
Both email and phone numbers have widely known and exploited vulnerabilities that won't ever be fixed (worse if the phone part is only SMS). Requiring both at the same time is OKish, but not any exemplary security.
I recently got a notification to create a separate AWS account (I don’t use it), and thought might as well enable 2FA. Added the first key. Looked for a way to add the backup key. Was confused, removed 2FA. What is that, lockout Russian roulette?
Apples plan is that I need to own several Apple devices for that, this is a non-starter for me.
Yubikeys have the advantage of working with all browsers
Passkeys: same, or one of the other participating devices.
Unfortunately ports are increasingly at a premium. You basically need to "mostly permanently" block the use of one of your USB ports for this to work. It's OK with my old MacBook Pro which has a USB port I mostly don't need to use for other purposes but thinner/lighter laptops don't have a lot of ports to spare.
That's why I use one of these rather than a yubikey: https://www.ftsafe.com/products/FIDO/NFC . I don't know why yubikey doesn't make a dual-method key when it's such an obviously nicer way to do things.
I personally was always forgetting my key when I worked in office. Or more likely I’d have the key and forget a USB A to USB C adapter (work was cheap and wouldn’t give out USBC keys).
My new job gives out USBC keys and I have yet to forget it when I needed it. They just don’t work as NFC on a phone.
Cybersecurity has been playing those silly games of "increasing security" and some 80% of recommendations were frankly BS
"longer passwords" yes. "password has to have symbols, numbers and be rotated every 3 mo" no
2FA yes, but not SMS, but not OTP because people get fished, blah blah blah
Not to forget the "put everything in a password manager" then you lose or forget your "extra safe random password" and are SOL
Meanwhile there are still incompetent people around that think asking for Mother's Maiden Name should be a security question
So where does it end?
It doesn't (can't) ever end because security is a process, not something you achieve and are done.
With ~inifite budget, one could achieve perfect security (but only for a clearly scoped threat model) for an instant, but both the infrastructure and the attackers move on, things constantly change, so it's not perfect anymore. And of course infinite budgets don't exist.
Obviously, no children should be allowed online even in a clean / locked down version of the internet. Ideally no ads/marketing should ever target children either.
I have the same impulse as most people that locking the internet down is a bad idea, but it seems like that is the only natural outcome eventually. We either stop abusing the internet and keep some form of freedom of speech / freedom (some countries values this more than others), or eventually the internet might become heavily regulated/controlled, which is the path we are currently on. Companies are already testing the waters with this, in some cases they are all ready committed to this (see self-hosting email vs big providers blocking small sender).
The problem of security is just an arms race towards the above, it is just a side effect because it is tolerated / no real consequences for misuse of the internet in most countries (that includes leaking data, being breached and data stolen, or just plain ol phishing - companies face zero consequences for data breaches).
Another way to think of it, you have a scale: on one side you have ultimate control, ultimate safety, no freedom - on the other side you have less control, less safety, but absolute freedom. The security arms race is just the shifting of balance between the two extremes.
I believe it was some part of oauth or saml (again not an expert here) where developers were making a common mistake by not verifying everything in the spec, leading to an easy bypass if you knew how it worked. Having devs implement a complex spec relating to authentication is a recipe for disaster.
As for running code in the environment there are many, many ways to deal with that. Obviously it's an easier environment to audit, but it's also much easier to control.
There's an old saying in photography, "the best camera is the one you have with you".
IMHO its very much the same thing with 2FA.
Any 2FA is better than no 2FA.
Sure some 2FA options are more secure than others, but by the same token, there's also a scary number of websites out there that have zero 2FA options. Others make it inordinately difficult to find (e.g. I'm looking at you Slack ... finding where to turn on 2FA in Slack is a nightmare).
Ironically there's no 2FA option for HN either. ;-)
No, I'm saying we need to come down to planet earth and recognise we live in the real world. Hence SMS or TOTP is preferable to nothing at all.
Its a bit like the hardcore open-source types who can't see the wood from the trees and cannot fathom why anyone would possibly want to use anything else other than Linux and fully open-source alternatives to Microsoft Office or Photoshop. Sometimes you have to compromise.
If for whatever reason you can't have anything else, MD5 is obviously better than plaintext. Not fine, but better.
With passwords you don't have external dependencies but with MFA, you do. Things are more complicated and real life is messy.
You can't even delete comments or your account on Hacker News, so it's not like it takes privacy or security seriously.
That's simply false because of the poor customer service of the providers and fates of many phones.
SMS is terrible because it is so easy to lose account access.
Phone broken/stolen? Completely locked out.
Or, I have this one financial institution that insists on sending SMS 2FA to the phone number on file, which is a 20+ year old landline which obviously can't receive SMS. Completely locked out. Someday I'll have to find out some way to get my money out of there (they have no local branches).
I will always use TOTP if at all possible, because it's not a single point of failure. I store the seed values securely and they are backed up, so can't be lost.
I hate TOTP, can handle SMS 2FA (sim-swapping is super rare here) and love FIDO/U2F/Webauthn (or whatever it’s called today). I have one with NFC on my keychain, and a backup device in the drawer. No off-site backup key, but encrypted backup codes.
worse than none because it "justifies" being sloppy with the first factor (i.e. account password).
edit: Your first sentence is meaningless because that is just as stolen with no 2FA.
False.
SMS 2FA is significantly, uncategorically, undeniably worse than no 2FA at all.
If your SIM card is hijacked, most websites/companies will quite happily let the impostor click a "Forgot password" link and get a SMS code to verify their identity, which will allow them into the account to take/change whatever other details they want at that time.
That's not 2FA. There is one single factor there, the SMS code.
SMS 2FA does not require you to have a 1FA backdoor, so you can't claim the latter is an inherent fault of the former.
For example, pairing "enter the SMS code" with "click the link we sent to your backup e-mail address" gets you a two-factor password recovery process.
That isn't the best or only method of 2FA password resets, it just comes to mind first because it's the last one I used and it is sufficient to prevent access via SIM hijacking alone.
I do feel though that SMS porting is such a lax system that using it as an authentication factor leads you into a lot of (SMS && social-engineering) situations that would be more preventable if SMS was not involved.
I say this fully realising that in this scenario the party allowing allowing these attacks to work due to poor understanding or lack of proper checks is the real problem.
What’s head-scratching to me is why tech-forward enterprises haven’t been faster to adopt unphishable forms of authentication like WebAuthn. I’m biased as I run an identity and access management company (stytch.com), but I hope more companies will consider integrating WebAuthn to support unphishable MFA.
Today, WebAuthn introduces some nuances that can discourage a B2C company from supporting it today (e.g. account recovery with lost devices), but it’s a clear win for corporate network/workplace authentication and B2B apps. I believe some of the lack of adoption is due to complexity to build (more complex than traditional MFA) and cost for off-the-shelf solutions (Incumbents like Auth0/Okta require ~$30k annual commitments to let developers use WebAuthn). If developers decide to build with Stytch, WebAuthn is included in our pay-as-you-go plan and can be integrated in an afternoon(https://stytch.com/products/webauthn)
What makes it unphishable is that the authentication is not based upon something that a user can be deceived into sharing with an attacker. Passwords and one-time passcodes (OTPs) can both be remotely acquired from users when attackers convince users to share these text-based verifications with them.
Because WebAuthn validates possession of a primary device that was previously enrolled (either the computer/phone the user is leveraging for the biometric check or the user's YubiKey), it's device-bound and cannot be phished.
Their 2fa is most likely okta or Duo style, in that the default authentication method is via push notification.
> Then they could just as likely proxy the hardware token handoff.
You can't do that because the security token itself receives the "relying party" in the form of the domain name it's trying to present authentication for. Requesting "uber.com" when on "ubeer.com" won't work.
WebAuthn is an ongoing project but the history goes back almost a decade to U2F, and the ongoing work has been carefully reviewed by a number of industry heavy-hitters. We know that it’s robust against phishing, too, which is why it’s so relevant to this conversation.
I’d also like to know more about your rationale for describing a system all of the major players have implemented as “unproven marketing hype”.
The history may go back almost a decade, as experimental technologies driven by industry working groups tend to do, but that work does not extend beyond the theoretical. If Facebook and Google implemented WebAuthn, they're still not staking their reputations on it. If they did, we wouldn't be using password-based logins nor MFA. Instead, they're slowly testing the waters in the real world, waiting to see how hackers respond to it. Consequently, WebAuthn remains on the bleeding edge, in the very early part of the adoption curve as it proves itself.
I think the naming here is causing confusion. This thread started about MFA usage, which is a chain of functionality going back to U2F:
> at this point, MFA that is not based on Webauthn (https://webauthn.guide/#about-webauthn) should be considered dangerously insecure.
That is broadly adopted and all of the companies you mentioned use it internally and and recommending it as the most secure form of MFA, based on both the strong phishing resistance and ease of use improvements, and I don't think that position I quoted is especially controversial in the security community other than that people in enterprise environments acknowledge the challenge of retrofitting older applications and services.
WebAuthn also allows you to setup passwordless login flows, which relies on some newer features which were added such as attestations about how the token was unlocked (i.e. corporate IT probably wants to require biometrics, not just a Yubikey-style tap). That is definitely newer, but again, you're talking about something which Microsoft and Apple have already shipped.
At one point U2F was simple - a USB token with a hardwired user presence button, providing a second factor alongside a username and password. Trivial to move between different computers and OSes. Secure even if the host OS can't be trusted. Physically unpluggable.
These days there's a mad variety of options. Options that are only secure if the host OS can be trusted. TPM-based options that are tied to a single laptop. Options like Windows Hello that are locked to a single OS vendor. Passwordless login, turning two factors into one. Copying credentials between devices, through the cloud. Sketchy low-cost biometric scanners.
For a security system, the latest versions sure are embracing a lot of complexity.
With that said, MFA in some form is better than none. However, some implementations provide better security than others (of course).
If you have knowledge on superior ways to protect users from MFA passthrough, please share it. I am always happy to learn about better ways of doing things. But contrarian bandwagoning without providing effective alternatives isn't helpful.
There was literally no training involved for this during my time at ElGoog. One wiki page covered it adequately.
For starters, how do you register the Yubikey? On Okta, this is a multi-step process with at least one non-obvious step, and one easy way to screw it up.
This was _social engineering_, something that even the finest MFA algorithms don't guard against.
And even if they do, they likely have a “backup” for people who never seem to be able to use the Yubikey right.
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.
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.
- Socially engineer an employee to get on their VPN (could have been prevented with webauthn / hardware 2fa)
- Once on VPN, scan their intranet and find a network share
- Network share has powershell scripts with admin credentials for their PAM vendor, Thycotic
- From there can get full access to all systems
Zero-trust may be a security meme at this point, the whole point of zero-trust is to make it so that once on your VPN, all of your stuff isn't immediately pwned. You're supposed to have authentication at all layers, not just the corporate VPN edge. An insecure network share is a ticking time bomb, even if it's behind a VPN, because you now have to hope and pray all of your VPN users aren't bribable, aren't morally bankrupt, aren't disgruntled, etc. The same thing could have happened via insider from the lowest level of employee with VPN access if that report is true.
It's become a "meme" because it is used in endless irrelevant ways. So many companies are pushing zero-trust solutions that don't have anything to do with the basic idea of requiring access control at every endpoint.
Also, while it is a very sound practice, there's also the hyped idea that it replaces everything else. Which is not very wise. You still want defense in depth over and above requiring acess control everywhere.
Pretty much any time a new security concept comes up vendors race to say that they implement it, whether they do or not.
With Zero trust, it's hardly a new idea (e.g the Jericho forum de-perimeterization) but it's hard to implement well across all systems.
Hedgehogs dont have this problem.
This is gross incompetence.
Did their IDS/IPS not go off on this? I wonder if this was a sophisticated scan designed to go slow and evade detection or if it was just nmap lol
I can't wait for the post-mortem, hopefully lots of good lessons to learn.
Assuming screenshot is real[0], they have over 1PB in their Google Drive, so chances are everyone just uses Google Drive with shared drives, and employees use Drive for Desktop (previously drive file stream)[1]. Shared drives are pretty powerful and access to them can be gated at the same level as you can regular Drive files.
My theory is that some high-level IT person either got phished and didn't have hardware 2fa, or that high-level IT person downloaded malware / got RAT'd and the Google Drive scanning was done in the background on their machine. Depending on the hierarchy, it might not have even been a scan, could've been the attackers sating their curiosity by browsing through all their internal files and happening to find some PAM credentials.
0: https://twitter.com/praise_terryd/status/1570583105123258369...
1: https://support.google.com/a/answer/7491144?hl=en#zippy=%2Cw...
Even using certificate based authentication for VPN along with their existing MFA would have prevented this. Unless the attacker compromised the employee's laptop in which case nothing would stop that.
We used online MFA (you had to respond to MFA requests on your phone). Not even sure why this is a discussion as the hacker confirmed it was a case of social engineering. No MFA protects against social engineering (no, not even ____ - don't try to convince me).
And yes, at least when I was there, there was pretty good training on SE deterrence.
Further, OneLogin was used, Yubikeys were phased out early on. I'd be surprised if they had brought them back, as I remember the security team being somewhat averse to them. I'm sure OneLogin is also investigating.
The security team at Uber was quite good. Constantly under stress. Constantly overworked. The last thing they need are knowitalls speculating about how stupid they are on HN. Cut them some slack - this could happen to any company (yes, it could, even yours - don't try to convince me otherwise).
Certain MFAs can protect against more types of attacks than others. You covering your head in the sand when people point that out doesn't change that fact but merely indicates you prefer feeling right to being right.
>as I remember the security team being somewhat averse to them
So you're saying that the security team was averse to the thing that would have prevented this hack? And that means we shouldn't put blame on them?
There's a lot of cognitive dissonance in discussion around this story IMO. Nowadays I assume everyone has been or will be pwned, because no breech surprises me anymore. Any small gap can and will be exploited, and as organisations grow the surface area only gets larger and larger. The only way to truly secure data is to not put it on the internet from the jump. For every breach that's published, there's likely a dozen that we never find out about.
That's true - some kinds of social engineering cannot be prevented by technical means. BUT hardware keys prevent an entire class of extremely common attacks that every other form of MFA is vulnerable to. It would have prevented the method of compromise used here.
Any company not using FIDO/WebAuthn in 2022 is behind on best practices.
What security team on earth would be against these?
Don't you know that sh*tting on everyone else and saying that how you could do it with only 5 people are the traditions of HN...
[1] https://twitter.com/Savitar0x01/status/1570580235716014081
* Social engineering successfully got someone
* MFA approach did not protect from a simple fake webpage tunneling hack
* VPN was based on a password rather than a certificate
* Network scan was not detected and stopped
* High level credentials were stored in a public file and not detected
* Abnormal credential usage was not detected and stopped
I probably missed a few but point there were many ways to stop this hack and all of them were broken. This wasn't some highly funded government operation that bypassed layers through clever approaches and expensive zero-day exploits.
Imagine deciding to add some extra floors to your office made from cardboard because, "we are scaling too quickly to build them out of concrete". Wouldn't happen. Why? The legal and marketing fallout would be fatal.
In the corporate world, especially in ones at the extreme levels of inefficiency/size/etc. it is easy just to blame the previous job holder, the previous culture, "we have made improvements since then" etc. as if that makes it alright.
tbf, we also see this in Healthcare and Government so I think it is Human Nature rather than corporate greed.
At this point it appears that they found more credentials on the internal network and owned SSO, MFA and AD giving admin access to everything.
That's my hangup. The fact that admin/root level accounts can be accessed with "credentials" alone, rather than only via SSO/MFA/Yubikey. Were these service accounts, what happened to least privilege?
SSO can go down or get owned so having break glass credentials isn't unheard of. The last place I worked at had them on paper in a safe in their headquarters. The Twitter threads show that they were stored in a password manager but the hacker was able to find credentials to access it which could have been one of the responsiblities of the employee which was targeted.
If you have your password manager on SSO it will be even easier.
EDIT: Comms not comma. I'll leave the typo because I LOVE bombcar's comment about the semicolon. Confused at first, but I smiled
(I’d assume going to text messaging to set something up, which is why you should know enough about your immediate coworkers to verify their identity via non-public information.)
With everything cloud now, how do you recover your cloud account of the master got compromised?
And they had an entirely separate IT setup that wasn’t related to yours.
> at Uber, we got an “URGENT” email from IT security
> saying to stop using Slack. Now anytime I request a
> website, I am taken to a REDACTED page with a
> pornographic image and the message “F** you wankers.”
From: https://twitter.com/samwcyo/status/1570583182726266883
> saying to stop using Slack. Now anytime I request a
How does an employee know if that message is legitimate or not? If you break into a secure system, mass-emailing all employees saying "URGENT: WE HAVE BEEN HACKED. PLEASE EMAIL YOUR PASSWORD AND SSN TO THIS ADDRESS IMMEDIATELY." is sure to get some percentage of success.
This could lead to a scenario where no one knows what to believe, internal systems are down, attackers are setting up fake IR channels to get even more info, etc. There’s no way most companies could weather an onslaught like that.
What’s head-scratching to me is why tech-forward enterprises haven’t been faster to adopt unphishable forms of authentication like WebAuthn. WebAuthn supports both built-in device biometrics like FaceID/TouchID and external hardware keys (eg YubiKey), which are inherently incapable of being phished — there’s no text-based secret for an attacker to deceive a user into sharing with them.
I’m biased as I run an identity and access management company (stytch.com), but I hope more companies will consider integrating WebAuthn to support unphishable MFA.
Today, WebAuthn introduces some nuances that can discourage a B2C company from supporting it today (e.g. account recovery with lost devices), but it’s a clear win for corporate network/workplace authentication and B2B apps. I believe some of the lack of adoption is due to complexity to build (more complex than traditional MFA) and cost for off-the-shelf solutions (Incumbents like Auth0/Okta require ~$30k annual commitments to let developers use WebAuthn). If you decide to build with Stytch, WebAuthn is included in our pay-as-you-go plan (https://stytch.com/products/webauthn)
Perhaps they just don't care about security?
For decades I've been told that security through obscurity is no security at all, but in the back of my mind, I think it might be the best thing I've got going for me working at a small place. Though I should say, that's far from being our only security - we do work at it too.
If I'm thinking about it, I can be assured that someone with differing motivations likely already has, or soon will be thinking about the same.
Small startups and businesses can absolutely get it right. It's usually much easier, with a small number of people and systems involved. You just have to approach it knowing it will take work every day. Some things will be harder than you want them to be. It will be worth it to avoid this kind of stuff.
In a well run organization it takes a lot more than that. There were a dozen steps in this exploit chain where it could have been detected and blocked. Likely Uber didn't care about security and their security team lacked both political power and resources.
Just don't rely on only that layer, and watch out for oddly quiet individuals named Sam Sepiol.
Developers do not give a shit. Security is not something they're trained in, interested in, or competent in (though they often think they are).
Security is a couple of people trying to bucket out the water as fast as they can from every sinking ship while developers are taking a piss on the floor and poking holes in the hull.
I think the bar for devs is extraordinarily low and we'll keep seeing this sort of thing until it we collectively raise it. Thankfully it seems like, very recently, this is starting to maybe happen. Packages requiring 2FA is the first thing I've seen that seems to indicate that developers are going to have to do the bare minimum for security in order to participate.
Believe it or not, it's much easier to successfully phish a big company where you have unlimited pool of emails to tap into.
You /have/ to treat uber and the like as though they are organised crime even if you think they are and will always be in league with rainbows, fairies and unicorns will never put your interests behind theirs.
edit: wave to uber's PR flunkies.
Additionally even if the information might not be admissible in US courts, it is in other countries making travel for those individuals very uncomfortable.
Isn't this illegal as fuck?
This was part of Uber's early strategy when cities responded with citing drivers of rideshare services. At this point, I've seen a rideshare stop in the center of an intersection with traffic to let people out, so maybe the cities were right in the end...
While I understand not wanting those passwords in Google's hands, the reality is that they do have the $$$ for security.
But instead of being able to leverage that functionality, and the Generate Password functionality we now have to resort back to name_of_application_my_name or something like that.
Do not ban things just because it has an issue. Provide a better alternative.
Also this has nothing to do with passwords in Google's hands. They could turn off syncing in Chrome and have a completely local password manager. I personally do exactly that.
Your org will suffer many data breaches due to this policy.
"We're told that an employee was socially engineered by the attacker to gain access to Uber's VPN, through which the intruder scanned the network, found a PowerShell script containing the hardcoded credentials for an administrator user in Thycotic, which were then used to unlock access to all of Uber's internal cloud and software-as-a-service resources, among other things.
After that, everything was at the intruder's fingertips, allegedly.
The New York Times reported that Uber staff were told to stop using the corporate Slack, and that the call to quit the chat app came after the intruder sent a message declaring: “I announce I am a hacker and Uber has suffered a data breach.”
The Times stated the Slack message listed “several internal databases that the hacker claimed had been compromised.” Various corporate systems have now been shut down by Uber."
""Instead of doing anything, a good portion of the staff was interacting and mocking the hacker thinking someone was playing a joke," Curry said. "After being told to stop going on slack, people kept going on for the jokes."
Evidence of that misunderstanding has surfaced on Twitter in the form of a screenshot of Uber's private Slack workspace."
The message: https://nitter.net/vxunderground/status/1570626503947485188
In fact it was always insecure I would say. All you need is wifi password and you have tonnes of super sensitive information on windows shares
I'm confused. Was the hacker claiming to be an IT person or was it the Uber worker?
Smartcards exist, but their use is clunky in practice (I'm aware Yubikeys may now function this way). For everything else, Microsoft's current MFA solution is "just use the cloud".
You don't need the application to, only your IDP. Everything should be SSO from there.
Is remaining in a role in which it's not possible to be effective negligent?
Maybe swes should start facing legal liability for thier failings like most other engineering disciplines. We would see this problem change overnight.
Another factor is that a lot of people have jobs where they're really busy and deal with a lot of e-mail from people with all kinds of bizarre communication styles. Catch one of them with the right e-mail on the right day, and you'll get a careless click.
Black hats get to try every day across lots of people, and they only need it to work one time against one person to score.
Careless click is not enough to compromise someone unless they are also running software that is not up to date. For example, how do you compromise someone if password login is disabled in all of the systems?
This is bottom of the barrel phishing. Attacks against big companies get _far_ more sophisticated. Things like complete mocks of internal login sites, realistic internal emails. There's big money in hacking big companies, and plenty of shady characters willing to invest in a potential payoff
Bottom line is Uber got pwned, and the dirty laundry is now out in the open for all to see and inspect. Tomorrow it'll be for sale on the darkweb.
Normal users stand no chance, especially when there are URLs that are sketchy because oops, saasprovider already has a customer with your requested url, so you end up with
mycompany0.saasprovider.com or mycompany-1.saasprovider.com
Its terrible practice all around and lazy systems and services administration
https://secure07a.chase.com/web/auth/#/logon/logon/chaseOnline?treatment=chase&lang=en
Can you elaborate what scrub means in this context? In what ways would this breach cover up the 2016 breach? Would the prosecutors suddenly lose their memory of the 2016 breach? Would evidence suddenly go missing?
Do you have citation for this?