Listen to this Post
Analysis of how to detect and prevent such attacks in the future
In the modern tech ecosystem, we are dependent on a significant number of software and hardware providers. With every additional link in the chain comes the risk that a weak segment can be exploited and compromise the rest of the network.
The risks inherent in the supply chain were highlighted spectacularly this month as news that hackers had compromised the update server for SolarWinds, a software vendor that is used by an exceedingly large proportion of the public and private sectors. Microsoft, the US Treasury Department, and even security firm FireEye were among the targets of the hack that experts believe began in March of this year.
While information regarding any damage through theft or other malfeasance is still dripping out slowly — and will likely take many months to account for — we are already learning significant details about how the actors undercut serious security measures to reach their target.
In the process, they may have struck a bigger win by undermining trust in our ability to defend ourselves from attacks.
What We Know About The Breach
So far, we know that this was a supply chain attack that took advantage of user trust in the underlying update system. It allowed the attackers to sneak in like a wolf in sheep’s clothing, undetected as it entered through a trusted point of entry.
Supply chain attacks have been a concern for some time now, with the National Institute of Standards and Technology (NIST) publishing their report on Supply Chain Risk Management Practices for Federal Information Systems and Organizations (NIST SP 800-161) back in 2015.
Reading accounts of the breach in recent days, it is clear that this was a masterclass in how to subvert the strongest of protections.
According to a write up issued by the National Security Agency (NSA), the attackers succeeded to “compromise on-premises components of a federated SSO infrastructure and steal the credential or private key that is used to sign Security Assertion Markup Language (SAML) tokens. Using the private keys, the actors then forge[d] trusted authentication tokens to access cloud resources.”
In short, the attackers ran circles around the multi-factor authentication (MFA) protections, essentially making their own authentication tokens that gave them access to continue with their intrusion.
Next, the hackers impersonated one of the global administrator accounts to assign credentials to cloud applications identities that granted them access to additional cloud resources. They then leveraged the application’s credentials for automated access to cloud resources that would otherwise be difficult for them to access without raising suspicions that something untoward was underway.
Once they were able to take over the compromised accounts, they took advantage of the wide-reaching access that the account had to move freely without restriction.
What Went Wrong?
By all accounts, according to the NSA and plenty of other smart folks, the protective systems that the affected organizations had in place worked as they should. There were a number of known vulnerabilities that SolarWinds should have patched when the CVEs were published, but the issues run deeper than serious bugs going unaddressed.
The problem is that while the defenders were playing a good game, the attackers came and flipped the board over.
In his reporting for ArsTechnica, Dan Goodin explains that the hackers compromised a server running Outlook Web App (OWA), which helped them steal the secret token and bypass the Duo MFA.
Even as this was a bit of bad luck for Duo, Goodin is quick to point out that:
“While the MFA provider in this case was Duo, it just as easily could have involved any of its competitors. MFA threat modeling generally doesn’t include a complete system compromise of an OWA server. The level of access the hacker achieved was enough to neuter just about any defense.”
Goodin puts his finger on the issue quite well, highlighting the fact that with enough privilege to access the necessary resources, no level of authentication verification will be enough to stop a talented hacker from reaching their end goal. Especially if they are willing and able to break your security infrastructure from its foundation.
Think about it like this.
If you want to protect your bicycle, then you buy a good lock. It probably doesn’t occur to you that a determined thief might come along and steal the whole bike rack.
Taking a step back, we know that statistically in most hacks we are unlikely to see an adversary go to these kinds of lengths, so we are unlikely to see a situation of this level again anytime soon.
However, there are a number of valuable lessons that we can take from this incident to better prepare for the future.
The attackers’ success in breaking through the authentication layer of defense highlights the necessity of multiple layers of defenses.
If authentication is the first line of defense to determine that an identity is who they say that they are, then Authomize’s capability to govern the actual entitlements is the last mile solution that enables organizations to set, monitor, and enforce their permissions policies.
Authomize achieves visibility over all an organization’s identities, resources, and permissions, analyzing the relationship between all of the assets down to the most granular and continuously updating the picture based on provisioning de-facto changes happening in your apps. Whereas many tools in this space look to simply emulate permissions from one identity to the next based on the idea that one appears to be “alike” to another, Authomize sees the big picture and offers powerful recommendations for much more accurate permission provisions. This means understanding which identities require which resources based on an analysis of the organization, allowing IT teams to grant access that both complies with a least privilege approach while offering suggestions for additional privileges that the identity is entitled to and needs in order to do their job.
A key component of Authomize’s approach is in identifying how an identity is supposed to behave. While administrators can set guardrails for policies that govern what an identity is permitted to do, Authomize can also play a key role in monitoring and alerting on suspicious behavior. In the case of the SolarWinds hack, having the ability to receive an alert that an important identity is acting out of character could have helped to raise a red flag at the time of the intrusion.
Looking at the Attack Graph as provided by Microsoft, we can see how the attackers were able to compromise the authentication layer in the on-premises environment before impersonating the admin and forging the SAML token.
This visualization shows us how they likely were able to escalate their privileges and gain access to the target resources.
By contrast, Authomize would have prevented this attack from being successful. At the point where the attackers would have attempted to forge the SAML token for the cloud administrator, Authomize would have identified that this was not an action within the purview of the role. Authomize would have then alerted the organization or even prevented the forging outright if such a policy had been set.
Furthermore, Authomize can and will alert on any new privileged identity such as a cloud admin, changes in app permissions and new trust relationships. These measures would have effectively blocked all key paths that attackers could have taken to compromise assets inside the target apps.
Admittedly, attackers could have taken a different path to avoid Authomize’s defenses by using existing identities, but that would have made them much more likely to be caught by various behavior analytics solutions and Authomize’s relevant capabilities. Going this route would have taken the attackers much more work to compromise the same amount of assets, thus mitigating the vast majority of threat vectors and giving the defenders a leg up.
In their reports following the publication of this breach, the Cybersecurity and Infrastructure Security Agency (CISA) and Microsoft issued their recommendations for organizations to prevent future incidents of this sort.
These include using solutions such as Authomize that can:
- Detect and monitor if administrative privileges have been granted and to whom
- Detect when privileges are granted to service accounts\application
- Regulate excessive service account\application activities across granted privileges
- Historically determine whether such an event has occurred, creating actionable logs
- Regulate token usage (tokens provided vs tokens used) and prevent Golden SAML attacks and similar token attacks
With these capabilities, organizations can better protect themselves from attempts to escalate privileges should they make it past the outer defenses, alerting to dangers and mitigating risk.
Practice Defense in Depth
One might have thought that we might have taken greater precautions against supply chain attacks following the NotPetya attack in 2017 that compromised a Ukrainian accounting software updating server, causing untold billions in damages. But given the reliance on key vendors in the market, we should not be that surprised when a key player like SolarWinds gets compromised and puts others at risk. If it wasn’t SolarWinds, then it might’ve been someone else.
In his 2006 post, Bruce Schneirer wrote about the importance of building systems that can fail gracefully. This means that when an adversary breaks through one layer of our defenses, what are the other layers that we have in place to mean that the loss of the defeated security measures don’t bring the whole house down?
Nothing is ever truly unhackable. Saying otherwise is asking for trouble. The question is when a breach occurs, how do we plan for our systems to fail gracefully increase our chances to catch attackers that went past the first line of defense as well as minimize the impact of an attack?