[HN Gopher] Critical cross-account vulnerability in Microsoft Az...
___________________________________________________________________
Critical cross-account vulnerability in Microsoft Azure automation
service
Author : arkadiyt
Score : 136 points
Date : 2022-03-07 16:34 UTC (6 hours ago)
(HTM) web link (orca.security)
(TXT) w3m dump (orca.security)
| theknocker wrote:
| HL33tibCe7 wrote:
| This seems like a fairly glaring oversight that really shouldn't
| have happened.
|
| Between this and
| https://www.rapid7.com/blog/post/2021/09/15/omigod-how-to-au...,
| I'm starting to lose faith in the security of Azure.
| delusional wrote:
| I'm worried Azure is getting too large to handle. It's like
| outlook, where 3 clicks and lead you into the old UI from the
| 90s. Microsoft seems addicted to breadth of features instead of
| quality of implementation.
| wronglebowski wrote:
| Where I work recently disclosed another vulnerability in a
| similar vein.
|
| https://sra.io/blog/letitgo-a-case-study-in-expired-domains-...
|
| Spooky stuff for sure.
| syshum wrote:
| I have been told a number of times I should give up on OnPrem
| because I could never afford to match the security of the
| cloud.....
|
| The more the cloud is exposed as "just someone else's computer"
| the easier it is to push back the often false narrative of "too
| big to be insecure"
| Godel_unicode wrote:
| Before you freak out too much, this bug has been closed. See
| below from the finders Twitter feed. Before you relax too much,
| this was horrifying and you should seriously consider rolling
| managed identities as well as auditing their usage in your
| tenants.
|
| "The issue was found and reported all in the same day. Microsoft
| fixed it within 4 days, classified it with critical severity and
| awarded a $40,000 #BugBounty"
| Veserv wrote:
| One of the top cloud companies who everybody assumes are
| supposed to have security and security experts beyond what you
| can deploy, which is one of the main reasons given for why you
| should move to cloud deployment, sold a critical administration
| service implying it had high security [1] to unsuspecting
| customers. Where as, in reality, it took a single researcher
| who had _never heard of the product before_ and who is
| unfamiliar with the tech stack used in its creation _less than
| one day_ to completely compromise it. By the internationally
| recognized Common Criteria standard [2], this would constitute
| a attack far below even Basic, the lowest certifiable level.
|
| This has happened time and time again to the point where their
| repeatable security design, process, and validation is
| demonstrably systemically incapable of rejecting even grossly
| insecure systems. The benefit of the doubt for the quality of
| their systems should not be extended to a process that
| consistently produces abject failures. To assume anything other
| than the level of quality they produce regularly is an
| extraordinary claim that requires extraordinary evidence and
| independent objective verification. So actually, yes, you
| should freak out if you rely on the security of Azure (or any
| other cloud for that matter) without independently verifying
| the quality of _every single service_ you use since their
| pattern of grossly incompetent security process means you
| should default to assuming their systems are terrible.
|
| [1] https://azure.microsoft.com/en-
| us/services/automation/#secur...
|
| [2]
| https://www.commoncriteriaportal.org/files/ccfiles/CEMV3.1R5...
| belter wrote:
| $40,000 is an incredibly low amount this type of severity
| finding.
| orf wrote:
| Great find, but I must say that I find the author of the post
| highlighting a quote from himself to be a bit jarring.
| sylens wrote:
| This is right after the ChaosDB disclosure in August. What is
| going on over at Azure?
| randomfool wrote:
| You skipped over Omigod which was right after ChaosDB.
| https://www.wiz.io/blog/omigod-critical-vulnerabilities-in-o...
| sylens wrote:
| Even worse.
| semicolon_storm wrote:
| As someone who works for a company that heavily utilizes Azure:
|
| 1. Try to hard to get security to be "it just works" feature
|
| 2. Too much handwavy "it's secure because we're in the cloud
| and say it's secure" logic going on
| upbeat_general wrote:
| This is pretty horrifying. I've worked on a project that did
| something similar with having services created on random ports
| but not only was this not a public service, it was removed from
| the design before deployment. I can't imagine deploying something
| like this for a _public_ cloud service that manages account
| actions with user-generated code.
|
| Security flaws happen but as someone who's not a security
| professional, this seems pretty inexcusable to me.
| hughrr wrote:
| The real mockery is it shows you exactly how much the
| independent certifications they have mean which everyone uses
| as due diligence check boxing.
| bushbaba wrote:
| The certs check for process issues such-as not updating your
| OS. They don't check for poor design.
| acdha wrote:
| That's the point: too people look at those certifications
| and see them as an end point rather than the floor of what
| anyone running a computer should do.
| [deleted]
| tempnow987 wrote:
| tldr: Microsoft provides a web service that returns user
| authentication tokens based on port of the request for users
| using the service without the user having to validate their
| identity!
|
| The default values of the service include Managed Identity being
| set to ON.
|
| This default means you don't have to provide or rotate any
| secrets and the service (which you can get a token to without
| authenticating) has access to all resources that can be
| authenticated with Active Directory. So full compromise at root
| level through a GET request to an endpoint with no
| authentication.
|
| Do I have this right? Wow.
| yourself92 wrote:
| Need the keys to the castle? Just ask!
| intunderflow wrote:
| Didn't Azure have another massive security vulnerability just a
| few months ago?
___________________________________________________________________
(page generated 2022-03-07 23:00 UTC)