Background
Solarwinds is a major network monitoring and SEIM product that is used by who’s who in every industry. They have a very prestigious clientele that includes many government agencies and leading enterprises.
What happened
In the 3rd week of December Solarwinds issued an urgent advisory for many versions of their primary ORION platform which allows an adversary to compromise the target SolarWinds server and acquire privileged access. Per SEC filings up to 18000 high-profile entities were impacted.
What went wrong
Leading cybersecurity firm FireEye named the exploit SunBurst. It was classified as a global intrusion campaign (UNC2452), and determined as a result of “Trojanized updates to SolarWind’s Orion Network”. The adversaries were able to hack the update server of SolarWinds and push malicious updates to all clients.
SolarWinds.Orion.Core.BusinessLayer.dll
Microsoft named it Soloriagate which was caused by the adversary uploading a compromised library to update the server. It is also being talked about that the said update server maintained a default password solawinds123.
“Very sophisticated attack”
This was as bad as a possible scenario which was started with an innocent but costly mistake of not resetting default passwords and leading to The Cybersecurity and Infrastructure Security Agency (CISA) issuing a rare Emergency Directive to patch the servers immediately.
Learnings
The fact that the wicked file was delivered digitally signed implies that the adversaries were able to compromise the company’s DevOps pipelines.
Although there were quite a few misses in this saga starting with password mismanagement to unsupervised updates, to failure to detect intrusion. It was just a perfect storm of combinations that led the situation to be this grave.
PS: Update: It seems the infection and the repercussions are worse than originally anticipated
While there will be long term consequences of this exploit. The very first thing we have to do is to tie this back to the culture of DevSecOps, namely the following:
1. Left-Shift of Security
Left-Shift left is the method of detecting and resolving a bug/issue to an earlier stage in the release cycle. Shifting security to the left ensures that security standards are met from the start when the design is being developed. Do not create a product and then think about meeting SOC-II, keep security in mind from start.
2. Feedback Loop
An example like OODA Loop ensures a continuous feedback loop for making all parties accountable for any incident that may occur and easy remediation in case of an exploit.
3. Automated Security
Having as much process to automatically monitor, systems for threats and provides real-time alerts( not a plethora of false positives). All teams can then easily collaborate. Also, In the future only allow authorized updates to flow.
The attack will let us have a better understanding of the reliability of our security controls and learning that we can be compromised even while doing everything by the book. We just have to be a step ahead of the adversary all the time.
