What We Know (And Don’t) About The SolarWinds Orion Hack So Far
FireEye made the news last week for responsibly disclosing an incident to the public in which they themselves were the victim. We wrote up an informational piece about what, exactly, was exposed to attackers in the “red team tools” drop, as it was dubbed in the press.
There’s so much information (and misinformation) floating around in the headlines and online within the security community that we wanted to pull together what information has been confirmed and discuss how it could impact businesses going forward. In this post, we’re going to dive into the SolarWinds side of the story, which is the latest news that was released yesterday.
The FireEye breach in the headlines last week was attributed to their third-party software vendor, called SolarWinds, specifically their Orion platform software. Malware was distributed along with ordinary Orion software updates, and actively exploited by some malicious party. That much we know, but we’re firmly within the fog of war on this hack, and it seems like a big deal.
- What else do we know about the hack?
- How do we know it?
- What do we still not know?
SOLARWINDS ORION
If you’re not a professional IT system administrator, you might have never heard of the Orion platform, from company SolarWinds. It’s an IT management stack that describes itself in terms of the “One Ring” from the Lord of the Rings:
In retrospect, this metaphor is more telling than it was meant to be. Orion is a highly privileged piece of software that has wide-ranging capability to do most anything on a network. It’s the thing that sysadmins at big organizations use to actually implement changes, get visibility, etc… And just like the One Ring, its influence was twisted by malice. Exploiting this component can give an attacker extremely privileged access into an organization’s internal (almost surely Windows domain) network.
WHO WAS COMPROMISED?
Part of why this is such a big deal is because of who Orion users are. Exploits that affect big businesses come and go all the time, but this one seems different. Users of the Orion platform include a lot of U.S. government agencies: All five branches of the U.S. Military, The U.S. Pentagon, State Department, NASA, NSA, Postal Service, NOAA, Department of Justice, and the Office of the President of the United States.
This according to SolarWinds’ own website:
This customer list has since been replaced by a pug wearing a track suit, but public information indicates that around 18 thousand customers out of their over 30 thousand userbase were expected to have been impacted.
The Orion platform isn’t the sort of thing that some small tech startup uses. It’s meant for large organizations. Targeting it is a bit like targeting the software that runs a Rolls-Royce: there is clearly an intended kind of target behind it and that lets you know something about the attacker.
WAS THIS A NATION-STATE ATTACK? HIGHLY LIKELY.
We don’t know for sure, but it seems highly likely. When these sorts of big hacks come out, there’s usually a chorus of people in the Twitterverse opining that it was so sophisticated that it simply must have been a nation-state actor. And most of the time, it turns out to be a college student just messing around. I’m usually a dissenter to the knee-jerk reactions on calling hacks necessarily a nation-state, so why is this different?
It really comes down to motivation and methodology, not so much “sophistication level.” Any cool hack can look really amazing and sophisticated if you phrase it just the right way, and this one has some of that. The attackers disguised themselves using an existing communication mechanism called the Orion Improvement Program (OIP) protocol, used all-custom software and not just existing malware tools, and make custom forged SAML credentials. All of that is somewhat impressive, but it’s about the level of capability you get from a good pen test. It doesn’t inherently indicate a nation-state in the way that the Flame spyware’s MD5 0-day collision attack did.
The thing that screams “nation-state” to me here is the fact that seemingly no targets were hit with any financial threats, such as a CryptoLocker, and the targets have such a political value. Whoever did this sure didn’t seem to be in it for the money, and it was just too sophisticated and professional to be a casual college student just messing around. FireEye says that the initial indicators of compromise came around Spring of 2020, and the attackers took their time slowly and manually going about lateral movement. That’s not the sort of thing you see from a smart teenager with a penchant for troublemaking; it’s a coordinated team without a profit-motive.
Though when talking about nation-state actors, the first jump is immediately to Russia. It would make some geopolitical sense for it to be Russia, after all. There’s even some reporting out there that states as fact that the hack came from a Russian APT group. This may or may not wind up being true, but isn’t known at this time. Russian officials appear to be denying attribution, but… that’s not worth very much. Even so, I would be cautious before jumping to a Russian attribution just yet.
COULD AN EXPOSED FTP PASSWORD BE THE CULPRIT? VERY UNLIKELY.
There is some reporting that an exposed FTP password might have been the initial entrypoint into the SolarWinds systems. It’s true that this vulnerability did seem to exist back in 2019, so it’s possible, but personally I don’t buy it.
In particular, FireEye made it very clear that the malware present inside the Orion packages were legitimately digitally signed by SolarWinds. This means that the attacker almost surely had some level of access into their buildchain systems, where the signing would happen. The FTP account referenced would only have let someone upload a file to the Akami CDN, but not digitally sign it. I suppose it’s possible that there was some automatic system that would digitally sign any file as it was uploaded to the CDN, but that seems far-fetched.
Additionally, the timelines don’t match. The FTP password was apparently fixed in November of 2019, while new malicious Orion software files were uploaded as late as March 2020.
Perhaps we’ll learn more information in the coming days about the nature of the initial compromise into the SolarWinds system, but it smells to me like someone snuck code into an internal repo. Spearphishing a developer would be a much more plausible explanation (and much more in a nation-state’s M.O.) but we’ll have to wait and see.
WHAT IS THE LESSON I SHOULD BE LEARNING FROM THIS?
I suspect that we might wind up putting greater scrutiny into 3rd party providers of proprietary systems that are critical to business. But it’s not clear that anything especially negligent happened on the SolarWinds side. So, I don’t know what that scrutiny would look like. Perhaps we’ll learn more about this if and when more information about the initial intrusion vector is discovered and disclosed. Right now, it’d be easy to just point the finger at a single cause or vendor, but there really isn’t enough evidence to back that up at this point.
Big takeaways are elusive here. What should a SolarWinds customer have done differently? Not apply updates? That’s not great. Inspect software updates? They were digitally signed and sent over the official mechanism. So, if you’re left feeling helpless and unsure about what to do, that’s probably normal. Until we know more about what went wrong, it’s hard to draw the right conclusion about what to do about it for next time.
Subscribe to Bishop Fox's Security Blog
Be first to learn about latest tools, advisories, and findings.
Thank You! You have been subscribed.
Recommended Posts
You might be interested in these related posts.
Sep 17, 2024
Navigating DORA Compliance: A Comprehensive Approach to Threat-Led Penetration Testing
Aug 28, 2024
Offensive Security Under the EU Digital Operational Resilience Act (DORA)
Aug 13, 2024
Manipulating the Mind: The Strategy and Practice of Social Engineering
Aug 01, 2024
Adversarial Controls Testing: A Step to Cybersecurity Resilience