Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Microsoft Security IT

Microsoft: Hackers Using 'Concerning' Tactic To Dodge Multi-Factor Authentication 74

Posted by msmash from the PSA dept.
Microsoft says token theft attacks are on the rise. From a report: Microsoft has outlined several mitigations to protect against attacks on multi-factor authentication that will unfortunately make life more difficult for your remote workers. Three years ago, attacks on multi-factor authentication (MFA) were so rare that Microsoft didn't have decent statistics on them, largely because few organisations had enabled MFA. But with MFA use rising as attacks on passwords become more common, Microsoft has seen an increase in attackers using token theft in their attempts to sidestep MFA.

In these attacks, the attacker compromises a token issued to someone who's already completed MFA and replays that token to gain access from a different device. Tokens are central to OAuth 2.0 identity platforms, including Azure Active Directory (AD), which aim to make authentication simpler and faster for users, but in a way that's still resilient to password attacks. Moreover, Microsoft warns that token theft is dangerous because it doesn't require high technical skills, detection is difficult and, because the technique has only recently seen an uptick, few organisations have mitigations in place. "Recently, the Microsoft Detection and Response Team (DART) has seen an increase in attackers utilizing token theft for this purpose," Microsoft says in a blogpost. "By compromising and replaying a token issued to an identity that has already completed multifactor authentication, the threat actor satisfies the validation of MFA and access is granted to organizational resources accordingly. This poses to be a concerning tactic for defenders because the expertise needed to compromise a token is very low, is hard to detect, and few organizations have token theft mitigations in their incident response plan."
This discussion has been archived. No new comments can be posted.

Microsoft: Hackers Using 'Concerning' Tactic To Dodge Multi-Factor Authentication More

Microsoft: Hackers Using 'Concerning' Tactic To Dodge Multi-Factor Authentication

Comments Filter:

  • I find it hard to take seriously an authentication protocol that is vulnerable to token replay. Wouldn't adding a time stamp and/or sequence number, protected by a cryptographically-secure hash, prevent token replay?

    • Just hash the last successful response and prevent another login until the challenge has refreshed.

    • Re:why is token replay possible? (Score:4, Informative)

      by d0ran$ ( 844234 ) on Friday November 18, 2022 @12:02PM (#63061341)

      It is a well known issue with TOTP replay. The RFC (https://www.rfc-editor.org/rfc/rfc6238#section-5.2) does highlight the issue

      " ...
        Note that a prover may send the same OTP inside a given time-step
            window multiple times to a verifier. The verifier MUST NOT accept
            the second attempt of the OTP after the successful validation has
            been issued for the first OTP, which ensures one-time only use of an
            OTP. ...
      "

      Other schemes such as HOTP and U2F explicitly prevent replay...

    • Re: (Score:2)

      by PPH ( 736903 )

      My garage door opener will not permit token replay.

      • My garage door opener will not permit token replay.

        Yea it will. All an attacker has to do is collect a bunch of "tokens" while blinding the GDO. Next they send the oldest one of the lot to the GDO so that it will finally close and you'll leave already.

        After you are gone they replay the next oldest token, pair their own remote to your garage door to persist access and steal all your shit.

    • I find it hard to take seriously an authentication protocol that is vulnerable to token replay. Wouldn't adding a time stamp and/or sequence number, protected by a cryptographically-secure hash, prevent token replay?

      This is a red herring. The issue is granting tokens to phishers in the first place not whether or not they can be "replayed".

      This is an avoidable problem with solutions (e.g. mutual PKI auth) in production use for literally decades. It's just Microsoft is grossly incompetent and can't help but constantly attempting to poorly reinvent the wheel so we are constantly treated to this nonsense.

    • Because at some point you have to go back to something password-like for auth. A lot of the lets-replace-password protocols are just a big pile of smoke and mirrors hiding the fact that what's going on behind the scenes is still pretty close to password auth. And that's not any kind of deliberate deception, it's because passwords have a bunch of properties that make them really, really hard to replace [ieee.org], and replacements are often just pay-no-attention-to-the-password-behind-the-curtain smoke and mirrors hi

      • Because at some point you have to go back to something password-like for auth. A lot of the lets-replace-password protocols are just a big pile of smoke and mirrors hiding the fact that what's going on behind the scenes is still pretty close to password auth. And that's not any kind of deliberate deception, it's because passwords have a bunch of properties that make them really, really hard to replace [ieee.org], and replacements are often just pay-no-attention-to-the-password-behind-the-curtain smoke and mirrors hiding the fact that when the rubber meets the road, it's some password-equivalent mechanism doing the work.

        I wasn't able to read beyond the abstract of your IEEE reference, but accepting that passwords have good properties, what does this have to do with replay attacks? Even if you use a password to establish your identity, the token which remembers that shouldn't be able to be replayed.

  • "When the user is phished, the malicious infrastructure captures both the credentials of the user, and the token," Microsoft explains. If both credentials and the token are stolen, the attacker can use these for numerous attacks. Microsoft highlights business email compromise, which is the largest cause of cybercrime financial losses today.

    Should the token issued be specific to the particular machine the user is logging from? Or its a man in the middle capturing the password of the user and then obtains a auth token from Microsoft? How the token issued to the user for the user's machine, and ip address combination can be replayed from another machine?

    Looks like Microsoft added some convenience feature, portable auth tokens not tied a particular machine or ip address opening the door for hackers?

    • Re: (Score:3)

      by Bert64 ( 520050 )

      IP addresses change, there are dynamic addresses, privacy addressing, pooled nat gateways, shared addresses etc. Plus if someone is able to mitm your connection they have access to the link and can originate from the same address.

      Machines are identified based on the tokens sent (ie usually by setting cookies to track individual devices), so it's fairly easy to spoof as a trusted machine.

      • I agree, it is easy to spoof the device.

        Almost all the streaming providers, including YouTube and Netflix spend enormous resources in identifying where the streams end up, people sharing passwords to streaming account etc. So the auth token could include some tracert info that is invariant. If the auth token is coming from a device the packets are going back to significantly different path, token could be invalidated or a new auth might be issued. I mean auth was issued to Boondocks, Pennsylvania area des

        • Re: (Score:2)

          by Bert64 ( 520050 )

          The hacker just needs to compromise a single device in the area, any random insecure device will do. This isn't hard to achieve at all.

          Ping times vary due to load, signal strength, interference, routing changes etc - even for the same user.

  • 2022 (Score:3)

    by DarkOx ( 621550 ) on Friday November 18, 2022 @11:58AM (#63061327) Journal

    This should not really be a surprise

      yes yes not the same explicit expiration, claims, blah blah

    - zoom out far enough and tokens are just fancy passwords. This was always going to be the next move in the arms race. Which is not say anything is 'wrong' with token based authA/authZ schemes just that its not a surprise the token is going to become a/the target .

  • Recommended Mitigations (Score:5, Informative)

    by nuckfuts ( 690967 ) on Friday November 18, 2022 @12:00PM (#63061333)

    In case you're wondering, here are the recommended mitigations:

    To counter the threat of token theft attacks on MFA, Microsoft recommends shortening session and token lifetimes, though this has a convenience cost to the user. Mitigations include:

    Reducing the lifetime of the session increases the number of times a user is forced to re-authenticate
    Reducing the viable time of a token forces threat actors to increase the frequency of token theft attempts
    Microsoft recommends implemeting Conditional Access App Control in Microsoft Defender for Cloud Apps for users connecting from unmanaged devices
    Microsoft also recommends implementing FIDO2 security keys, Windows Hello for Business, or certificate-based authentication for users.

    Users with high-level privileges, such as the Global Domain admin, should have a segregated cloud-only identity. This will help reduce the attack surface from on-premises to cloud if an attacker compromises on-premises systems. These identities should not have a mailbox attached to them, Microsoft said.

    • This will help reduce the attack surface from on-premises to cloud if an attacker compromises on-premises systems.

      hmm

      • Re: (Score:2)

        by EvilSS ( 557649 )

        This will help reduce the attack surface from on-premises to cloud if an attacker compromises on-premises systems.

        hmm

        Hmm what? It's standard best practice. In case a local admin account is compromised, it prevents that account from being used to also compromise the cloud tenant. It's the same reason we recommend admins not use their AD accounts to manage VMWare or other hypervisors, as that is another popular vector for jumping from PCs to the hypervisor hosts. It's why we recommend admins keep separate admin accounts, ideally protected with a PIM, and NOT use it as their everyday user account.

        • Re: (Score:2)

          by Bert64 ( 520050 )

          If a domain admin account is compromised then you gain access to all other accounts (via multiple methods) in any case.
          If it's an admin account of something else then it's potentially not so bad.

          • Re: (Score:2)

            by EvilSS ( 557649 )
            In the on-prem AD yes. But this method prevents that admin-level compromise from flowing into the cloud tenant. That's the entire point of making sure your on-prem domain admins are not also GA's in Azure AD (or admins in anything else you federate on-prem AD/LDAP with).
        • Attack surface is a specific term, and you have far more potential control over limiting attack vectors on prem than you do in the cloud, even if the cloud may have better security in other ways (depends on your personnel and physical security). The surface itself isn't smaller, and you can't air gap the cloud. Compromised accounts aren't limited to physical presence.

          • Re: (Score:2)

            by EvilSS ( 557649 )
            In theory, sure. In reality though, the attack surface area of the on-prem network is usually much larger than the cloud. No one outside a small subset of orgs air-gaps their company, especially today. And, unfortunately, as much as we advise against it, pretty much every org has end users. How many big hacks start out with a compromised remote PC and a VPN connection? Or an on-prem user clicking on something stupid? Quite a damn few. Over the past 3 years, every single time I've been pulled into a situati

    • In case you're wondering, here are the recommended mitigations:

      To counter the threat of token theft attacks on MFA, Microsoft recommends shortening session and token lifetimes, though this has a convenience cost to the user. Mitigations include:

      Reducing the lifetime of the session increases the number of times a user is forced to re-authenticate
      Reducing the viable time of a token forces threat actors to increase the frequency of token theft attempts
      Microsoft recommends implemeting Conditional Access App Control in Microsoft Defender for Cloud Apps for users connecting from unmanaged devices

      These are not mitigations they are fundamental misunderstandings of the problem.

      Microsoft also recommends implementing FIDO2 security keys, Windows Hello for Business, or certificate-based authentication for users.

      Well hey even broken clocks are right twice a day. Too bad Microsoft is actively doing away with certificate based authentication (e.g. "legacy authentication") in exchange.

      Users with high-level privileges, such as the Global Domain admin, should have a segregated cloud-only identity. This will help reduce the attack surface from on-premises to cloud if an attacker compromises on-premises systems. These identities should not have a mailbox attached to them, Microsoft said.

      That's just swell but if this problem isn't fixed the answer is still "segregated" phishing attacks.

  • If an authenticated user (token) pops up on a new IP/device, require re-authentication?

    • Re: (Score:2)

      by zlives ( 2009072 )

      yes just pay for that conditional access license.

    • What about roaming between IPs?
      Some features must be limited... why are these tokens leaking easily? they are temporary but should be treated as securely as a type of password.

      • Re: (Score:2)

        by ebonum ( 830686 )

        ADP and my bank make me log back in.

        • AS THEY SHOULD!
          Convenience features shouldn't beat out security all the time.
          When it doesn't matter then ok... stop fucking demanding my texting phone number "for security" for your throw away website! We all know they are planning to leverage that data in the future... hell, their only profit might be when they sell their business and their biggest asset could be their database!

  • Microsoft Circumvents its own security (Score:3)

    by ironicsky ( 569792 ) on Friday November 18, 2022 @12:22PM (#63061395) Journal

    Windows 11 has some interesting security circumvention problems.

    My workplace disabled facial recognition, finger print login, and pin login. I've enabled all of them due to a bug in Windows.

    It seems Microsoft security schemes may need fixing all across their ecosystem

    • Re: (Score:3)

      by gweihir ( 88907 )

      It seems Microsoft security schemes may need fixing all across their ecosystem

      Always have. MS does not take security seriously, never has. To make matters worse, MS does not understand security and never has.

  • Simple mitigation, long-established: pin the token to the source address that authenticated. Any use of a token from any other source address is invalid and triggers re-authentication. It isn't perfect but it makes things much much harder for the attacker.

    • Re: (Score:2)

      by DarkOx ( 621550 )

      Does not work. Even if you don't have portable devices moving between networks, wireless to wired, wifi to mobile etc - you still have CGNAT.

      If the connection isnt kept alive you really can't count on the device coming from the same IP address from one request to another. I guess you could PIN to the source AS (CIDR allocation) and probably not break legitimate clients but that also probably doesn't thwart attackers all that effectively, who can probably get or are on the same carrier network.

      As far as PINi

      • Re: (Score:2)

        by Bert64 ( 520050 )

        Also if someone is in a position to mitm your connection, they are generally in a position to originate traffic from the same address you're using anyway.

  • My company just had a security audit and they strongly recommend using MFA to secure our infrastructure against remote attacks. I even pointed out a few articles warning about the MFA vulnerabilities at the time and yet they still insisted on this being the solution to secure accounts. Every time I see an article like this one I keep asking myself why we even bothered to have an audit if they recommend stuff that is already showing so many signs of security issues.

    • Auditors are checkbox tickers.
      They check you comply with either law or best practices. Reality often matches well with those two, but sometimes doesn't.

      I have pretty much the same experience as you.

      • I'm glad I'm not the only one seeing such a thing.

        I just feel management just wanted the audit to then follow the recommendations and cover themselves if something happens and blame the auditors.
        It just grinces my teeth knowing how much we now need to spend on an MFA authentication on a monthly basis on top of the fee that was given to these auditors.

      • And in practice, auditors don't even ensure that you are complying with the law. They just kind of glance over and see if anything looks funny.

    • Re: (Score:2)

      by King_TJ ( 85913 )

      Yep! Where I work, the cyber-insurance provider demanded we reduce our MFA token expiry time to no more than 1 day maximum. (Previously, if our users check-marked the option to remember their login, it would stop popping up MFA prompts for up to 45 days.)

      I'm not saying 45 days wasn't too long ... but 1 day is terrible by comparison. We already have multiple domains so anyone accessing a resource on one domain while last using another gets a new MFA prompt, anyway. For some of our users with multiple devices

    • Most security features are flawed in one way or another, nothing is perfect...
      Implementing MFA, especially if doing a good job of the implementation will generally improve your security and not weaken it in any way.

      The problem when people blindly follow and think something is perfect. Pretty much everything is flawed in some way, but so long as you understand the risks you can take steps to mitigate them.
      Thinking that MFA (or anything else) is a magic bullet, and that you can simply turn it on and never have to worry about security again is the biggest vulnerability of all.

      • Most security features are flawed in one way or another, nothing is perfect...
        Implementing MFA, especially if doing a good job of the implementation will generally improve your security and not weaken it in any way.

        The problem when people blindly follow and think something is perfect. Pretty much everything is flawed in some way, but so long as you understand the risks you can take steps to mitigate them.
        Thinking that MFA (or anything else) is a magic bullet, and that you can simply turn it on and never have to worry about security again is the biggest vulnerability of all.

        There are certainly a huge array of threats that secure authentication schemes don't address: Inside jobs, $5 wrenches, cracked systems...etc.

        Yet when it comes to Microsoft (and many others) you can be assured you never have to go that far to break into a system as authentication system is guaranteed to be designed in laughably insecure manner where the problems with the implementations are well known and well understood.

        The issue here isn't magic bullets it's basic competence.

    • Re: (Score:1)

      by ebvwfbw ( 864834 )

      You're right. Do away with MFA. Then all they have to do is get your password. No MFA required. Like it's the 1990s.

      Seriously, did you think this through? It's another step. A step that would keep the vast majority of people out. Now if you want to break in you also have to be good enough to steal a MFA token. Password is like the guard that lets you onto the property with a car pass. MFA is like another guard at the building entrance.

      • You're right. Do away with MFA. Then all they have to do is get your password. No MFA required. Like it's the 1990s.

        Seriously, did you think this through? It's another step. A step that would keep the vast majority of people out. Now if you want to break in you also have to be good enough to steal a MFA token. Password is like the guard that lets you onto the property with a car pass. MFA is like another guard at the building entrance.

        Did I actually say I didn't want security beyond password protection? Is that really what your powers of deduction concluded from what I wrote?
        I do want protection, it just clearly isn't MFA as it's can be compromised by people with limited skills.
        Auditors should be recommanding something that isn't just the current trendy fad and be at least able to propose something else as a secondary option.

        • Re: (Score:1)

          by ebvwfbw ( 864834 )

          You're right. Do away with MFA. Then all they have to do is get your password. No MFA required. Like it's the 1990s.

          Seriously, did you think this through? It's another step. A step that would keep the vast majority of people out. Now if you want to break in you also have to be good enough to steal a MFA token. Password is like the guard that lets you onto the property with a car pass. MFA is like another guard at the building entrance.

          Did I actually say I didn't want security beyond password protection? Is that really what your powers of deduction concluded from what I wrote?

          I do want protection, it just clearly isn't MFA as it's can be compromised by people with limited skills.

          Auditors should be recommanding something that isn't just the current trendy fad and be at least able to propose something else as a secondary option.

          I didn't misunderstand anything. Looking back - you started this out by saying you were arguing with auditors to not use MFA. You said you pointed out articles.. and so on. They insisted on using it as they have to. If you're not using MFA as you said you were arguing against, it doesn't take a Sherlock Holmes to figure out you're using just a password. So my deductive reasoning is very firmly based on what you said. That's why I asked - is that really what you want? Password only? I was hoping you had some

  • ...the password to another device.
  • I just enabled it for all of our IT staff. This news doesn't make me happy. However, it did put a stop to 99.9 of our security issues. Plus, we enabled Geo-regional checks. I guess we'll just have to harden it a bit. We hired a guy to just monitor our logins. This isn't a bad idea for most organizations with 1000+ users. Most users just can't be trained to stop blindly clicking random emails from weird places. We had a non-Staff user requesting Microsoft tech support to help the user to enable access to so

  • That's too complicated, there's a much easier way to breach MFA: simply keep trying to login. Eventually, your victim will either tap approve to make the annoying prompt go away, or will inadvertently approve your request while trying to approve their own legitimate one.

    • That is the reason why I never implement a 2FA that prompts the user on their phone.
      Yes typing over a code is more hassle, but at least you will be left alone at night when you are trying to sleep.

  • It's what I do everyday just to do my job...

  • The problem is not token theft it is the fact their defective by design authentication schemes are incapable of preventing verifier impersonation.

    When Microsoft started requiring MFA while concurrently "deprecating" secure certificate based solutions I said exactly this would happen.

  • Back in the 90s Microsoft recommended that, under no circumstances, should you store passwords or pre-authentication information in cookies. You would have to be unbelievably incompetent and reckless to write a web service to work that way since its reasonably trivial to steal the contents.

    Yet, here we are, and Microsoft as usual is able to demonstrate why it made those recommendations so many decades ago.
  • I don't know how it works, but I would have thought a token request from a device would be tied to that device, so only that device could successfully use the response. I guess not.

Slashdot Top Deals

An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.

Close