Live data from Hacker News

Microsoft Chose Profit over Security, Whistleblower Says

propublica.org

301–310 of 318 posts

Re: Microsoft Chose Profit over Security, Whistleblower Says

#301

Earlier quoted context omitted.

I think there is too much confusion in the details of the actual attack. You have to steal the private key for the SAML signing certificate for an app. The correct answer would be to scope any token to only have access to what the app has access to, the second layer which is documented in their 2020 article, is to require mfa on admin actions, and the 3rd layer is to disconnect azure admin accounts from on-prem admin…

If all those other solutions are better, why does the article say this: >In the immediate aftermath of the attack, Microsoft advised customers of Microsoft 365 to disable seamless SSO in AD FS and similar products — the solution that Harris proposed three years earlier. And did Microsoft advise those other solutions prior to Solarwinds happening?

This is the mentioned article: https://techcommunity.microsoft.com/t5/microsoft-entra-blog/...

What it says is "be careful when using federated trust relationships, because if one of your trusted environments is pwned, it will be trusted by the others". That's very obvious.

And about "disable seamless SSO", I only found this: "On-premises SSO systems: Deprecate any on-premises federation and Web Access Management infrastructure and configure applications to use Azure AD." (Seems pretty basic too, especially considering how vulnerable on-prem ADs are).

The original article seems to paint this MS page as a security advisory or vulnerability notification, while it just seems to me to be a very very basic security guideline.

Re: Microsoft Chose Profit over Security, Whistleblower Says

#302

Earlier quoted context omitted.

Because as far as I can tell, there was no "vulnerability" here, it's just how the product works. Stealing an OAuth key is just as bad. Stealing a domain's krbtgt key is just as bad. Businesses want that when they login to a computer, they are SSO'ed in to all their apps. That's how ADFS works, you authenticate to it using kerberos and it issues you a SAML token. Here they stole apparently the key used to sign the SA…

>Stealing an OAuth key is just as bad What is an "OAuth key"? Do you mean an OAuth token? No, Golden SAML is worse than stealing an OAuth token, because an OAuth token is valid for 1 user, but Golden SAML can be used to impersonate any user. Also, OAuth tokens expire, but Golden SAML doesn't expire (although if you steal an OAuth refresh token, that won't expire). >I fail to see how in this particular incident its Mi…

> What is an "OAuth key"? Do you mean an OAuth token? No, Golden SAML is worse than stealing an OAuth token, because an OAuth token is valid for 1 user, but Golden SAML can be used to impersonate any user. Also, OAuth tokens expire, but Golden SAML doesn't expire (although if you steal an OAuth refresh token, that won't expire).

Stealing the OAuth token signing key, since then any fake OAuth tokens signed by it would be considered authentic.

Re: Microsoft Chose Profit over Security, Whistleblower Says

#303

Earlier quoted context omitted.

>Stealing an OAuth key is just as bad What is an "OAuth key"? Do you mean an OAuth token? No, Golden SAML is worse than stealing an OAuth token, because an OAuth token is valid for 1 user, but Golden SAML can be used to impersonate any user. Also, OAuth tokens expire, but Golden SAML doesn't expire (although if you steal an OAuth refresh token, that won't expire). >I fail to see how in this particular incident its Mi…

> What is an "OAuth key"? Do you mean an OAuth token? No, Golden SAML is worse than stealing an OAuth token, because an OAuth token is valid for 1 user, but Golden SAML can be used to impersonate any user. Also, OAuth tokens expire, but Golden SAML doesn't expire (although if you steal an OAuth refresh token, that won't expire). Stealing the OAuth token signing key, since then any fake OAuth tokens signed by it would…

There isn't necessarily an OAuth signing key. The OAuth tokens might not be signed. They might be random values, which act like a password, with a hash of them stored in a database so they can't even be stolen from the database.

Even if they are signed, it doesn't need to be as bad as Golden SAML, because OAuth tokens have a short expiration, so the signing key can have frequent automatic rotation, so any stolen signing key will quickly be useless. For the refresh tokens, they don't have fast expiration, so frequent rotation won't work, but you could have a hybrid system where the OAuth tokens use a frequently rotated signing key, but the refresh tokens are random values with hashes stored in a database.

Re: Microsoft Chose Profit over Security, Whistleblower Says

#304

Earlier quoted context omitted.

If all those other solutions are better, why does the article say this: >In the immediate aftermath of the attack, Microsoft advised customers of Microsoft 365 to disable seamless SSO in AD FS and similar products — the solution that Harris proposed three years earlier. And did Microsoft advise those other solutions prior to Solarwinds happening?

This is the mentioned article: https://techcommunity.microsoft.com/t5/microsoft-entra-blog/... What it says is "be careful when using federated trust relationships, because if one of your trusted environments is pwned, it will be trusted by the others". That's very obvious. And about "disable seamless SSO", I only found this: "On-premises SSO systems: Deprecate any on-premises federation and Web Access Management inf…

I think those things the article is advising are the same things Andrew Harris wanted to advise customers to do 3 years prior, but Microsoft didn't want to, because it would make the default configuration sound insecure (it kind of was), jeopardizing government contracts, especially since various government systems would break if those config changes were made.

Re: Microsoft Chose Profit over Security, Whistleblower Says

#305

Earlier quoted context omitted.

This is the mentioned article: https://techcommunity.microsoft.com/t5/microsoft-entra-blog/... What it says is "be careful when using federated trust relationships, because if one of your trusted environments is pwned, it will be trusted by the others". That's very obvious. And about "disable seamless SSO", I only found this: "On-premises SSO systems: Deprecate any on-premises federation and Web Access Management inf…

I think those things the article is advising are the same things Andrew Harris wanted to advise customers to do 3 years prior, but Microsoft didn't want to, because it would make the default configuration sound insecure (it kind of was), jeopardizing government contracts, especially since various government systems would break if those config changes were made.

I get what you're saying, but from my point of view, this seems like something that doesn't need to be advised, because it is so trivial. Yes, if someone pwns my AD, then they can also pwn my cloud if i'm using some sort of federated trust. Even if i'm not, and both systems are completely separate, they just need to steal passwords from the cloud admin, which should be easy given they're already domain admins.

Maybe Andrew being overly cautious, was assuming most government users didn't know these basic facts, and should be warned anyway? Was MS pushing back on his report because communicating something like this to users would probably sow too much confusion?

That would still a failure on MS's part, but would make for a much more boring story. The article makes it seem like Andrew discovered an atomic bomb and MS pushed it under the rug. The reality seems much more bland.

But still, could you elaborate on the default configuration being insecure? I know next to nothing about Azure/Entra, maybe I'm missing something important.

Re: Microsoft Chose Profit over Security, Whistleblower Says

#306

Earlier quoted context omitted.

> can of course install Arch or Gentoo or NixOS Minimal and then audit the packages that they're installing to see that there's no obvious security violations, but it's unrealistic to think that most non-software-engineer people are going to do that. It's a fantasy to think that random devs can audit kernel/security code. No single person can. Too many lines of code to audit (that you didn't write yourself). Even if…

Sorry, I guess I didn't really mean to imply I was going to dissect everything line by line, but I can at least look to see if every package in there is directly open-source and if there are any packages that are being pulled in that are frequent security concerns. ETA: I know I can technically do that with Ubuntu or Fedora or OpenSUSE as well, it's not like it's a secret which packages they include, but what I like…

> if there are any packages that are being pulled in that are frequent security concerns.

As an individual, do you think you can do that? I know a lot of packages with security concerns where CVEs are never issued. You just need to go to their PRs and luck into finding descriptions of a security fix. I doubt this would scale for a given individual.

Re: Microsoft Chose Profit over Security, Whistleblower Says

#307
”They saw it differently, Harris said. The federal government was preparing to make a massive investment in cloud computing, and Microsoft wanted the business. Acknowledging this security flaw could jeopardize the company’s chances, Harris recalled one product leader telling him. The financial consequences were enormous. Not only could Microsoft lose a multibillion-dollar deal, but it could also lose the race to dominate the market for cloud computing.”

There is something fundamentally broken about an organization’s culture when this type of thinking is pervasive in the organization.

Re: Microsoft Chose Profit over Security, Whistleblower Says

#308
post #236

Earlier quoted context omitted.

Did you buy the more expensive lock for your house? Are your doors fortified, if they are why isn't the steel an inch thicker? Do you also choose having money over security? Sounds like the government also chose having a more productive work force, etc, over higher costs and lower productivity.

Not sure what point you are trying to make - for one, I don’t keep anything valuable in my house. Two, I have adequate security measures for the threats I am likely to deal with - I have cameras, locks on all windows and doors, and I have alarms. The rough security/compliance world equivalent is a checklist that says “Do you lock your doors every night?” and you say “yea I do” regardless of whether or not you even ha…

It isn’t. If it was a false dichotomy everyone would just work from airgapped systems because there’s no trade off.

Re: Microsoft Chose Profit over Security, Whistleblower Says

#309

Earlier quoted context omitted.

> Are these ads only bundled with a certain versions of Windows? Yes. Enterprise customers can get builds without them, but home users can't.

I keep hearing that, but I still see plenty of ads (and other dark patterns like data collection you can't turn off) in Enterprise builds. I heard Win10 LTSC was somewhat better so I'm hoping there will be a Win11 LTSC coming out at some time with longer support.

You can absolutely turn off everything, but you don’t change those settings on the Win10 enterprise machines themselves. You can, technically, but it’s registry stuff. You put the machines in an Active Directory domain and you configure group policy to turn those things off, and you push those policies to the workstations in the domain.

This is 100% normal everyday stuff for enterprise customers, and an enormous pain in the ass for someone who pirates Windows Enterprise.

Re: Microsoft Chose Profit over Security, Whistleblower Says

#310

Earlier quoted context omitted.

I think those things the article is advising are the same things Andrew Harris wanted to advise customers to do 3 years prior, but Microsoft didn't want to, because it would make the default configuration sound insecure (it kind of was), jeopardizing government contracts, especially since various government systems would break if those config changes were made.

I get what you're saying, but from my point of view, this seems like something that doesn't need to be advised, because it is so trivial. Yes, if someone pwns my AD, then they can also pwn my cloud if i'm using some sort of federated trust. Even if i'm not, and both systems are completely separate, they just need to steal passwords from the cloud admin, which should be easy given they're already domain admins. Maybe…

It is pretty boring. Where I would blame Microsoft, there needs to be an easier way to setup AD, AAD, ADFS, without having a bunch of people be domain and global admins, like out of the boxed roles and better gui. Every ad deployment I’ve ever worked in is insecure due to complexity of secure deployment. So people running it are going to be logging in domain admin /ga to do basic crap like add a new hire.
Post reply on HN