Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

On the contrary, Azure has a much better security culture than Windows business unit.

Most stuff is built with .NET, Go, Java and Rust, while the hypervisors are based on Windows (Azure Host OS[0]) it isn't the same as regular Windows, and most workloads are Linux based, officially > 60% [1].

Finally, starting this year, Azure has new security guidelines, all new software is to be written in managed languages, if a GC is not an impediment, Rust otherwise.

Writing code in either C or C++, is only allowed for existing products, with the related security guidelines in place[2].

[0] - https://techcommunity.microsoft.com/t5/windows-os-platform-b...

[1] - https://azure.microsoft.com/en-us/products/virtual-machines/...

[2] - https://x.com/dwizzzleMSFT/status/1720134540822520268



Thank you, I really appreciate this response. I need to read all of this. However, the most recent compromises did happen on Azure, and not Windows, correct?

edit: and of course that's where the threat actors put their focus, because that's where the data lived.


The whole issue is with Recall storage, and information gathering on Windows.


Yes, sorry, I had diverged upthread into the part where the CCP read the USA's gov emails.

I can't get over that little tidbit.


Per Microsoft's write-up:

> Storm-0558 acquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com. All MSA keys active prior to the incident – including the actor-acquired MSA signing key – have been invalidated. Azure AD keys were not impacted. The method by which the actor acquired the key is a matter of ongoing investigation. Though the key was intended only for MSA accounts, a validation issue allowed this key to be trusted for signing Azure AD tokens. This issue has been corrected.

So the attackers found a valid private key for MSA (undetermined how, the theory was that it was scraped from a debug dump that was moved from high privilege prod to someone's low privilege shared drive). They then used that key to sign invalid tokens for AAD and the validating side incorrectly accepted those tokens. In this case, the validating side would be Exchange / OWA. Azure AD seems to not be implicated in the security issues, since it was MSA that leaked the key and OWA that failed to properly validate it.

That's my interpretation of the text anyway. It also aligns with my own understanding from a brief time at MS that Azure is much better at security than the rest of MS and that Exchange is a dumpster fire because of decades of cruft and evolution of systems.


Thank you so much, this really closed the gaps in my understanding of what really happened.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: