[HN Gopher] In major gaffe, hacked Microsoft test account was as...
___________________________________________________________________
In major gaffe, hacked Microsoft test account was assigned admin
privileges
Author : taimurkazmi
Score : 114 points
Date : 2024-01-27 17:50 UTC (5 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| taimurkazmi wrote:
| This is what is commonly known in the cybersecurity industry as a
| "whoopsie"
| orionblastar wrote:
| 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.
| ratg13 wrote:
| Rather curious now to know how many global admins Microsoft has.
| cratermoon wrote:
| 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.
| makeitdouble wrote:
| TBF given the amount of rights needed to be managed for each
| employee for all their accounts accross the services, it feels
| like the natural progression of things.
|
| Basically, we're experiencing the Windows XP security popup
| equivalent but at a service level, where at every step of a
| task you're asked to identify to something else and the back
| and forth to get the proper credentials with the proper rights
| can take days.
|
| Support teams calling it fucks and throwing half the accounts
| and permission bucket at any newcomer is just humane.
| wepple wrote:
| This pattern is the rule rather than the exception across MS
| ecosystems, but to see Microsoft itself do it is particularly
| egg-on-face.
|
| MS security has put significant effort into tooling and best
| practice documentation to try and prevent these types of major
| screw-ups
| ics wrote:
| Yeah this shit happens all over the place. I've worked for/with
| numerous people whose method of testing almost always involves
| giving maximum latitude for idk... shotgun debugging? The
| bigger problem is that people just forget, they've made five
| test accounts with admin privileges and it isn't known until
| (hopefully) someone does an audit of user privileges across the
| entire company.
| wolverine876 wrote:
| > 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."
|
| 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.
|
| 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.
| skywhopper wrote:
| How do you suggest they make config errors "impossible"?
| wolverine876 wrote:
| Don't make it a configuration option, restrict the option to
| only very specific conditions, require multiple approvals and
| verifications, limit the duration of the configuration (e.g.,
| it disables after 7 days unless reset), audit it, etc etc.
| citizenpaul wrote:
| I doubt the problem is technical. There probably were 20 best
| practices and safeguards in place to prevent it technically.
| The problem is guardrails and best practices only matter if
| they are cared about by the
| organization/leadership/bureaucracy. I've been told to give
| super admin/root rights to VIPs that had no business with such
| things many times over the years even though it overrode all
| policy/procedure/regulation/law.
|
| Its also compounded by every job is a
|
| cross-cross-cross-parttimecross-cross-dualrole-trirole job
| these days.
|
| I've seen role based controls that had more roles than actual
| permissions that were possible to grant so the entire point of
| the RBAC was self defeating. It was actually less time to
| simply grant permissions individually but of course that meant
| the reports would not show roles so it was not allowed.
|
| That doesn't come from the tech people that comes from poor
| leadership.
|
| On a side note I once designed an add on to a RBAC permission
| system to overcome this problem for an in house ERP. We had a
| permission type called "Permission Exception" If someone needed
| a permission outside of their role they got it assigned this
| way so a report could be generated that showed everyone that
| could do things outside of a job role. I've never seen it
| anywhere else. All it did was add a flag to the permission but
| it worked. HR would check the permission exceptions every
| quarter and see what needed removed from people. It kept the
| permissions in check by actual knowledgeable authority rather
| than some part time help desk position trying to cluelessly
| trial error untangle permissions.
| wolverine876 wrote:
| Yes, that's what I was saying, though it could be technical
| management. Whoever configured it that way may have been put
| in a position to fail.
|
| > I've been told to give super admin rights to VIPs that had
| no business with such things many times over the years even
| though it overrode all
|
| One can establish the power to say 'no', at least in many
| places. The systems are your work domain (depending on your
| job title); you can make clear that outsiders are not
| permitted inside.
|
| An essential is to establish credibility: 'Leave it to me -
| stay off my turf - and it will get done.' When they say the
| VIP needs something, find out what they really need and
| deliver that with amazing promptness and reliability (i.e.,
| no saying later, 'oh, I didn't think of that!'). Everyone
| will be happy and impressed.
|
| It also gives the impression that what you say is serious -
| you really mean that these security issues are serious. If
| you go along with the request, you convey that it's just
| talk.
|
| Easily said in a comment, much harder to do of course. But
| remember that if you follow their instructions, and stuff
| goes wrong, it's your fault - your name is on the systems;
| the failures and successes are your reputation; and also you
| were supposed to advise them ...
| Arainach wrote:
| Missing in this post: how do the authors define "production" if a
| "non-production" account has admin rights to the prod domain?
| hn_throwaway_99 wrote:
| Yes, I think this is key. This blog post and the quotes in the
| article are calling this a "gaffe", but in an organization the
| size and complexity of Microsoft, I'd say that mistaken
| permissions assignments are _inevitable_. So I don 't think
| it's really helpful to focus on the "someone in a 220k person
| company made a mistake at some point" angle.
|
| However, at most companies there is usually a hard thick line
| between production and test systems. Granting production access
| to a test account should be basically impossible, so how _that_
| happened should be what the investigation should focus on.
| HenryBemis wrote:
| On top of that, when one (person/company) sets up a test
| account they should (at the creation/activation) set the
| deletion/deactivation date. So even if the admin is hit by a
| bus, that damn account will go off on DDMMYYYY and not "live
| long enough to become the villain".
|
| Also, TERRIBLE/HORRIBLE user access management and review.
| How do they let a test account be live for "months"? Don't
| they have some alerts for all test accounts in PROD
| environment to pester them daily??
|
| (I keep ranting about the need of a strong and capable
| internal IT audit.. this is an alert that your IT audit
| SHOULD have set up for their Continuous Audit processes)
| cedws wrote:
| Well said. A test account having admin privileges over a non-
| prod system is not the real problem. Poor isolation between
| prod and non-prod is.
| chc4 wrote:
| 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.
| nimbius wrote:
| 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...
|
| Its almost like security is some sort of ribbon campaign.
| pottertheotter wrote:
| What book?
| nimbius wrote:
| Cissp, csslp, issap, issep,heck even a dog eared copy of the
| security+ would have helped...
| Voultapher wrote:
| Security is a process and not a product.
|
| Anyone selling you security as a product is scamming you.
| coldcode wrote:
| 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.
| jcmeyrignac wrote:
| Why is this considered a "gaffe"? It may be the act of a mole who
| works at Microsoft as an admin.
| rvba wrote:
| KGB captured a NSA account?
|
| Access to everything means it was not a planned disclosure.
|
| 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...
| SebFender wrote:
| "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"
|
| We're in the presence of a genius.
| peteradio wrote:
| Indians believe in many gods while Christians believe in one of
| three depending on context.
___________________________________________________________________
(page generated 2024-01-27 23:00 UTC)