Consider recommendations from Cyber Safety Review Board report

Nat Sakimura

Here is an internal report that might help OID determine impact: == It seems like numbers don’t work here. = = Stateful is described below ~~#18~~.

This is primarily a cloud problem that has little to do with wire protocols The National Institute of Standards and Technology (NIST) and the Risk Management Framework (RMF) Joint Task Force (JTF) should update Special Publication (SP) 800-53’s control catalog to better account for risks to cloud-based digital identity systems,
To drive the rapid cultural change that is needed within Microsoft, the Board believes that Microsoft’s customers would benefit from its CEO and Board of Directors directly focusing on the company’s security culture and developing and sharing publicly a plan with specific timelines to make fundamental, security-focused reforms across the company and its full suite of products.
Cloud Service Provider Cybersecurity Practices: Cloud service providers should implement modern control mechanisms and baseline practices, informed by a rigorous threat model, across their digital identity and credential systems to substantially reduce the risk of system-level compromise. è Comment – threat models are not abstraction like listed here, they need to be focused on some deliverable.
Audit Logging Norms == This is primarily org focused. Perhaps a link to SSE might help in OID protocol specs
Digital Identity Standards and Guidance: Cloud service providers should implement emerging digital identity standards to secure cloud services against prevailing threat vectors. Relevant standards bodies should refine, update, and incorporate these standards to address digital identity risks commonly exploited in the modern threat landscape.
Cloud Service Provider Transparency: Cloud service providers should adopt incident and vulnerability disclosure practices to maximize transparency across and between their customers, stakeholders, and the United States government, even in the absence of a regulatory obligation to report.
Victim Notification Processes: Cloud service providers should develop more effective victim notification and support mechanisms to drive information-sharing efforts and amplify pertinent information for investigating, remediating, and recovering from cybersecurity incidents
the actor stole secret keys used to generate authentication codes for SecurID tokens, which were used by tens of millions of users - Ultimately, Microsoft determined that Storm-0558 used an acquired MSA consumer token signing key to forge tokens to access Microsoft – but they have NO IDEA how that happened - On 2023-06-24, Microsoft invalidated the stolen key the threat actor was using è I have wondered about the tendency of some of the newer OIDC standards to tell the various cloud services what they must do. And each standard has its own list – IMHO this is really pointless as the mandates don’t match between standards.
user emails è I think the point here is that no codes can be in email except perhaps one that expire within 15 mins.

10. Ultimately, Microsoft determined that Storm-0558 used an acquired MSA consumer token signing key to forge tokens to access Microsoft

11. tokens should only come from Microsoft’s identity system, yet these had not. Moreover, tokens used by the threat actor had been digitally signed with a Microsoft Services Account (MSA) è need to identify the services that can create valid tokens

12. Nine months after the discovery of the intrusion, Microsoft says that its investigation into these hypotheses remains ongoing. è speed is of the essence

13. Attack – who knows, MSFT doesn’t – the attack model can’t really address such a failure of internal control of signing keys – Microsoft told the Board that Storm-0558 had compromised Microsoft’s corporate network via an engineer’s account from an external laptop getting insider access - insider attacks are similar – a good assumption is that compromise of some internal accounts is inevitable.

14. Victims did not have the tools to determine where the breach was created. Microsoft never detected anything – all input came from outside MSFT and was coordinated by CISA. è pay attention to CISA reports

15. Victim coordination was complicated for this incident as it involved multiple U.S. government agencies, foreign governments, senior government officials, private sector organizations, and private individuals.

16. On July 11, 2023, Microsoft published its first blog about the Exchange Online intrusion, disclosing that Storm-0558 had used an MSA consumer signing key that enabled it to forge authentication tokens and access email accounts. When then did they reported some of the victims giving other attacks notice about weak points è don’t do that!

17. If Microsoft had not paused manual rotation of keys; if it had completed the migration of its MSA environment to rotate keys automatically – manual is BAD

18. Stateful tokens: Microsoft’s authentication system accepted a token that it had not issued.

19. Per customer keys (key scope): Microsoft had a single key that signed tokens for all consumer

20. Bound tokens: Microsoft’s identity system used bearer tokens that did not require any proof of possession, thus making the tokens more vulnerable to replay attacks

Microsoft insufficiently protected MSA system key materi

‌

2024-07-11T14:29:56+00:00

Comments (4)

Nat Sakimura
- changed status to open
Discussed the first step: Pam to write a scenario document and link it to this issue so that we will be able to understand the subject better.
- 2024-07-08T23:20:46+00:00
Nat Sakimura
Here is an internal report that might help OID determine impact: == It seems like numbers don’t work here. = = Stateful is described below ~~#18~~.
1. This is primarily a cloud problem that has little to do with wire protocols The National Institute of Standards and Technology (NIST) and the Risk Management Framework (RMF) Joint Task Force (JTF) should update Special Publication (SP) 800-53’s control catalog to better account for risks to cloud-based digital identity systems,
2. To drive the rapid cultural change that is needed within Microsoft, the Board believes that Microsoft’s customers would benefit from its CEO and Board of Directors directly focusing on the company’s security culture and developing and sharing publicly a plan with specific timelines to make fundamental, security-focused reforms across the company and its full suite of products.
3. Cloud Service Provider Cybersecurity Practices: Cloud service providers should implement modern control mechanisms and baseline practices, informed by a rigorous threat model, across their digital identity and credential systems to substantially reduce the risk of system-level compromise. è Comment – threat models are not abstraction like listed here, they need to be focused on some deliverable.
4. Audit Logging Norms == This is primarily org focused. Perhaps a link to SSE might help in OID protocol specs
5. Digital Identity Standards and Guidance: Cloud service providers should implement emerging digital identity standards to secure cloud services against prevailing threat vectors. Relevant standards bodies should refine, update, and incorporate these standards to address digital identity risks commonly exploited in the modern threat landscape.
6. Cloud Service Provider Transparency: Cloud service providers should adopt incident and vulnerability disclosure practices to maximize transparency across and between their customers, stakeholders, and the United States government, even in the absence of a regulatory obligation to report.
7. Victim Notification Processes: Cloud service providers should develop more effective victim notification and support mechanisms to drive information-sharing efforts and amplify pertinent information for investigating, remediating, and recovering from cybersecurity incidents
8. the actor stole secret keys used to generate authentication codes for SecurID tokens, which were used by tens of millions of users - Ultimately, Microsoft determined that Storm-0558 used an acquired MSA consumer token signing key to forge tokens to access Microsoft – but they have NO IDEA how that happened - On 2023-06-24, Microsoft invalidated the stolen key the threat actor was using è I have wondered about the tendency of some of the newer OIDC standards to tell the various cloud services what they must do. And each standard has its own list – IMHO this is really pointless as the mandates don’t match between standards.
9. user emails è I think the point here is that no codes can be in email except perhaps one that expire within 15 mins.
10. Ultimately, Microsoft determined that Storm-0558 used an acquired MSA consumer token signing key to forge tokens to access Microsoft

11. tokens should only come from Microsoft’s identity system, yet these had not. Moreover, tokens used by the threat actor had been digitally signed with a Microsoft Services Account (MSA) è need to identify the services that can create valid tokens

12. Nine months after the discovery of the intrusion, Microsoft says that its investigation into these hypotheses remains ongoing. è speed is of the essence

13. Attack – who knows, MSFT doesn’t – the attack model can’t really address such a failure of internal control of signing keys – Microsoft told the Board that Storm-0558 had compromised Microsoft’s corporate network via an engineer’s account from an external laptop getting insider access - insider attacks are similar – a good assumption is that compromise of some internal accounts is inevitable.

14. Victims did not have the tools to determine where the breach was created. Microsoft never detected anything – all input came from outside MSFT and was coordinated by CISA. è pay attention to CISA reports

15. Victim coordination was complicated for this incident as it involved multiple U.S. government agencies, foreign governments, senior government officials, private sector organizations, and private individuals.

16. On July 11, 2023, Microsoft published its first blog about the Exchange Online intrusion, disclosing that Storm-0558 had used an MSA consumer signing key that enabled it to forge authentication tokens and access email accounts. When then did they reported some of the victims giving other attacks notice about weak points è don’t do that!

17. If Microsoft had not paused manual rotation of keys; if it had completed the migration of its MSA environment to rotate keys automatically – manual is BAD

18. Stateful tokens: Microsoft’s authentication system accepted a token that it had not issued.

19. Per customer keys (key scope): Microsoft had a single key that signed tokens for all consumer

20. Bound tokens: Microsoft’s identity system used bearer tokens that did not require any proof of possession, thus making the tokens more vulnerable to replay attacks
1. Microsoft insufficiently protected MSA system key materi
‌
- 2024-07-11T14:29:56+00:00
Joseph Heenan reporter
Just for reference, I opened a ticket for the FAPI working group to consider if the same items should be mentioned in FAPI or not: https://bitbucket.org/openid/fapi/issues/704/consider-recommendations-from-cyber-safety
- 2024-07-11T14:33:04+00:00
Joseph Heenan reporter
Just for the record: We discussed this again on last week’s Connect WG call. With the recommendation that sender constrained access tokens become mandatory it might be that it’s time for a OpenID Connect 1.1 to be created that makes sender constrained tokens mandatory. It could also mandate PKCE which would be an alternative solution for aligning OpenID Connect with the OAuth BCP / OAuth 2.1 ( https://bitbucket.org/openid/connect/issues/1362/alignment-of-certification-tests-with ).
- 2024-07-15T08:51:46+00:00
Log in to comment