[insomniacity]

> The old public key’s certificate revealed it was issued on April 5th, 2016, and expired on April 4th, 2021, and its thumbprint matched the thumbprint of the key Microsoft listed in their latest blog post, named “Thumbprint of acquired signing key”

Am I reading this right? The key was expired? And still in use??

[tzs]

I have no idea how validity works for the systems these keys are used in, but I do know that in general there are two ways that key or certificate based verification handles an expired key or certificate. Anyone know which of these is the way whatever Microsoft was using these things for works?

In one of them, which is the way TSL verification works, it goes something like this when checking certificate Cn that is signed by Cn-1 which is signed by ... is signed by C0.

  1   time_check = now()
  2   for cert in Cn to C0
  3      if time_check < cert.valid_from || time_check > cert.valid_to
  4          return EXPIRED
  5   return NOT_EXPIRED

Each certificate's expiration is checked against the current time.

The other, which is used for code signing, goes something like this:

  1   time_check = now()
  2   for cert in Cn to C0
  3      if time_check < cert.valid_from || time_check > cert.valid_to
  4          return EXPIRED
  5      time_check = cert.issue_time
  6   return NOT_EXPIRED

Cn is checked against the current time. The rest of them are checked against the time at which they signed the next downstream certificate.

I understand why code signing works like that. It's essentially digital notarization, and you don't want your notarized documents to become no longer notarized just because the notary public you used has since stopped being a notary public and let their license expire.

[dhx]

When Microsoft explained to their customers:

"Storm-0558 acquired an inactive MSA consumer signing key"[1]

They should have said:

"Storm-0558 acquired an EXPIRED MSA consumer signing key"

And when they said:

"a validation issue allowed this key to be trusted for signing Azure AD tokens."[1]

They should have said:

"MULTIPLE validation issues allowed this key to be trusted for signing Azure AD tokens."

And when Microsoft said:

"The actors are keenly aware of the target’s environment, logging policies, authentication requirements, policies, and procedures."

They should have said something like:

"The actors could have been aiming for a brazen hit-and-run and didn't stop for a second to think about policies and other nonsense. Alternatively, the actors were unsophisticated and completely unaware of facts like the US State Department paying us a stack more money for the privilege of being able to log mailbox access events in detail (thanks Boeing for the tip from MCAS!). Additionally, the actors appear to have neglected the fact that Chrome 92 was last updated in 2021 and therefore a fairly bad choice of user agent to use for an attack against a US department whose ICT systems should be using the latest version of web browsers. Additionally, the actors likely had no idea how US State Department mailboxes are accessed, and made a very poor guess of it by using random public data centres throughout Europe."[2][3]

[1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...

[2] https://www.cisa.gov/news-events/cybersecurity-advisories/aa...

[3] https://www.theguardian.com/us-news/2023/jul/20/ambassador-t...