Solarwinds hack, Sologate and Windows update

The recent SolarWinds attack has raised serious questions about how secure businesses and government agencies are when an operating system or software update is released. Microsoft was also hit by the attack, so it's time to figure out what's going on.

Microsoft recently announced that SolarWinds attackers have verified the Windows source code (typically only major government customers and trusted partners have access to the Windows source code). The attacker could read the software source code, but could not change it.

This incident raised questions and concerns among Microsoft customers. This could mean an attacker could inject a backdoor process into the Microsoft update process.

Summarizing the SolarWinds attack, also known as the Solorigate, the attacker was able to break into a remote management/monitoring tool vendor and enter the development process to build a backdoor. When the software was updated through the usual update process set by SolarWinds, the backdoor was deployed to a number of corporate customer systems, including US government agencies. Then, the attacker could silently monitor the various activities of these customers.

The attacker used an attack technique to forge tokens for authentication, allowing the domain system to determine that it is receiving legitimate user credentials when the credentials are forged. Security Assertion Markup Language (SAML) is regularly used to securely transfer credentials between systems. This single sign-on process can provide additional security to your application, but it can also allow an attacker to gain access to your system.

Called Golden SAML, this attack process involves an attacker first gaining administrative access to an enterprise's Active Directory Federation Services (ADSF) server, then stealing the necessary private keys and signing certificates. Thus, the attacker can continue to access these credentials until the ADFS private key is invalidated and replaced.

Currently, the attacker is known to have been on the updated software between March and June 2020, but there are indications that long before that, in October 2019, the attacker may have already attacked the site and entered silently. 

The attacker looked into the Windows source code, but there was no modification 

"The attacker could not directly connect to Microsoft's ADFS/SAML infrastructure," Microsoft said in further investigation, but using one account to view the source code from multiple source code repositories. This account did not have permission to modify the code or engineering systems. And, as a result of the investigation, there was no change.” 

This is not the first time that Microsoft's source code has been attacked or leaked to the web. In 2004, from Windows NT to Windows 2000, 30,000 files were leaked to the Web through third parties. Windows XP was reportedly leaked online last year.

I can't confidently say that there is no backdoor to the Microsoft update process, but I trust the Microsoft update process itself. Even if you don't trust the patch the moment it comes out.

The Microsoft update process depends on the code signing certificate that must match. Otherwise, the system will not install the update. Even if you use a distributed patching process called Delivery optimization in Windows 10, the system takes a portion of the patch from another computer on the network or from another computer outside the network and recompiles the entire patch by matching signatures. This process allows you to get updates from anywhere outside of Microsoft, and your computer verifies that the patch is valid.

This process has never been blocked. In 2012, the Flame malware used stolen code-signing certificates to trick the system into installing malware as if it were from Microsoft. However, Microsoft tightened the security of the code signing process so that the certificate was revoked and the attack vector was terminated.

Microsoft's policy is based on 'assume breach' that the source code and network have already been hacked. So when you get a security update, you'll often see vague references to additional enhancements and security features that help you move forward, rather than just get fixes for what you already know.

For example, KB4592438, released last December for 20H2, contains an ambiguous reference to an update to improve security when using Microsoft Edge Legacy and Microsoft Office products. . Monthly security updates specifically address declared vulnerabilities, but there are also areas that make it difficult for an attacker to use known techniques for malicious purposes.

Feature releases often enhance the security of the operating system, but some protection features require an Enterprise Microsoft 365 license called the 'E5' license. However, you can still use advanced protection techniques, but you can use it by editing manual registry keys or Group Policy settings. One of these examples is a group of security settings designed to reduce the attack surface. Blocks malicious operations from occurring in the system by using various settings.

However, you need to be an advanced user to set these rules. Microsoft doesn't expose the settings in an easy-to-use interface because Microsoft believes these features are suitable for businesses. If you are an advanced user and want to check these attack surface reduction rules, it is recommended to set up the rules using the PowerShell GUI called ASR Rules PoSH GUI. You can first review the impact on the system by setting it to 'audit' without activating the rule.

If you download the GUI from the GitHub site, these rules are listed. For reference, it must be run with administrator privileges. Right-click the downloaded .exe file and click Run as administrator. As the aftermath of the SolarWinds attack continues, it is not a bad idea to strengthen system security.