>"able to trick the Microsoft platform’s authentication"
So they social engineered the password, and if MFA was on it was push based MFA and the user just clicked OK to all popups on their phone?
So they social engineered the password, and if MFA was on it was push based MFA and the user just clicked OK to all popups on their phone?
Encryption: Yes.
Multi-factor authentication: Yes.
Do they care if the MFA is simply the user pecking at buttons like a bird trained with seeds: No.
There is a real problem with Azure AD MFA. Unlike the consumer MFA, it shows you exactly zero information about the source of the information. None. You get a choice of "approve" or "do not approve". You don't get any input information for making this decision.
Hacking this is trivial. If you know someone's password, you just have to occasionally try logging in. Eventually the user will accidentally click approve even though they didn't trigger the authentication.
You'd assume that nobody would ever fall for something like this, because surely nobody would be so stupid as to approve an MFA prompt they didn't trigger.
Meanwhile, my Microsoft Authenticator app triggers randomly about 5-10 times per day because every single MS app insists on "reauthenticating" me every 24 hours. So I'll be sitting at my desk and my phone will pop it up randomly. I'll look up, and sure enough, Teams wants me to re-MFA for some stupid reason.
I'm paranoid enough that I'll always reject these MFA prompts and then start the login cycle manually, but most people would just peck the button like a trained bird.
Similarly, I've run scripts before that needed 6 MFA prompts to complete (don't ask). I ran the script once and it asked 7 times... uh-oh. Is this an Azure bug, or a hacker from China? How could I possibly know?! The information is not provided to me!
This is Microsoft's fault, 110%, and I dare anyone here to argue otherwise.
So instead of reaching for the downvote button, make your case on how "yes, yes, yes, yes" is not a security disaster below in the comments please.
Your actions may make it some If these things happen as well. I can think of a few organizations where your script would have resulted in your account being locked down and a security incident.
That said, I'm sure there's a reasonable level somewhere in the middle. The current situation certainly doesn't sound like it, although I haven't used any form of Microsoft MFA, so I can't really say either way.
Just about every business will have options that are a perfectly reasonable choice in some circumstances and really, really stupid in others.
Microsoft has billions of users. The security needs of the US Department of Justice are not the same as my mom’s real estate office.
When you use 3rd party IdP, for example, how does Azure MFA know what the app is?
The configuration described was not out of the can. Somebody decided to make it the way it was.
Most likely due to some physical (not legal) issue that would make it mechanically unsafe to operate the vehicle above that speed even in an otherwise appropriate location. (Or perhaps it's due to some obscure state law, or the manufacturer is just out to spoil your fun, or ... who knows?)
More generally, I agree with the point you make here about the responsibility to configure things correctly. However, it seems to me that Microsoft is also on the hook for failing to include the necessary context when an MFA request is sent. It's a bit like selling a car with seat belts that superficially appear to work but fail at the slightest provocation, no?
It is is on by default however when using the same mobile app for Hotmail or XBox live accounts.
Microsoft thinks the data of Fortune 500 companies is less valuable than your Minecraft skins.
Notably, Microsoft's consumer MFA, the type used to protect Hotmail and XBox accounts shows more information in the exact same mobile app!
It's not that they don't have the capability, or don't know that it's important. Microsoft has explicitly chosen to never ever show additional information of any type for enterprise customers only.
They care about the security of their own things, not you stuff, in other words.
> All of the organizations were breached through a network management system called Solar Winds, according to three people familiar with the matter, who spoke on condition of anonymity because of the issue’s sensitivity.
https://www.washingtonpost.com/national-security/russian-gov...
>SolarWinds N-central before 12.1 SP1 HF5 and 12.2 before SP1 HF2 allows remote attackers to retrieve cleartext domain admin credentials from the Agent & Probe settings, and obtain other sensitive information
I personally found and reported the unpublished CVE-2019-10690 in N-Central, but that was only local privesc.
> They gained access to victims via trojanized updates to SolarWind’s Orion IT monitoring and management software. This campaign may have begun as early as Spring 2020 and is currently ongoing. Post compromise activity following this supply chain compromise has included lateral movement and data theft. The campaign is the work of a highly skilled actor and the operation was conducted with significant operational security.
I'm just glad I'm not the only one who sees this as a problem.
If they offload auth to a on-prem or third party IdP (common in big hybrid O365 tenants), there are often different paths, implementation screwups or bugs that let you bypass MFA. Microsoft’s position is “buy Azure AD, Buy M365, Buy ATP” and other paths are poorly tested, or they explicitly tell you to F off.
Also remember that federal agencies are bigger than most fortune 50 companies, are usually global in scope and have lots of collaborations with other agencies and other third parties, and may have independent pockets within the agency. Those friction points are where problems tend to happen!