5 ms·

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 krbt

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 SAML token so they could generate their own. Unless there was some vulnerability that exposed the key publically, I fail to see how in this particular incident its Microsoft's fault.

Thorrez 2y ago
>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 Microsoft's fault. Andrew Harris wanted to warn customers about the weakness, and tell them they can prevent the weakness by disabling seamless SSO. Other Microsoft people said no, that would alert hackers to the attack, we want to keep the attack secret, and it also would jeopardize our contracts by making the default setting sound insecure. Then Golden SAML was published publicly, so that first reason was no longer valid, but Microsoft still wouldn't tell customers they could prevent the attack by disabling seamless SSO. Then Solarwinds happened, and Microsoft finally advised customers to disable seamless SSO.
- what-the-grump 2y ago
  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 accounts preventing this type of attack. But disabling SSO altogether is non-starter for most businesses, what are we going to do tomorrow? Spend months recreating 100,000x accounts in various applications, no. We decrypt ssl traffic in our company, someone steals the private key and now can read the entire stream including your bank account details, lets stop decrypting ssl traffic because someone might leak the key? The answer from the infosec communinity has been its worth the risk.
  - Thorrez 2y ago
    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?
    - HotPotato787 2y ago
      This is the mentioned article: https://techcommunity.microsoft.com/t5/microsoft-entra-blog/protecting-microsoft-365-from-on-premises-attacks/ba-p/1751754 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.
      - Thorrez 2y ago
        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.
        HotPotato787 2y ago
        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.
- chucke1992 2y ago
  > "disabling seamless SSO" It is never going to happen in the corporate. Never.
  - Thorrez 2y ago
    The article says Andrew Harris worked with the NYPD to disable it for their setup. And Microsoft themselves advised customers to disable it after Solarwinds.
- rb12345 2y ago
  > 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.
  - Thorrez 2y ago
    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.
temac 2y ago
This is ignoring security in depth, weaknesses, and security architecture. When ignoring that, you can not pretend, and MS did pretend, that you had a good enough stance on security. Fixing discovered vulns alone is mandated, it gives you maybe half a point, but the other 9.5 points or at least 5 before you can claim you care about security require more than fixing known vulns or waiting for world scale incident to "respond". You have to prevent issues.

Thorrez 2y ago

>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 Microsoft's fault. Andrew Harris wanted to warn customers about the weakness, and tell them they can prevent the weakness by disabling seamless SSO. Other Microsoft people said no, that would alert hackers to the attack, we want to keep the attack secret, and it also would jeopardize our contracts by making the default setting sound insecure. Then Golden SAML was published publicly, so that first reason was no longer valid, but Microsoft still wouldn't tell customers they could prevent the attack by disabling seamless SSO. Then Solarwinds happened, and Microsoft finally advised customers to disable seamless SSO.

what-the-grump 2y ago
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 accounts preventing this type of attack. But disabling SSO altogether is non-starter for most businesses, what are we going to do tomorrow? Spend months recreating 100,000x accounts in various applications, no. We decrypt ssl traffic in our company, someone steals the private key and now can read the entire stream including your bank account details, lets stop decrypting ssl traffic because someone might leak the key? The answer from the infosec communinity has been its worth the risk.
- Thorrez 2y ago
  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?
  - HotPotato787 2y ago
    This is the mentioned article: https://techcommunity.microsoft.com/t5/microsoft-entra-blog/protecting-microsoft-365-from-on-premises-attacks/ba-p/1751754 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.
    - Thorrez 2y ago
      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.
      - HotPotato787 2y ago
        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.
chucke1992 2y ago
> "disabling seamless SSO" It is never going to happen in the corporate. Never.
- Thorrez 2y ago
  The article says Andrew Harris worked with the NYPD to disable it for their setup. And Microsoft themselves advised customers to disable it after Solarwinds.
rb12345 2y ago
> 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.
- Thorrez 2y ago
  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.

temac 2y ago

This is ignoring security in depth, weaknesses, and security architecture. When ignoring that, you can not pretend, and MS did pretend, that you had a good enough stance on security. Fixing discovered vulns alone is mandated, it gives you maybe half a point, but the other 9.5 points or at least 5 before you can claim you care about security require more than fixing known vulns or waiting for world scale incident to "respond". You have to prevent issues.