Least Privilege Application Management - A Lesson Learned from SolarWinds Orion

The sophisticated, nation-state assault used to infiltrate SolarWinds Orion and then leveraged to compromise potentially thousands of its customers is astonishing in scope and potential fallout.

In a year of brutal lessons, this attack serves as a very loud and humbling reminder—anyone can be hacked. Anyone. No amount of security controls, software, processes, and training can block every attack. You always can and should strive to reduce risk, but that risk dial never goes completely to nil.

We are also reminded that we have created an amazing digital infrastructure that, if compromised and its runtime and secrets stolen, could pose a massive impact to our world, economy, and the life we are slowly getting used to during a pandemic. For the attacker, this digital infrastructure also presents the means to accumulate extraordinary wealth via stolen secrets, intellectual property, holding assets in ransom or blackmail, or by sabotaging the prospects of an adversary, whether a competitor or nation.

Understanding the SolarWinds Attack and Application Privileges

Link copied

No vendor can legitimately claim that their solution would have outright prevented the attack on SolarWinds, and we should be wary of any such claims. With that said, organizations can take strategic steps to prevent this type of attack vector in the future—if they understand and address one of the fundamental problems of legacy infrastructure management. This core security problem is the need for any application to have unrestricted access to everything on the wire, or in privileged access management terms, global (or domain) shared administrator (or root) access.

What is global shared administrator access? It refers to when an account(s) has unrestricted access to an environment. This typically means security exceptions are made for it to operate unencumbered. For instance, the account may be allow-listed within application control software and excluded from antivirus software, so it is not blocked or flagged. The account is permitted to operate on behalf of a user, the system itself, or an application across any asset or resource within an environment. This type of access has been dubbed “god privileges” by many security professionals and introduces massive, unmitigable risk.

Global shared administrative access is typically used by legacy applications to monitor, manage, and automate on-premise technology. Global shared admin accounts exist in many tools we commonly find today on premise and operating within our environments, including network management solutions, vulnerability management solutions, asset discovery tools, and mobile device management solutions, to name a few.

The core issue is that these global administrative accounts are needed for the solution to operate correctly and, thus, they cannot operate using the concept of least privilege application management, which is a security best practice. If the accounts have privileges and permissions removed, the application will most likely fail. Thus, they are allowed full and unrestricted access to operate, which presents a massive attack surface.

In the case of SolarWinds, that is exactly what happened. The application itself was compromised via automatic updates and the threat actors leveraged unrestricted privileged access throughout the victims' environment using the application. The threat actors could perform virtually any task disguised as SolarWinds and even took great care not to execute on systems that had advanced vendor security monitoring and hardening present. Thus, one of our original premises has now come to light. If the malware is sophisticated enough to navigate around security solutions and only execute on targets where it can evade detection, it will do so using global shared administrative privileges. No single solution could have detected and blocked the attack.

Our annual cybersecurity predictions blog last year ranked the rise of malware auto-updates as our top prediction for 2020. So, while the general threat was not unknown or unexpected, the scale and devastation of this specific SolarWinds attack will resonate with us all for a long time.

How to Prevent or Mitigate Attacks Involving Legacy Applications

Link copied

The big question is: how can we modernize our environments and not be dependent upon applications and accounts that require excessively risky privileges?

To start, there is nothing wrong with many of these legacy applications, such as network management and vulnerability management solutions, based on scanning technology. The technology and security models needed to implement these applications are simply outdated. This is something we need to change.

If you think the SolarWinds breaches are the worst thing that has ever happened in cybersecurity, you may be right. For those cybersecurity professionals who remember Sasser, Blaster, Big Yellow, Mirai, and WannaCry, the volume of system impacts is comparable, but the mission of the threat actor and payload made those historical worms look trivial in comparison to the SolarWinds attack.

Serious threats have existed for decades, but never have we seen a resource exploited in this manner with an outcome so sophisticated in mission that all the potential targets, infections, and repercussions are still not known. When Sasser or WannaCry hit, you knew it. Even with ransomware, you know the impact within a short timeframe.

With the SolarWinds incident, staying under the radar was a primary goal of the threat actors. And please keep in mind, there is still that same fundamental problem with other legacy applications today. Many other applications with global shared administrative privileges could be leveraged in our environments to execute an attack across thousands of companies, with horrifying results. Unfortunately, this is not a patchable vulnerability—rather the exploitation uses the features within the application that need these privileges.

So, where do we start?

First we need to identify and discover all the applications in our environment that need these excessive privileges:

• Using an enterprise-grade discovery tool, determine which applications have the same privileged account on multiple systems. The credentials are most likely shared and can be leveraged for lateral movement.
• Inventory your Domain Administrators Group and identify any applications or service accounts present. Any application that needs Domain Administrative privileges presents a high risk.
• Review any applications that are in your antivirus global exclude list (compared to exclusions on specific hosts). These will operate under the first and most important step of your endpoint security stack – malware prevention.
• Review software inventory that is used throughout the enterprise and determine what privileges are needed for the application to operate and perform auto-updates. This can help determine if local administrative privileges are required or local administrative accounts are present for the application to correctly operate. For example, an impersonation account for application privilege elevation may have a local proxy account just for this purpose.

Next, we need to implement—whenever possible—least privilege application management. This entails removing all excessive application privileges. However, as we discussed, this may not be possible. Ultimately, to eliminate the need for global shared privileged accounts, you may need to:

• Upgrade the application to a newer version of the solution
• Select a new vendor to solve the problem
• Migrate the workload to the cloud or a different infrastructure

As an example, consider vulnerability management. Traditional vulnerability assessment scanners use a global shared privileged account (sometimes more than one) to remotely connect to a target and authenticate as an administrative account to identify vulnerabilities. If a host is compromised with memory-scraping malware, then the hash used for authentication can be scraped and leveraged for lateral movement and to establish a persistent presence.

Vulnerability management vendors recognized this problem and, in lieu of storing a persistent administrative account for scans, they integrate into Privileged Access Management (PAM) solutions to obtain a current privileged account to complete the scan job. When no PAM solution was available, vulnerability management vendors also mitigated the risk by developing local agents and tools that can use API’s for assessment in lieu of a single shared administrative credential for authenticated scans.

My point for this example is simple: legacy vulnerability management technology evolved so it no longer exposes customers to the enormous risk of global application accounts and access. Unfortunately, many other technology vendors have not evolved their solutions, and the threat remains until the legacy solutions are replaced or modernized.

If you have technology that requires these global shared administrator accounts to operate, a technology replacement or upgrade should be a primary concern for 2021. Make sure you are buying from those vendors who have already mitigated the threat or are being proactive with future deployments.

Finally, consider least privilege application management. Privileged access management solutions are designed to store secrets and allow applications to function with the minimal level of privileges, even if they were never designed to accommodate them in the first place.

Going back to our example, vulnerability management solutions can leverage Unix and Linux privilege management technology to execute vulnerability assessment scans, even if they were not granted privileged access natively. The privilege management tool executes commands on behalf of the scanner and returns the results. It honors least privilege for the scanner’s commands and denies anything the scanner might try when inappropriate, like a system shutdown. In some respects, least privilege on these platforms is similar to sudo and can control, restrict, and execute applications with privileges, regardless of the process calling the command. This is just one method that privileged access management can apply to some legacy applications in instances where excessive privileges are required and a suitable replacement is infeasible.

Mitigating Your Cyber Risk in 2021 & Beyond: Key Next Steps

Link copied

Any organization can be a threat actor’s target, and any application with excessive privileges can be leveraged against the entire company. The SolarWinds breach should be the impetus for us all to revisit and identify those applications which are operating with the risks of excessive privileged access. We need to determine how we can mitigate the threat, even if we cannot immediately eliminate it.

Ultimately, your risk mitigation and remediation efforts may lead you down the path to an application replacement or a shift to the cloud. One thing is certain, the concept of privileged access management applies to applications just as with people. If your applications are not adequately managed, they can jeopardize security for the entire business. And nothing should have unrestricted access across your entire environment. That is one weak link we should all identity, remove, and avoid in the future.