Critical cross-account vulnerability in Microsoft Azure automation service | Hacker News Reader

Critical cross-account vulnerability in Microsoft Azure automation service

orca.security

216 pointsarkadiyt41 comments

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.

The real mockery is it shows you exactly how much the independent certifications they have mean which everyone uses as due diligence check boxing.

The certs check for process issues such-as not updating your OS. They don't check for poor design.

SOC2, which is by far the most common compliance certification, checks for:

1. The presence of a formal threat model

2. A process for applying controls against that threat model

3. Evidence that the process is being followed (for a type 2)

This is actually pretty good. It's just also easy to game. It's totally on you to say what your threat model is, to say what controls you've accounted for, what risks you've accepted, etc. An auditor might call you out like "no, encrypting data at rest doesn't address password reuse", but you have a lot of control over how the whole thing plays out.

That means that most companies basically just buy their way out of SOC2 by having a compliance team that retroactively works to map what currently exists to a standard threat model provided by NIST. What happens less often is that people actually do the work the intended way - starting with a model, creating a process, and then creating an audit trail for it.

If they did, honestly, SOC2 would have a lot of value. It is a very sound approach to security. But, as with all cost centers, the goal is to minimize the cost of security, not to do it well.

This is an excellent explanation of the process. Like a lot of people, I was pretty surprised at how the certification works when I first learned about it. It's way more about checking that you have a process than it is checking that the process is sound.

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.

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.

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.

AWS is pretty huge too - thw list ofnaervices doesnt fit on my screen!and half of them are half baked!

Just like all other cloud vendors, unless we are speaking about mini cloud offerings.

sorry how do you mean with outlook? is there really a way to remove the "modern" design and unveil the 90s beauty beneath?

Not the OC, so not sure exactly what they meant, but if you go into File/Options it would recognizable to anyone from 20 years ago. But I would say the same thing about the equiv. screen in Photoshop. There's continuity in applications that have been around for decades, and that's not necessarily a bad thing.

The number one screen where you're exposed to it is in the filter configuration screen.

Sadly, there is nothing resembling beauty in that screen. It's a multi-page wizard that attempts to guide you through what should be a simple filter commandline to a frustrating exercise in in trying to convince the tool that yes, I do want to filter on an email address that is not in my address book.

It's from the era when the Internet just started becoming popular, and having hyperlinks instead of buttons was being introduced for no good reason at all.

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.

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"

The point of the cloud was never that it’s got stronger security. Even in the early days people were constantly leaking data due to insecure S3 buckets.

Nonetheless, people repeatedly claim that using cloud vendors' high-level services is more secure than running your own stuff.

And in some instances that’s a valid claim. The problem here is you’re taking two massive generalisations and assuming they’re always mutually inclusive.

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"

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...

> 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,

I’d say your assumptions are wrong there. Security is not one of the main reasons for moving to the cloud. It’s not even _a_ reason to. Delegating responsibility for security might be cited as a reason but that’s not the same as saying the cloud is “more” secure. That’s just saying you are you don’t want to pay for security yourselves. Which is a whole different thing to what you’re claiming.

This is patently false. Security is repeatedly cited as a reason to move to the cloud, including in cloud vendors' own marketing materials.

You’re conflating sales pitches with actual business decisions that management make. I’ve been on the decision making board for a few companies and the pragmatic reality is the only time people cite security as the reason for moving to the cloud is when:

1. They’ve lost all their sysadmins / security staff and thus need to outsource that governance

2. When they’re looking to delegating responsibility (ie say to the customers “it’s an Azure issue, they’re fixing it”).

In both instances it’s not about Azure / AWS / GCP being more secure, it’s about _WHO_ owns the responsibility for securing.

The difference is important.

More often the actual reasons for migrating to the cloud are cited as cost saving (which is often misunderstood too but that’s another topic) and quicker deployment times (this is probably the strongest valid argument in my opinion)

Point taken.

> Azure has more certifications than any other cloud provider.

This is so... wrong. Makes me shudder. It's a bit like saying "I have so many credit cards, I must be really rich!".

$40,000 is an incredibly low amount this type of severity finding.

Is no one doing security QA there? This seems to me like someone thought "the isolation is going to be enforced by networking" and then no one validated it by just running nmap or something.

Finding this should have been trivial for MS. And further, why would you only have one mechanism for tenancy enforcement? Networking is a fine boundary, but there should have been a token as well.

> And further, why would you only have one mechanism for tenancy enforcement? Networking is a fine boundary, but there should have been a token as well.

Honestly, this bug, and this comment on the recent ChaosDB bug, https://news.ycombinator.com/item?id=29296170, make me think that Azure just doesn't know how to do tenant segregation securely. These types of bugs where some small flaw allow complete takeover of other accounts (or worse, complete takeover of the whole service) are pretty catastrophic.

Yeh, MS seems to be like every other large corp in this case. Too big to handle for one security team. So you end up with, some parts of it that got security down; but all those < V3 services? they seem to be written by 3rd world contractors who code-review via stackoverflow

There is no QA of any kind, other then customers complaining.

Totally broken features are regularly shipped and stay broken.

A random example: Application Gateway shows 5 metrics if you open one in the Portal on the first page. Two of those metrics aggregate a rate (Mbps) using sum instead of avg.

40% of their front-and-center graphs show gibberish, and that’s been like that for probably years.

No one tested any of this. Not a security person, not a UX person, or any manager.

PS: Take a look at the cypher suites offered by App Gateway and its and TLS defaults. Note the current year. Now consider that this is their security product with Web Application Firewall functionality!

Would you trust their WAF to keep you safe? Or just tick a checkbox that some auditor says needs ticking?

I’m surprised a feature like this didn’t require a detailed threat model with explanation of mitigations before launch. Don’t think this “authentication” method would’ve past muster

Me too. We have a multi-tenant system and we did threat modeling, immediately calling out that while we had network restrictions that we should assume those will fail and we'll add mTLS and an out of band token.

That took almost no time or effort to realize.

This is right after the ChaosDB disclosure in August. What is going on over at Azure?

You skipped over Omigod which was right after ChaosDB. https://www.wiz.io/blog/omigod-critical-vulnerabilities-in-o...

Even worse.

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

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.

Need the keys to the castle? Just ask!

Didn't Azure have another massive security vulnerability just a few months ago?

Great find, but I must say that I find the author of the post highlighting a quote from himself to be a bit jarring.

JFC this industry needs to get its secops act together. This is the #2 cloud provider in the world.

Reply on news.ycombinator.com