For the second time in two years, malicious hackers have taken advantage of a flaw in a cloud provider’s identity service to orchestrate an intelligence coup. In 2021, Russian hackers carried out an operation that began with a supply chain attack targeting the managed service provider SolarWinds and then manipulated flawed Microsoft identity systems to penetrate hundreds of victim organizations. And just last week, Microsoft revealed another operation — this time carried out by hackers based in China — that also took advantage of a flawed identity service to access email inboxes, including those belonging to the U.S. secretary of commerce and State Department officials.
Identity is the means of determining who can see, interact with and modify each piece of a digital workspace. Cloud infrastructure providers rely on various services to store and validate these identities. Today, these services are more important than ever as more users move to the cloud, and companies make identity a front line of defense against adversaries. Getting identity services right is essential to delivering the perceived security benefits of cloud computing.
Both the Biden administration and technology companies have urged government and private sector entities to move their technology infrastructure into the cloud, in part out of the belief that doing so will deliver major security benefits. In 2021, for example, Microsoft President Brad Smith said in testimony before the U.S. House of Representatives that not doing so was like “leaving your keys on the kitchen table.” If we extend Smith’s metaphor to the most recent operation against the company, it seems that Microsoft left its own keys on the table inside its own house only to have them swiped and used against 25 different customers.
Holding cloud providers accountable for the security of their infrastructure requires understanding what happens when critical parts of that infrastructure, and not just customer facing products, fail. But key questions remain unanswered about just how hackers based in China were able to abuse Microsoft’s systems to read the secretary of commerce’s emails. If the policy community wants to hold cloud providers, including Microsoft, accountable here are three questions that must be answered.
Where did the attackers obtain a Microsoft account consumer signing (MSA) key?
In carrying out the recently disclosed attack, hackers based in China obtained a Microsoft account consumer signing key that was used to forge authentication tokens for Outlook Web Access and Outlook.com. But it remains unclear how the attackers obtained the key in the first place. Was it obtained from a consumer or enterprise resource, a customer system or the first-party Microsoft corporate network?
The source of this key, as much as the design flaws that allowed it to sign for tokens hither and thither, will influence our perspective on whether this incident is in fact, as one White House official has already rashly labeled it, “much narrower” than the Solar Winds/Sunburst campaign of several years ago. Was the key and its signing power wholly within Microsoft’s control or was this another gap in the so called “shared responsibility” model in which cloud users must partner with cloud providers to ensure theirs is a safe and happy fate?
How the key was obtained may have important implications for whether and how Microsoft is held to account for this incident. The Biden administration’s National Cybersecurity Strategy includes a proposal for a liability scheme, but a more recent “implementation plan” has walked that back to a White House-hosted conference sometime next year. However, there is a program on the books today that the administration could use to hold Microsoft and other cloud providers accountable for the secure design of their infrastructure — the Civil Cyber Fraud Initiative, which seeks to use the False Claims Act to go after government contractors that fail to follow cybersecurity standards. The method by which the key was obtained may shape whether the administration thinks this is a sufficiently calamitous incident to act with the tools in hand.
Did the attackers use the same MSA key in multiple customer environments?
A pivotal assumption underlying the cloud computing business model is that providers can reasonably ensure the that customers and their data will be separated and isolated from one another. “Multi-tenancy” allows multiple customers to share the same cloud infrastructure, and it is the assumption upon which the economics of cloud computing are based. It assumes that Wells Fargo, Waymo and Wegmans data can share the same computing infrastructure, transit the same network, without Wells Fargo, Waymo or Wegmans being able to peek at their neighbors. To break this assumption would violate the prime directive that one customer must not be able to intrude on the activities of another.
In this incident, was an MSA key associated with one customer used to access the environment of many different customers? Put another way, did Microsoft promise to give every neighbor in the building a separate lock, then start lending out a master key for anyone to use because it was easier on building management? If Microsoft failed to maintain this separation, it may highlight another crack in the multi-tenant model and raise concerns about an important economic assumption underlying cloud computing offered by all companies and cut into revenues at a moment of critical competition, especially between Microsoft and Google.
Did the attackers use this key or the other revealed flaws in Microsoft’s cloud identity infrastructure to move between Office 365 Government and Office 365 Commercial?
Customers affected by the recently disclosed incident include both private sector entities and government agencies. These agencies supposedly have a different cloud available to them — Office 365 Government — than private sector clients. Cloud services can be offered together on the widely available “public cloud” or grouped together into “community” or “private” clouds. These community clouds, like Office 365 Government, are supposed to be “logically segregated” — isolated from a public cloud much like one tenant is supposed to be isolated from its neighbors. This is a substitute for physically separating cloud infrastructure, a model pioneered by Amazon Web Services as a way to save money instead of building government-only data centers and infrastructure.
Here, did the attackers use the same key to compromise accounts in both Office 365 Government and Office 365 Commercial? If so, why was a signing key from Office 365 Commercial allowed to sign tokens in Office 365 Government?
If the attackers did not use the same key to target both Microsoft’s government and commercial offerings, did the hackers target solely personal accounts? Or were senior U.S. government officials being allowed to use Microsoft resources outside of the FedRAMP approved offerings for their agency?
If an attacker was able to target both government and public clouds, it undermines the premise of logical isolation between these infrastructures, which cloud service providers have relied on to sell government-only “community clouds.” This has harsh business implications but might force a useful reckoning of the extent to which these isolated clouds are useful for all but the most secretive and sensitive customers.
If cloud service providers cannot reliably separate their infrastructure logically into “high” and “low” security under existing models, then governments might have to determine, in partnership with the private sector, how to ensure adequate security of all cloud infrastructure for use by private and public sector users alike, physically separating only a small number of defense and intelligence community clouds.
Policy for securing cloud systems
The flaws discovered in Microsoft’s cloud services — both here and in SolarWinds/Sunburst — are design flaws in the infrastructure of Microsoft’s cloud service. They are the sorts of architectural flaws that any cloud provider might be subject to, like a missing support beam that causes a building to collapse with just the right wind. Just because customers may not be able to resolve them with a patch as with many other software vulnerabilities does not mean transparency, accurate recording, and action to address them are not important. These kinds of infrastructure flaws should be the new focus for cloud policy, requiring that regulators hold companies accountable for choices they make in the design of their infrastructure, not just the security outcomes of their products.
It will require tremendous focus from the White House to bring companies to the table to talk about how they make these design choices and then hold firms accountable for those choices using existing authorities. This will require adapted policy tools from Congress to perfect, but it’s an effort the administration can start tomorrow with the authorities and resources they already have.
With a measure of accountability, the cybersecurity community and policymakers can ensure that next time malicious hackers attack cloud infrastructure the flaws are smaller and harder to exploit, the attackers are more rapidly detected and the compromise of a cloud service is less consequential.
If the cloud is as important as documents such as EO 14028 and the National Cybersecurity Strategy would have you believe, then there’s no time to waste.
Dr. Trey Herr is the director of the Atlantic Council’s Cyber Statecraft Initiative under the Digital Forensic Research Lab.
