Solarwinds is Hacked
Easily the biggest security news in the last several years, we would have to turn in our security membership cards if we didn’t discuss it. Closing out an otherwise uneventful 2020, news broke that the vendor Solarwinds was hacked by what appears to be a Russian hacking group. Beginning in March 2020, this hack introduced malicious code into the Solarwinds source code thereby affecting not only Solarwinds but, to Solarwinds’ delight, all of its clients. When Solarwinds’ customers upgraded to the latest versions of the application, the malicious code was installed as part of the upgrade.
To date, it is believed that nearly 18,000 customers, including large businesses and federal agencies, were affected. Any companies using Solarwinds software should immediately review Solarwinds' security advisory to verify whether their product or software version is affected by this attack. Any companies using third party IT services should ask what Solarwinds products and versions are being used and how the service provider is investigating the impact of the attack. Ironically, some of our clients are actually so far behind on updating Solarwinds that they aren’t affected (missing software update management for the win!).
The malicious code, now being called Sunburst and Supernova, allowed the hackers to sit undetected within target networks and systems, while they patiently collected user credentials and proprietary data and information. While it is still unknown the full extent of this attack, Microsoft has reported that hackers were able to view source code in various internal Microsoft repositories.
For more details see:
The Takeaway: For Solarwinds and the federal government, this attack was a clear example of the capabilities of nation state hackers and the need for constant security vigilance in all parts of an organization. For smaller companies and teams, carefully auditing every vendor update is unmanageable and untenable. Instead, use this attack to reinforce the need for basic security principles such as Least Privilege and Defense in Depth.
Security Best Practices - Least Privilege
You had one job! Just the one! -- Loki
The principle of Least Privilege dictates that every user, system, and entity within the environment should have the minimum privileges necessary for its role or function. While a common sense principle in theory, it can be devilishly difficult to implement successfully. Humans, even those working in security, have a tendency to take the lazy approach and it is far easier to simply “run as administrator” when hitting a permissions issue than to diagnose why the issue occurred in the first place.
Why is it important?
In the case of the Solarwinds attack, malicious code was able to run with the permissions of the Solarwinds software. Thus, hackers now had access to every system, file, or resource that Solarwinds could access. Furthermore, once the malicious code was able to capture user credentials via the network or misconfigurations on the server itself, the hackers had full access to anything those users had permissions to.
While it doesn’t prevent accounts from being compromised or data from being stolen, this principle ensures that the impact of the attack is the smallest possible.
Security Best Practices - Defense in Depth
I wish he didn’t trust me so much. I think he really trusts me too much. -- Bobby Womack
To actually prevent the attack, or as much of the attack as possible, companies should utilize a defense in depth strategy. For those playing cybersecurity Bingo this week, this principle is sometimes also called a “zero trust approach” or an “assumed breach model”. In this approach, we assume that the external defenses will be breached or otherwise bypassed. Thus, we adopt the defensive mindset of how to detect and prevent an attacker who already has insider access.
Why is it important?
In today’s world of phishing emails and social engineering, it is easy to imagine the scenario of a hacker with insider access. When (not “if”) an employee falls for a phishing email and submits their credentials, the hacker now has insider access. Best case scenario, they realize their mistake and notify security, who can then reset the password and investigate the account activity. But with a defense in depth model, we never assume the best case scenario. As proactive defenders, we want to detect and respond to this breach whether or not the user notifies us. In this scenario, we can look at anomalous logins (why is Tim from New Jersey logging in from North Korea?), anomalous user activity (why is Jimmy from finance opening powershell?), or spikes in permission errors (why is Beth from accounting trying to access the IT department’s file share?).