Former employee says software giant dismissed his warnings about a critical flaw because it feared losing government business. Russian hackers later used the weakness to breach the National Nuclear Security Administration, among others.
The federal government was preparing to make a massive investment in cloud computing, and Microsoft wanted the business. Acknowledging this security flaw could jeopardize the company’s chances, Harris recalled one product leader telling him. The financial consequences were enormous. Not only could Microsoft lose a multibillion-dollar deal, but it could also lose the race to dominate the market for cloud computing.
Harris said he pleaded with the company for several years to address the flaw in the product, a ProPublica investigation has found. But at every turn, Microsoft dismissed his warnings
his fears became reality. U.S. officials confirmed reports that a state-sponsored team of Russian hackers had carried out SolarWinds, one of the largest cyberattacks in U.S. history. They used the flaw Harris had identified to vacuum up sensitive data from a number of federal agencies, including, ProPublica has learned, the National Nuclear Security Administration, which maintains the United States’ nuclear weapons stockpile, and the National Institutes of Health, which at the time was engaged in COVID-19 research and vaccine distribution. The Russians also used the weakness to compromise dozens of email accounts in the Treasury Department, including those of its highest-ranking officials. One federal official described the breach as “an espionage campaign designed for long-term intelligence collection.”
Harris’ account, told here for the first time and supported by interviews with former colleagues and associates as well as social media posts, upends the prevailing public understanding of the SolarWinds hack.
the board’s report identified a “corporate culture that deprioritized both enterprise security investments and rigorous risk management.”
ProPublica’s investigation adds new details and pivotal context about that culture, offering an unsettling look into how the world’s largest software provider handles the security of its own ubiquitous products. It also offers crucial insight into just how much the quest for profits can drive those security decisions, especially as tech behemoths push to dominate the newest — and most lucrative — frontiers, including the cloud market.
I read the article as criticism of the lack of defense in depth, where compromise of a specific server gives access to keys that give near-untraceable access to all servers. Yes, Solarwinds fucked up by putting their keys in a place where someone could access it, but Golden SAML is the technique that makes a breach worse.
It’s mostly the responsibility of the client to build defense in depth. If is a straight shot from your Solarwinds server to your ADFS server, where the SAML signing keys are stored, that’s your fault, not Solarwinds or Microsoft. Well, I would still blame Solarwinds, because they were encouraging horribly insecure practices, like doing “agentless” monitoring using a highly privileged account.
In this case, yes, not letting a SAML assertion signed by the ADFS server authenticate to Azure reduces defense in depth. But if you’re at the point where your authentication servers have been compromised, you’re already so turbo-fucked that it’s very unlikely a wall like that would stop an attacker for long.
I’m not going to pretend to be an expert on this (I worked in cybersecurity in 2000’s but was only entry level, and changed careers before cloud/mobile made things way more complicated), but the general point still seems true: security requires conscious design that discourages poor configuration by client IT, and makes bad practices unviable by not only end users, but also the sysadmins who manage the actual IT resources. Then, things should be limited in impact.
In other words, the manufacturer doesn’t get to wash their whole hands of this thing if their design makes it easy for clients to screw up. In this case, it does sound like these systems were deployed by clients that didn’t have a solid understanding of the relationships between on-prem AD and ADFS and didn’t know how to configure them securely, that’s also a significant documentation/education issue that Microsoft owns some responsibility for.
(Plus in the case of the Solarwinds hack, there were a few other Microsoft vulnerabilities exploited to get to the point where the hackers could traverse the system looking for keys/certificates.)
So I don’t think this particular dude was warning about a non-vulnerability, and it sounds like the “security boundary” response he met with internally is similar to how you’re responding to this report.