Microsoft anunció recientemente que los atacantes de Solarwinds han visto su código fuente de Windows. (Normalmente, solo los clientes clave del gobierno y los socios de confianza tendrían este nivel de acceso a las "cosas" de las que está hecho Windows). Los atacantes pudieron leer, pero no cambiar, la salsa secreta del software, lo que generó preguntas y preguntas. preocupaciones de los clientes de Microsoft. ¿Significaba esto, quizás, que los atacantes podían inyectar procesos de puerta trasera en los procesos de actualización de Microsoft?
First, a bit of background on the Solarwinds aka Solorigate attack: An attacker broke into a remote management/monitoring tool company and was able to inject himself into the development process and build a gate. Stolen. When the software was updated through the normal update processes implemented by Solarwinds, the hijacked software was deployed to customer systems, including many US government agencies. UU. The attacker was then able to silently eavesdrop on various activities on these clients.
One of the attacker's techniques was to spoof tokens for authentication so that the domain system thought it was getting legitimate user credentials when, in fact, the credentials were spoofed. 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 for applications, as shown here, it can allow attackers to gain access to a system. The attack process, known as the 'Golden SAML' attack vector, "involves attackers first gaining administrative access to an organization's Active Directory Federation Services (ADFS) server and stealing the private key and certificate of the organization." organization". signature required. " This allowed continued access to these credentials until the ADFS private key was invalidated and replaced.
Attackers are currently known to have been on updated software between March and June 2020, although there are indications from various organizations that they may have been silently targeting sites as of October 2019.
Microsoft investigated further and found that while the attackers could not inject themselves into Microsoft's ADFS/SAML infrastructure, "one account had been used to view source code in multiple source code repositories. The account was not authorized to change any engineering code or system, and our investigation confirmed that no changes were made. "This is not the first time that Microsoft source code has been hacked or leaked on the Web. In 2004, 30.000 files from Windows NT to Windows 2000 were released to the Web by a third party. Windows XP was reportedly leaked online last year.
While it would be unwise to assert with authority that Microsoft's update process can never have a back door, I still trust Microsoft's own update process, even if I don't. Trust the company's solutions the moment they are released. Microsoft's update process depends on code signing certificates that must be matched; otherwise, the system will not install the update. Even when you use the distributed patch process in Windows 10 called Delivery Optimization, the system will pull parts of a patch from other computers on your network, or even from other computers outside your network, and recompile the patch. corrects the integer by matching the signatures. This process ensures that you can get updates from anywhere, not necessarily from Microsoft, and your computer will verify that the patch is valid.
There have been occasions where this process has been intercepted. In 2012, the Flame malware used a stolen code signing certificate to make it look like it came from Microsoft to trick systems into allowing the installation of malicious code. But Microsoft revoked that certificate and increased the security of the code signing process to ensure that the attack vector was stopped.
Microsoft's policy is to assume that its source code and network are already compromised, and therefore has an "assumed infringement" philosophy. So when we get security updates, we don't just get fixes for what we know; I often see vague references to additional hardening and security features that help users move 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 monthly security updates specifically address a reported vulnerability, there are also elements that make it more difficult for attackers to use known techniques for malicious purposes.
Feature releases often increase the security of the operating system, although some of the protections require a license from Microsoft 365 Enterprise called an "E5" license. But you can still use advanced protection techniques, but with manual registry keys or by modifying group policy settings. An example of this is a group of security parameters designed to reduce the attack surface; uses various settings to prevent malicious actions from taking place on your system.
But (and that's a big but), defining these rules means you have to be a power user. Microsoft considers these features more targeted at enterprises and businesses and therefore does not expose settings in a user-friendly interface. If you are an advanced user and want to review these Attack Surface Reduction Rules, my recommendation is to use the PowerShell GUI tool called GUI ASR Rules PoSH to set the rules. First set the rules to 'audit' instead of enable so that you can examine the impact on your system first.
You can download the GUI from the github site and you will see these rules listed. (Note that you need to run as administrator: right-click the downloaded .exe file and click Run as administrator.)
<p>Copyright © 2021 IDG Communications, Inc.</p>