Reminds me of an ancient Roblox hack I heard about, where they had a non-production staging version of the website that users could sign up for (with accompanied "nothing here is permanent" banner). A new administrator user account was added to production, and someone was able to register the same staging site username and use it's cookies and tokens in order to hijack the production account and compromise the site. I can't imagine these types of problems are that uncommon: if you generate cryptographic tokens based off username or user ID that doesn't have a different secret for production/staging, if your staging site talks to other external services that mix up permission grants for production, etc.
The dev/production boundary in large companies is much more porous than people like to think. Consider a typical day: you log in to your pc, check email, then use the same creds to log in to your azure portal (after all, all backed by the same tenant). Your account is linked to github and your cloud account.<p>Groups and teams get created all over the place, with mysterious permissions, just so that you can play in Teams, or OneDrive, and these persist in the company directory almost indistinguishable from security groups.<p>Sometimes you get automated emails asking you if you still need something, but the messages are opaque, and in a really big company there's no-one you can really ask (helpdesk takes 2 days to get back to you, and what are you gonna do, hit up John Savill on Twitter?), so you hit ok and try to carry on.<p>Inevitably, the fabric starts to rend, and an attacker gets lucky at a weak spot and can jump sideways through the tenant to get what they want.<p>As a wise CISO once said, hackers dont break in, they log in.
> Kevin Beaumont—a researcher and security professional with decades of experience, including a stint working for Microsoft—pointed out on Mastodon that the only way for an account to assign the all-powerful full_access_as_app role to an OAuth app is for the account to have administrator privileges. “Somebody,” he said, “made a pretty big config error in production.”<p>Without knowing details of the system: That would not seem to be the problem, and I'm surprised someone with expertise would say it is. There should be no way for someone to make that error. Whoever designed it and whoever administers it should have made it impossible; they would be responsible.<p>If you build and operate a factory with a button that electrocutes everyone inside, and someone mistakenly presses that button, it's clear where the problem is.
I like how we have all these cool security certifications that can quantifiably protect companies and industries from calculable risk and yet somehow the well reasoned and thoughtful best practice of a $36 book on amazon goes totally ignored...<p>Its almost like security is some sort of ribbon campaign.
This is why I hate when I go to a new gig and someone just assigns me a bunch of rights, "because it's easier". No, don't do that. Not only are you exposing your company to breaches, you're giving me responsibilities I don't want. I could make a mistake and screw something important up, or something could get hacked and people might think it was me, because I have privileges to do it.
I got one better, worked at a law firm, managers and partners were given admin access to everything. Default password after reset is "passme" because password was too long to remember. They are supposed to reset their password after login into the server. Hackers got a few of their accounts and started messing with things and stealing data. Even some test accounts had admin status. I'm glad I don't work there anymore, I was a programmer analyst and only had admin access to my PC to make Visual BASIC 6.0 work.
This pattern is the rule rather than the exception across MS ecosystems, but to see Microsoft itself do it is particularly egg-on-face.<p>MS security has put significant effort into tooling and best practice documentation to try and prevent these types of major screw-ups
I once worked for a company that stored all of its passwords for production servers and databases in a text file in the code repository, all because the chief architect didn't want to have to remember any passwords. Pointing out how stupid that was to the CTO, got me a statement "we trust our employees" and "we passed our security audit". My face is still hurting from the facepalm.
KGB captured a NSA account?<p>Access to everything means it was not a planned disclosure.<p>Also why does MS not design its systems to simply disallow one person to have such priviledges? They are attacked by state actors and have moles inside...
Now Russia is probably extorting Microsoft with all the dirt they uncovered. I hope at least they will make the information public after they're done.