Oasis Security Research Team Discovers Microsoft Azure MFA Bypass
oasis.security
oasis.security
This could have gone unnoticed for years as so many cloud provider gaffes do. It's unlikely that anyone would think "Hey let's try brute forcing the login today". This violates trust-but-verify. You accept their say-so and so you're fully delegating trust. And because you're paying thousands of bucks for a service you assume it must be good. That's the very model of a (con)fidence trick. You don't even know you bought a lemon until its too late.
There's no substitute for having someone qualified and educated in cybersecurity with that as their full-time job - and better yet bring your critical assets back on-prem with some kind of hybrid setup. Big cloud is really eating at the McDonalds of cybsersecurity.
I would rather trust a company with x persons working on security than one person.
Yes Big Company Microsoft got this one wrong (and also some other), but how many did they right? It’s always easy to be mad at failure if we overlook the times where something was done right.
No. Perhaps counter-intuitively the "problem" isn't trust here.
What I'm raising above is not the necessity to trust but the extent to which verification is possible or frustrated. For example, with open versus proprietary code you may or may not have the capacity to audit it, but you always have the possibility.
> I would rather trust a company with x persons
Trustworthiness does not scale in this way. Though the "many eyes" theory has some weight, we also say "two people can keep a secret if one of them is dead." Assigning more cooks to the broth yields rapidly diminishing returns for reasons Fred Brooks explains [0].
But that is not my strongest objection. A more serious reason not to trust a BigTech company with your security is the "principal agent problem" [1]. As Ross Anderson puts it; "If Alice guards a system and Bob pays the cost of failure, you can expect trouble!" [2]. Microsoft does not "pay the price".
Worse, Google (and Meta, Linked-In etc) base their business model on your insecurity - they are primarily in the business of acquiring data about you to use in selling your person to advertisers. They are therefore motivated, however weakly, against your actual security. It's a scandal that such companies also act as data processors and suppliers of services like online storage.
So while you can outsource trust, you cannot unload responsibility to verify. A solution is education based on a credo of "principles not products" [4].
[0] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
[1] https://en.wikipedia.org/wiki/Principal-agent_problem
[2] https://www.csail.mit.edu/news/dertouzos-distinguished-lectu...
[3] https://techrights.org/n/2024/09/25/Technology_rights_or_res...
I think that Microsoft is getting away easy here with Oasis publishing the vulnerability report. If Microsoft published the report it would be incumbent upon them to include information about what they did to discover whether this happened before Oasis reported the problem.
One wonders how many Azure accounts might have been compromised and are even now allowing data to be exfiltrated.
Of course, the vault where those accounts are stored is a complete enterprise product with associated usability so what ends up happening is that people copy their passwords to an Excel sheet, or worse to Windows sticky notes, which often get up getting screen-shared in Teams calls.
A security company should know this. It's been strictly recommended against in the NIST guidelines (and others) for nearing a decade now. I start to really question the expertise of any security company that parrots this outdated advice. What else are they not keeping up on?
Focus on monitoring, alerting, educating, etc. Force password changes only when there are indicators of compromise.
Why would you avoid TOTP altogether? Yes, SMS OTP is insecure because SMS is insecure, but OTP itself is fine, unless I missed something?
With passkeys if someone gets remote control of your computer they have access to everything you setup a passkey for.
Typically people say “well full remote control is far less common than phishing”, and it is, for now, until everyone’s using passkeys and all of the sophisticated phishing attack effort just shifts to passkeys.
The obvious weak point here is all of the outsourced IT who aren’t specifically focused on cybersecurity. Every IT company is using multiple tools for central management that either allows remote control or remote execution, or there’s always in-house developers who realistically aren’t doing a security analysis of every third-party library they’re installing.
And yet it is still the recommended practice for every IT department for pretty much all corps. Even AWS has their forced 90 password reset policy where you start to get reminders 15 days early so it's actually 75 days. Only at AWS, they don't force you into the password rotation flow at the end of the 90, they automatically lock the account. While that might make sense for inactive accounts, for accounts that have clicked the Not Now for 14 days should be taken to a change password screen instead. /rant
Not any that I or my colleagues consult at.
>or was there another point to your comment?
The purpose of my comment was to refute your claim that arbitrary password resets is the "recommended practice for every IT department for pretty much all corps".
Because it's not true.
>Great there's at least 3 companies that do not have this policy.
Between me and my colleagues we consult at dozens to hundreds of corporations per year. "At least 3" is pretty disingenuous.
do you honestly believe that i was unaware that there are companies that do not require the rotation policy? maybe the "pretty much all" phrase was confusing and you did not think that left room for some to not?
that's great that there are some companies that do not, but there are a great number of people that still do. it's not anything that needs rebutting as we're all aware they exist
~90% or more of the companies we consult with do not have forced arbitrary password rotations when we start our engagement with them (~100% do not have it by the end of the engagement). We engage with dozens to hundreds of companies a year.
Does your definition of "pretty much all" actually mean "a small portion"? No wonder I was confused...
Where are you getting your numbers from? What data are you reviewing?
Sounds like your doing the lord's work. Godspeed
That is not what I said. In fact, that's the complete opposite of what I said! Here, I'll add some emphasis for you.
>"~90% or more of the companies we consult with do not have forced arbitrary password rotations ___when we start our engagement with them___"
This is a policy set by the organization. You can easily change it to longer in IAM (or disable it entirely).
Another AWS set of creds is SSO+2FA, and no longer has the rotating policy. It's like a breath of fresh air.
Turns out, just like TFA, several security audits I've been through all list the password rotation policy in them.
With no need to memorize passwords, you can change them as often as you fancy.
This is all that matters, regardless of whether a password manager is used or not.
Users should be able to change their own password (almost) whenever they want.
But arbitrary forced password changes from the admin should not happen unless the account has indicators of being compromised (even if all of your users have a password manager).
Every few months we need to change our password. It cannot be a previously used password. It needs uppercase, lowercase, number, special character and minimum 12 characters. We have 2FA that is easily bypassed by going offline then back online once through login. We have 4 different active security suites running on our machines, and mandatory biweekly virus scans, at 10am (which cannot be changed). Every standard 16GB machine runs on it's knees all day long. But at least you can skip 2fa by turning off wifi real fast.
Chances are your company ultimately exists to optimize for shareholder value
My actual password choices are secure, memorable, and available even if I lose my phone or password manager. The counter is just an annoyance.
I can't because there is generally a limit to how many passwords it checks for previous use. So you can usually just start back at "1" for the increment after you hit "0".
Hopefully that is not the case now though, and I am surprised the advice has persisted... (though outdated gov standards probably played a part until recently)
Not much to say about this article except that it's one more in a long trend of security startups hyping bugs to attract business.
I'm not loving how they claim it's MFA bypass when it's really brute force, though I wouldn't necessarily minimize the attack overall either, I'm more curious how widespread these kinds of timeout bugs might be in other places.