3 ms·

Yes, MFA would have helped here, but I think it's besides the point. I've worked on a lot of projects, including one for a major stock exchange, and I've never

Yes, MFA would have helped here, but I think it's besides the point. I've worked on a lot of projects, including one for a major stock exchange, and I've never seen perfect security. It's too slow. Even if you had MFA for the VPN, it doesn't stop local malware from being able to use the foothold to gain access to the network once the MFA is cleared. I'm not saying that MFA is useless, just that these types of things are very hard to get right and we only hear about the times the attackers got through. "Oh they should have done X" where X is any one of an increasingly long list of possible things they should have done ranging from security headers on their website, to MFA, to auditing their third party libraries, to locking down their development machines and networks (during Covid, ha!) it's never ending. The very best at it get by without total calamity, but the long tail of organizations just don't have the right staff, focus, or resources to do it. Edit: I'm not saying it's right! I don't think it is right, and I've worked with governments to bring in regulations in certain industries, but to characterize this all on one failure kinda misses the point. There is a broader, harder problem that I'm not sure is even solvable.

genmud 5y ago
Going to have to hard disagree there. MFA and addressing password reuse is table stakes in 2021. Like this is literally the first item I would do as a CISO in any company. MFA is among the core security items like running endpoint protection, updating your software or filtering spam. Bucketing it with things like CORS or auditing third party libraries is either disingenuous or extremely naive.
- 3pt14159 5y ago
  Look, MFA for access to code repositories or a cloud is one thing, but if you think that MFA is "table stakes" for a VPN I don't know what to tell you other than "then very few orgs are doing table stakes with their VPNs." These types of arguments are so hard to have over HN, because people with actual experience across all sorts of organizations can't explicitly say what they have seen and where because of NDAs and we all have our own viewpoints and individual experience. Bucketing MFA into one broad concept is as disingenuous as calling out security headers as being as benign as CORS. Does your org have MFA on SSH? On email? On the code repo? On the Slack login? On the VPN(s)? Etc. Etc. I have yet to see a single org that had MFA on everything and blaming a lack of MFA on the VPN misses the point. If they'd had it there, the attackers would have hit elsewhere. Most developers install random software and browser toolbars that they'll never have time to check and connect directly to their companies servers, repos, and communication tools. Pretending like MFA on a VPN would have magically solved everything is a pipedream. There are too many ways in, and every time someone gets in the response from the software community is always "oh why didn't they do X" while ignoring the larger truth: There are too many threat vectors and getting them all right, at all times, is nigh on impossible.
  - vlovich123 5y ago
    Yup. Every major tech company I’ve seen uses MFA + SSO for everything (including VPN and ssh). Many are even abandoning VPN because it doesn’t really give you what you want for security (vs something like BeyondCorp which is rapidly becoming the “right way” to do these things). There’s no silver bullet that magically stops all attacks so your position feels a bit extreme. MFA would have stopped this particular attack (so would have disabling inactive accounts or scanning for password existence on leak databases). Expect future attacks to focus on unrevoked lost/stolen yubikeys.
    - tialaramex 5y ago
      > Expect future attacks to focus on unrevoked lost/stolen yubikeys. If the Yubikey is serving as a FIDO Security Key (rather than in one of its other modes) then this is much trickier than it might look. Suppose you find my Security Key in the street, or left behind on public transit. It has no idea who it belongs to! All it is capable of doing is proving that it's still the same Security Key as before, which it is. I use that Security Key to sign into Google, Facebook, GitHub, and a dozen more, but the Security Key itself has no memory of any of that, it's a blank slate. The Security Key works perfectly well, maybe you can eBay it, but you can't realistically break into accounts with it. The alternative is stealing keys to order. But this involves connecting up two very different skill sets, one of which requires physical proximity. That's a tall order for everybody but nation state adversaries. If you're an Indian organised crime syndicate, hacking some IT systems in Texas is likely practical for you via the Internet, but flying a member out to Dallas to try to steal a physical object from the right person is both unduly risky (local cops might be bought off, but the cops in Dallas don't know you from Adam) and surprisingly expensive.
      - vlovich123 5y ago
        You don’t think there’s a possibility of timing attacks that can be used (eg use the yubikey for an account under your control on the same service)? Might be hard for corporate keys obviously… m Also there’s a baked in assumption that the HW for these is secure. They’re probably pretty good but I don’t know how resistant they would be to a physical attack to figure out the domains. I agree that these attacks will get more expensive but I it’s still too early in the adoption cycle for me to conclude this is an unmitigated hard stop against these kinds of attacks vs just a speed bump. Another area of weakness one can expect is the use of automated system accounts. Those are still in the Wild West age in terms of being constructed Willy Nilly, having lots of privileged access to internal systems without real access nor auditing controls, no expiry, and sometimes even offer login access.
- technion 5y ago
  I agree with you in the sense that those are literally the first thing I would do as a CISO anywhere too. But I've long accepted that this is why you or I will never be CISO of an organisation like this. I've worked alongside such people, and they'd be horrified that thread isn't all about a logon disclaimer on that VPN.
wepple 5y ago
It’s not beside the point. MFA substantially raises the effort required of the attacker. Malware on a workstation with VPN access is a far higher bar than just being able to log directly in to a VPN with stolen/guessed creds.

genmud 5y ago

Going to have to hard disagree there. MFA and addressing password reuse is table stakes in 2021. Like this is literally the first item I would do as a CISO in any company. MFA is among the core security items like running endpoint protection, updating your software or filtering spam. Bucketing it with things like CORS or auditing third party libraries is either disingenuous or extremely naive.

3pt14159 5y ago
Look, MFA for access to code repositories or a cloud is one thing, but if you think that MFA is "table stakes" for a VPN I don't know what to tell you other than "then very few orgs are doing table stakes with their VPNs." These types of arguments are so hard to have over HN, because people with actual experience across all sorts of organizations can't explicitly say what they have seen and where because of NDAs and we all have our own viewpoints and individual experience. Bucketing MFA into one broad concept is as disingenuous as calling out security headers as being as benign as CORS. Does your org have MFA on SSH? On email? On the code repo? On the Slack login? On the VPN(s)? Etc. Etc. I have yet to see a single org that had MFA on everything and blaming a lack of MFA on the VPN misses the point. If they'd had it there, the attackers would have hit elsewhere. Most developers install random software and browser toolbars that they'll never have time to check and connect directly to their companies servers, repos, and communication tools. Pretending like MFA on a VPN would have magically solved everything is a pipedream. There are too many ways in, and every time someone gets in the response from the software community is always "oh why didn't they do X" while ignoring the larger truth: There are too many threat vectors and getting them all right, at all times, is nigh on impossible.
- vlovich123 5y ago
  Yup. Every major tech company I’ve seen uses MFA + SSO for everything (including VPN and ssh). Many are even abandoning VPN because it doesn’t really give you what you want for security (vs something like BeyondCorp which is rapidly becoming the “right way” to do these things). There’s no silver bullet that magically stops all attacks so your position feels a bit extreme. MFA would have stopped this particular attack (so would have disabling inactive accounts or scanning for password existence on leak databases). Expect future attacks to focus on unrevoked lost/stolen yubikeys.
  - tialaramex 5y ago
    > Expect future attacks to focus on unrevoked lost/stolen yubikeys. If the Yubikey is serving as a FIDO Security Key (rather than in one of its other modes) then this is much trickier than it might look. Suppose you find my Security Key in the street, or left behind on public transit. It has no idea who it belongs to! All it is capable of doing is proving that it's still the same Security Key as before, which it is. I use that Security Key to sign into Google, Facebook, GitHub, and a dozen more, but the Security Key itself has no memory of any of that, it's a blank slate. The Security Key works perfectly well, maybe you can eBay it, but you can't realistically break into accounts with it. The alternative is stealing keys to order. But this involves connecting up two very different skill sets, one of which requires physical proximity. That's a tall order for everybody but nation state adversaries. If you're an Indian organised crime syndicate, hacking some IT systems in Texas is likely practical for you via the Internet, but flying a member out to Dallas to try to steal a physical object from the right person is both unduly risky (local cops might be bought off, but the cops in Dallas don't know you from Adam) and surprisingly expensive.
    - vlovich123 5y ago
      You don’t think there’s a possibility of timing attacks that can be used (eg use the yubikey for an account under your control on the same service)? Might be hard for corporate keys obviously… m Also there’s a baked in assumption that the HW for these is secure. They’re probably pretty good but I don’t know how resistant they would be to a physical attack to figure out the domains. I agree that these attacks will get more expensive but I it’s still too early in the adoption cycle for me to conclude this is an unmitigated hard stop against these kinds of attacks vs just a speed bump. Another area of weakness one can expect is the use of automated system accounts. Those are still in the Wild West age in terms of being constructed Willy Nilly, having lots of privileged access to internal systems without real access nor auditing controls, no expiry, and sometimes even offer login access.
technion 5y ago
I agree with you in the sense that those are literally the first thing I would do as a CISO anywhere too. But I've long accepted that this is why you or I will never be CISO of an organisation like this. I've worked alongside such people, and they'd be horrified that thread isn't all about a logon disclaimer on that VPN.

wepple 5y ago

It’s not beside the point. MFA substantially raises the effort required of the attacker. Malware on a workstation with VPN access is a far higher bar than just being able to log directly in to a VPN with stolen/guessed creds.