And when you're talking about "most secret" contracts, those are all classified systems, which are on totally separate networks in totally separate private data centers located on military installations. Unless you've figured out how to break strong symmetric encryption using hardware-generated, hardware-loaded, pre-shared keys controlled in military arms rooms, that means you need physical access. It doesn't necessarily mean you need to break into a military installation. You can always try to break into a contractor SCIF instead, but that still isn't all that easy. My wife once saw some AT&T contractors digging too close to the wrong fiber line at her facility when she was working for the Navy at a contractor site and unmarked black SUVs were there to take those guys away to God knows where within two minutes.

That said, I don't doubt people try. When I was at Raytheon working at a secure facility, a Chinese company bought the property across the street, built a hotel at exactly the same height with windows facing us, and it was conspicuously almost always empty. I don't think demand for hotel rooms was financing that place.

I used to do design/permitting for fiber networks and going around DOD areas/Fiber was always fun. You wind up having to submit your routes, and get vague feedback as to what you need to move, but never how far away/etc. Usually your best bet is to just go to the other side of the road if possible.

This bug only seems to widen that vulnerability slightly, to those groups plus those with knowledge of this bug.

Nothing in major US cloud providers can reasonably be expected to remain private, so I think this breathless headline is a little overblown.

You cannot imagine any other party it would be worse to be vulnerable to?

I'd expand that to "Nothing in third-party cloud providers can reasonably be expected to remain private". If you don't have ultimate oversight of how the host of your data is managed, anything could be going on there, regardless what nationality of company is managing it or what promises their salespeople make.

Unless you have some secret kung-fu that makes your on-prem infrastructure hack-proof.

The issue with the cloud is scale.

I’d argue the issue with cloud is less about scale, more about how easy it is to get started. My mother could quite easily click through the account creation on a cloud provider and setup something insecure, but not a chance is she going to get a DC built with equipment racked or even a basic setup at a colo facility.

Disappointing to see that it's arstechnica.

https://docs.microsoft.com/en-us/azure/cosmos-db/secure-acce...

By that logic should there be legal consequences for a company if someone breaks into their office and steals paper records?

Comparing cloud storage and paper records is worse than comparing apples to oranges; it's comparing apples to celery. Sure they're both edible but they are vastly different organisms.

And yes, there can be legal consequences for a company if someone breaks into their office and steals paper records.

I think when people talk about consequences, they’re not regarding these companies as victims of crimes, rather as negligent actors.

That computers are involved should not remove negligence as a possibility to recover damages.

I bet Microsoft would claim damages of $1+ billion if someone used that type of exploit maliciously by damaging data and undermining customer confidence in Azure.

What a joke. This should pay $1+ million.

1. Small time cheap skate business owners sometimes try to cheat professional artists by "paying with exposure", when they have no meaningful audience or influence and therefore no meaningful exposure to give.

2. Sources that do genuinely have very large audiences and influence can infact give an artist so much exposure that it's worth far more than any reasonable direct payment

This situation seems a lot more like 2 than 1. The company is in the business of helping companies secure their cloud environments, and these articles going around the tech press are being read by hundreds of thousands of people who are generally more interested in cloud security than a random person. They could spend many times the amounts discussed here on advertising and still not get their name in front of that many of the right people in a good context.

edit: and what about it had been a smaller company or individual researcher who wouldn't be able to gain as much from this publicity? Are you saying that Microsoft would have awarded them $ 500k? Because that's not the message sent with this reward. And frankly, even this discussion is kind of off-the-point because I doubt that's what they took into account when defining the money quantity.

PR campaign or not, you don't spit on those kinds of rewards. And it's a bad look on MS to award 40k on one of the worst vulnerabilities to ever hit a cloud provider...

1. Disclose to Microsoft for $40k

2. Disclose to an intelligence agency for several times that

3. Disclose to criminals for several times that, in turn

The incentives are now publicly known to be misaligned, and as a potential Azure customer, I have to contend with the simple reality that a significant number of vulnerabilities will be exploited rather than reported.

$40k doesn't even come close to covering engineer time here. This should be a $1M payout.

The reality is that if an organization is using a managed database and doesn't have service-provider vulnerabilities as part of their threat model, they are naive and arguably negligent.

Knowledge required to find stuff like that is very scarse. And you have to know where to look for.

Chances to find something really big are so small that its not worth it to look for them finnancially.

Thats why ppl don’t do that often. They do it if they have long cooperation history with given company because they are treated as an employee.

TL;DR is that you don’t want to encourage ppl to start looking. All software has bugs, so its only a matter of time until someone finds something.

The company you work for, once they track the code back to you, will investigate you to make sure you did not make profit on it.

Once you reach a certain bar, people do the right thing.

$40k isn't enough to cover the cost of research+reporting at livable salaries, let along overhead, fake starts, etc.

1) Microsoft could afford $10M

2) I think people would be honest well short of $10M

3) The cost to customers, if this went public, would be far more than $10M.

You want people to be able to make an honest living on security research, or otherwise, the only people looking for vulnerabilities, aside from the independently wealthy hobbyists, will be crooks.

But you are right. They should pay them more.

That seems overly paranoid.

Over the past few years the number of security fiascos has been increasing. Is the internal Security team (forget what the org was called) dead now ?

I'm sure lack of dedicated testing is also a major factor, but do launches no longer have to satisfy a security review ? Maybe in the name of agile development ?

I wouldn’t be surprised if they started embracing the “ship fast” mentality with the cloud a bit more over the past years, in order to corner the market more quickly (which they did).

Additionally, I can also imagine that the release processes for cloud are fundamentally different than something like an OS. With the cloud, there’s a much larger mentality of releasing often, and it may be difficult to translate rigorous security audits to this workflow.

Cosmos DB probably went through security review during the design phase and then again regularly as the code was written and improved. The Jupyter notebook functionality was also likely reviewed by security teams during the design, testing, and implementation phases. But once you're through those approvals most security review is going to be done via automated tooling with only occasional re-reviews and penetration testing at scheduled intervals. Automated testing is great at detecting vulnerabilities that have been discovered in the past, but really not good at detecting new classes of vulnerabilities, hard-to-detect authorization vulnerabilities, or how code integrates with other services.

Once the initial approval and code reviews had been done developers would still be committing code to the service and each line of code is probably not receiving a manual code review. Vulnerabilities like this are hard to detect even with a manual review as the testing team may not have great knowledge of all interconnected services, especially if it's an outside vendor.

You could literally not ship anything without this review, so they must have abandoned the process by now. Or just never extended it to "the cloud"

https://www.flexi-news.com/the-8-most-important-execs-who-le...

I don't believe private keys were in use here, instead I expect these are secrets and the thing about secrets is, as Bono sang, "A secret is something you tell one other person" which means now there's another party that can lose it.

This is a reason to avoid using shared secret schemes and instead prefer private keys, because if access to Cosmos DB required a private key you as the only one with the key know if you gave that to Jupyter, if you didn't then it can't very well have given copies to anybody else. Unfortunately this is also why systems often don't use such an approach, enabling Jupyter across Azure likely earned somebody a promotion.

> A privilege escalation vulnerability allowed anyone with a Cosmos DB account to filch the private key for any other Cosmos DB account, by way of the Jupyter notebook functionality.

Could we not be served the same article?

So the good news is you aren't seeing things, that is what the Ars article said. The bad news is that Ars are wrong and these are clearly not private keys but shared secrets.

Other people have linked Microsoft's documentation, the control panel for Cosmos DB lets you ask for new keys and warns you they may take minutes to be ready, so that means it's a shared secret, as a private key would be something you pick and don't reveal to Microsoft.

Indeed. Under FF reader mode the carousel is flattened into normal inline illustrations so I thought for a moment they could A/B test the article content.

I don't know how these security boundaries are usually implemented, but I would expect this bug to be way less plausible. Isn't this an architectural smell?

I believe a 3rd group should be founded - our programmers did something stupid, looking for that.