CSRB Lashes Microsoft's 'Cascade of Security Failures'
Your weekly dose of Seriously Risky Business news is written by Tom Uren and edited by Patrick Gray. It's supported by Lawfare with help from the William and Flora Hewlett Foundation. This week's edition is sponsored by Resourcely.
You can hear a podcast discussion of this newsletter by searching for "Risky Business News" in your podcatcher or subscribing via this RSS feed.
The Cyber Safety Review Board (CSRB) has described 'a cascade of avoidable errors' by Microsoft in an incident in which a PRC-affiliated cyber espionage actor accessed email accounts belonging to senior US and UK officials.
A newly released report by the CSRB states:
In May 2023, a threat actor known as Storm-0558 compromised the Microsoft Exchange Online mailboxes of a broad range of victims in the United States, the United Kingdom, and elsewhere. Storm-0558, assessed by multiple sources to pursue espionage objectives and maintain ties with the People’s Republic of China (PRC), accessed email accounts in the U.S. Department of State, U.S. Department of Commerce, and U.S. House of Representatives. This included the official and personal mailboxes of U.S. Commerce Secretary Gina Raimondo; Congressman Don Bacon; U.S. Ambassador to the PRC, R. Nicholas Burns; Assistant Secretary of State for East Asian and Pacific Affairs, Daniel Kritenbrink; and additional individuals across 22 organisations. These senior officials have substantial responsibilities for many aspects of the U.S. government’s bilateral relationship with the PRC. Storm-0558 had access to some of these cloud-based mailboxes for at least six weeks, and during this time, the threat actor downloaded approximately 60,000 emails from State Department alone.
The review found that the threat actor responsible was also linked to the 2009 Operation Aurora compromise of dozens of private companies, including Google, and also to the 2011 RSA SecurID incident.
It says the group "behind the Operation Aurora campaign has been known to compromise cloud identity systems, steal source code, and engage in token-forging activities to gain access to targeted individuals' email accounts".
So this group has been honing this kind of tradecraft for at least 15 years.
The CSRB provides comprehensive detail about the Microsoft Exchange Online incident, including "the cascade of Microsoft's avoidable errors that allowed this intrusion to succeed".
We've covered some of these errors before. A Microsoft Services Account (MSA) signing key that should have expired in March 2021 still worked in 2023, for example, and although this key should only have been valid for consumer accounts, it worked for enterprise accounts too.
The compromise started some time in May, and Microsoft was first tipped off to it by the US State Department on 16 June. The State Department was able to detect the compromise because it paid for Microsoft's highest level of logging, and analysed these logs using custom security rules.
Many other affected organisations did not pay for these logs and as a result, were unable to detect the compromise.
Microsoft initially based its investigations on the assumption the incident had resulted from traditional threat vectors such as device compromise or credential theft. However, after pulling on the thread for 10 days and identifying 21 more affected organisations, Microsoft realised that Storm-0558 had been minting its own authentication tokens. Per the report:
This was the moment that Microsoft realised it had major, overlapping problems: first, someone was using a Microsoft signing key to issue their own tokens; second, the 2016 MSA key in question was no longer supposed to be signing new tokens; and third, someone was using these consumer key-signed tokens to gain access to enterprise email accounts.
According to Microsoft, this discovery triggered an all-hands-on-deck investigation by Microsoft that ran overnight from June 26 into June 27, 2023, focusing on the 2016 MSA key that had issued the token as well as the access token itself. By the end of the day, Microsoft had high confidence that the threat actor had forged a token using a stolen consumer signing key. Microsoft then escalated this intrusion internally, assigning it the highest urgency level and coordinating its investigation across multiple company teams. As a result, Microsoft developed 46 hypotheses to investigate, including some scenarios as wide-ranging as the adversary possessing a theoretical quantum computing capability to break public-key cryptography or an insider who stole the key during its creation. Microsoft then assigned teams for each hypothesis to try to: prove how the theft occurred; prove it could no longer occur in the same way now; and to prove Microsoft would detect it if it happened today. Nine months after the discovery of the intrusion, Microsoft says that its investigation into these hypotheses remains ongoing.
Unfortunately, this is the only section in the report where Microsoft treats its security problems with the urgency they deserve. The vendor undertook a series of remediation steps including revoking the stolen key, blocking Storm-0558's exploitation method, actually ensuring that consumer and enterprise keys worked as expected, and enhancing monitoring of its identity systems.
Microsoft observed the group use phishing to try to reacquire access to email accounts it had previously compromised, so these steps appear to have 'fixed' the particular vulnerability Storm-0558 used.
However, once Microsoft was satisfied with this tactical success it was back to 'business as usual'. The incident didn't trigger a wholesale reevaluation of the security of Microsoft's cloud environment.
The CSRB is very critical of what it says is Microsoft's refusal to admit that it doesn't have a good handle on how Storm-0558 acquired the MSA key. In September 2023, Microsoft published a blog post stating that the "most probable" way was that Storm-0558 had found the key in a crash dump that had been transferred off Microsoft's hardened production environment.
However, Microsoft subsequently learnt that most of the statements in that blog weren't correct. In particular, the company has not found a crash dump containing the key. This changes it from 'most probable' to 'theoretically possible' in our view, but it seems like Microsoft remained wedded to the explanation even as it became increasingly unlikely.
This is not the only recent major security incident involving Microsoft and actors affiliated with adversary states. In January this year, Microsoft announced a group it calls 'Midnight Blizzard', previously attributed to the Russian Foreign Intelligence Service (SVR) by the US government, was able to access sensitive Microsoft corporate email accounts.
The CSRB wrote that it was "troubled" by the Midnight Blizzard incident:
This additional intrusion highlights the Board’s concern that Microsoft has not yet implemented the necessary governance or prioritisation of security to address the apparent security weaknesses and control failures within its environment and to prevent similar incidents in the future.
After listing an extensive catalogue of mistakes, the Board writes that "individually, any one of the failings described above might be understandable. Taken together, they point to a failure of Microsoft’s organisational controls and governance, and of its corporate culture around security".
Microsoft has touted its 'Secure Future Initiative', announced in November last year, as a solution to its security difficulties. The CSRB, however, recommends that this initiative "and other security-related efforts should be overseen directly and closely by Microsoft's CEO and its Board of Directors, and that all senior leaders should be held accountable for implementing all necessary changes with utmost urgency."
The Board also recommends Microsoft develop "a plan with specific timelines to make fundamental, security-focused reforms across the company" and that "Microsoft leadership should consider directing internal Microsoft teams to deprioritise feature developments across the company's cloud infrastructure and product suite until substantial security improvements have been made".
It's a strong call to action and music to our ears. But will Microsoft listen? Or should the US government be lining up its sticks?
Supply Chain Compromises Find A Way
The attempted 'XZ Utils' backdoor is an evolutionary step in the long history of state-backed supply-chain attacks.
Risky Business News has an excellent wrapup of the incident, but the very short summary is that a persona-based operation carried out over a number of years was used to take over the XZ Utils open source project, a data compression suite.
This project was modified so that under certain conditions it would place a backdoor in Linux's SSH server. This backdoor would provide admin-level remote code execution when triggered with the right cryptographic key.
This is possible because Linux's SSH server is started by its service manager (systemd), which partly relies on XZ Utils.
The persona-based portion of the operation involved several GitHub accounts that either helped or harassed the original project owner, Lasse Collin, who has been working on XZ since the mid-2000s. One of the helpful personas, Jia Tan, became a project maintainer in September 2022, nearly a year after first suggesting an innocuous patch on the project. Several other personas pressured Collin about the pace of progress during this time.
There are several reasons to believe this is a state-backed operation including the duration of the operation, reasonable OPSEC and the sophistication of the technical portion of the attack.
Combining persona-based operations to enable deployment of a backdoor is new, but it is really just a variation on a theme.
State-backed supply-chain operations have used techniques ranging from interdiction and modification of devices as they are shipped to customers to placing malicious insiders in companies. Cyber operations are also commonly used.
The 2020 SolarWinds breach, for example, used a cyber operation to modify SolarWind's build process to push out malware to selected customers.
And back in 2015 Juniper announced that its ScreenOS software had been compromised with two distinct backdoors that dated back to 2012. One allowed an informed eavesdropper to passively decrypt VPN traffic. Another bypassed authentication for SSH and Telnet. It hasn't been fully explained how ScreenOS was modified, although these backdoors were presumably cyber-enabled given the age of the incident.
Whereas many other examples are cloaked in secrecy, the public nature of open source software has meant that in the case of XZ Utils, there is now a tremendous amount of information available about the attack. From a researcher and defender point of view, this is a good thing.
On the flip side, this also provides a blueprint for other attackers who might want to carry out the same sort of attack. And the fundamental drivers for this sort of operation, such as improved security for developer accounts on GitHub, aren't going away.
These types of attacks are already popping out of the woodwork. Risky Business News' Wednesday edition covers a similar style attack on F-droid that dates back to 2020. (F-droid is an open source app store for Android devices).
The Risky Business podcast has an extensive discussion on this incident and an interview with Anders Freund, the developer who stumbled across the backdoor while troubleshooting SSH server processes that were using a surprising amount of CPU.
Three Reasons to Be Cheerful This Week:
- Tying authentication cookies to devices: Google is prototyping a new web capability called Device Bound Session Credentials (DBSC). The idea is to bind authentication tokens to a specific device, so that cookie theft is useless.
- Indians rescued from scam centres: The Indian government has confirmed that 250 Indian nationals have been rescued from forced labour in Cambodian scam or 'pig butchering' call centres.
- Exploit mitigation making 0days harder: Google's latest 0day year in review report says that exploit mitigation technologies really do make exploitation more difficult. For example, no new use-after-free vulnerabilities were exploited in Chrome thanks Chrome's MiraclePtr mitigation. The report also cites the V8 heap sandbox in JavaScript engines and iOS's Lockdown mode as successful examples of exploit mitigations.
Sponsor Section
In this Risky Business News sponsor interview, Catalin Cimpanu talks with Resourcely co-founder and CEO Travis McPeak about how the DevOps ecosystem has evolved and ushered the need for DevSecOps and how the company provides and manages its secure-by-default templates.
Shorts
Critical Infrastructure Regulations Thud Into Inboxes
CISA has published its notice of proposed rulemaking, i.e. draft regulations, spelling out how critical infrastructure entities will have to report cyber security incidents to it.
The regulation is commonly known as CIRCIA, as it is authorised by the Cyber Incident Reporting for Critical Infrastructure Act, and comments on the proposed rules are due in 60 days. We support the idea that government agencies should be empowered to know what is going on amongst critical infrastructure, but at 447 pages the proposed rules are comically long.
One rule we positively like, as pointed out by John Sakellariadis of Politico, would require reporting of incidents of unauthorised access "facilitated through or caused by a compromise of a CSP [Cloud Service Provider], managed service provider, other third-party data hosting provider, or by a supply chain compromise".
CyberScoop has further coverage.
Protecting Customers From Location Tracking
The US Federal Communications Commission announced last week that it is investigating how to protect customers from location tracking using vulnerabilities in the Signalling System 7 (SS7) protocol that is used to control calls across phone networks.
The collection and sale of geolocation data willy nilly is a big deal, but we don't think SS7 vulnerabilities are the most pressing problems given what else we know about the geolocation-for-sale landscape. Still, it's a good move to at least come up with an informed assessment of the problem.
Risky Biz Talks
You can find the audio edition of this newsletter and other fine podcasts and interviews in the Risky Biz News feed (RSS, iTunes or Spotify).
In our last "Between Two Nerds" discussion Tom Uren and The Grugq look at how states have very different views about manipulating the information environment aka 'information warfare'.
From Risky Biz News:
Spyware vendors behind 24 zero-days last year: Commercial spyware/surveillance vendors were behind 24 of the 97 zero-days that were exploited in the wild in 2023, according to a Google report published this week.
Eleven of the 24 zero-days impacted Safari and iOS, while the rest impacted Android and other Google products.
The data shows a clear interest from spyware vendors for mobile platforms. Google says it did not link any non-Apple or non-Google zero-days to spyware vendors.
Attribution was only possible for 58 of the 97 zero-days discovered last year. Spyware vendors and APT espionage groups each accounted for 24 zero-days, while financially-motivated groups (ransomware gangs, initial access brokers, etc.) accounted for the other 10.
[more on Risky Business News]
NVD consortium plan gets criticised: NIST's plan to create a larger consortium to manage the NVD instead of its beleaguered staff is getting pushback from the industry because it's taking too much to pull together, leaving the US vulnerability database increasingly out of date and behind the curve. [New coverage in CyberScoop and our original coverage on the topic]
Russian prison system hack: An anti-Kremlin hacktivist group has hacked Russia's prison system following the death of opposition leader Alexey Navalny. The hackers claim they stole a database containing the data of hundreds of thousands of Russian prisoners. The database contains information on prisoners, their families, and contact information. The hackers claim they are a mix of nationalities, including Russian expats and Ukrainians. [Additional coverage in CNN]
