Microsoft recently announced that its Windows source code had been viewed by the SolarWinds attackers. (Normally, only key government customers and trusted partners would have this level of access to the “stuff” of which Windows is made.) The attackers were able to read – but not change – the software secret sauce, raising questions and concerns among Microsoft customers. Did it mean, perhaps, that attackers could inject backdoor processes into Microsoft’s updating processes
First, a bit of background on the SolarWinds attack, also called Solorigate: An attacker got into a remote management/monitoring tool company and was able to inject itself into the development process and build a backdoor. When the software was updated through the normal updating processes set up by SolarWinds, the backdoored software was deployed into customer systems — including numerous US government agencies. The attacker was then able to silently spy on several activities across these customers.
One of the attacker’s techniques was to forge tokens for authentication so that the domain system thought it was getting legit user credentials when, in fact, the credentials were faked. Security Assertion Markup Language (SAML) is regularly used to transfer credentials securely between systems. And while this single sign-on process can provide additional security to applications, as showcased here, it can allow attackers to gain access to a system. The attack process, called a “Golden SAML” attack vector “involves the attackers first gaining administrative access to an organization’s Active Directory Federation Services (ADFS) server and stealing the necessary private key and signing certificate.” That allowed for continuous access to this credential until the ADFS private key was invalidated and replaced.
Currently it’s known that the attackers were in the updated software between March and June 2020, though there are signs from various organizations that they may have been quietly attacking sites as long ago as October 2019. Windows 10 security: Are you on the right version?https://imasdk.googleapis.com/js/core/bridge3.432.0_en.html#goog_1599119546Volume 0%
Microsoft investigated further and found that while the attackers were not able to inject themselves into Microsoft’s ADFS/SAML infrastructure, “one account had been used to view source code in a number of source code repositories. The account did not have permissions to modify any code or engineering systems and our investigation further confirmed no changes were made.” This is not the first time Microsoft’s source code has been attacked or leaked to the web. In 2004, 30,000 files from Windows NT to Windows 2000 leaked onto the web via a third party. Windows XP reportedly leaked online last year.
While it would be imprudent to authoritatively state that the Microsoft update process can never have a backdoor in it, I continue to trust the Microsoft updating process itself — even if I don’t trust the company’s patches the moment they come out. The Microsoft updating process depends on code-signing certificates that have to match up or the system will not install the update. Even when you use the distributed patch process in Windows 10 called Delivery optimization, the system will get bits and pieces of a patch from other computers on your network – or even other computers outside of your network – and recompile the entire patch by matching up the signatures. This process ensures that you can get updates from anywhere — not necessarily from Microsoft — and your computer will check to make sure the patch is valid.
There have been times when this process has been intercepted. In 2012, the Flame malware used a stolen code-signing certificate to make it look as if it came from Microsoft to trick systems into allowing malicious code to be installed. But Microsoft revoked that certificate and increased the security of the code-signing process to ensure that the attack vector would be shut down.
Microsoft’s policy is to assume that its source code and network is already compromised and thus it has an “assume breach” philosophy. So when we get security updates, we don’t just receive fixes for what we know; I often see vague references to additional hardening and security features that help users going forward. Take, for example, KB4592438. Released for 20H2 in December, it included a vague reference to updates to improve security when using Microsoft Edge Legacy and Microsoft Office products. While most of each month’s security updates specifically fix a declared vulnerability, there are also parts that instead make it harder for attackers to use known techniques for nefarious ends.
To deliver secure, highly reliable connectivity to cloud applications and data centers, IT needs a simple orchestration tool.
Feature releases often bolster security for the operating system, though some of the protections mandate an Enterprise Microsoft 365 license called an “E5” license. But you can still use advanced protection techniques but with manual registry keys or by editing group policy settings. One such example is a group of security settings designed for attack surface reduction; you use various settings to block malicious actions from occurring on your system.
But (and this is a huge but), to set these rules means that you need to be an advanced user. Microsoft considers these features to be more for enterprises and businesses and thus doesn’t expose the settings in an easy-to-use interface. If you are an advanced user and want to check out these attack surface reduction rules, my recommendation is to use the PowerShell graphical user interface tool called ASR Rules PoSH GUI to set the rules. Set the rules first to “audit” rather than making them enabled so you can first review the impact on your system.
You can download the GUI from the github site and you’ll see these rules listed. (Note, you need to Run as administrator: right mouse click on the downloaded .exe file and click on run as administrator.) It’s not a bad way to harden your system while the fallout from the SolarWinds attack continues to unfold.