Analyzing the compromised DLL file that started the Solorigate attack
1–10 of 149 posts
Re: Analyzing the compromised DLL file that started the Solorigate attack
#2This method is part of a class, which the attackers named OrionImprovementBusinessLayer to blend in with the rest of the code
Chuckled at this one.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#3Did SolarWinds' CA (certificate authority) reworked their code signing certificate?
Re: Analyzing the compromised DLL file that started the Solorigate attack
#4I am curious how this code actually made it in, based upon the following:
> The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline. Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes.
Unless this a compromise of the build machine, it sounds suspiciously like a lack of code review standards to me.
In our organization, the only way to get a line of code into master is through a process where a 2nd developer reviews and approves via GitHub. Branch protection rules are really nice for this kind of concern. Obviously, the attacker can hit right after cloning source, but it helps to know your foundations are clean regardless.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#5I am curious how this code actually made it in, based upon the following: > The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline. Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes. Unless this a compromise of the build machine, i…
If we're at the level where we think it's an inside job, it doesn't seem that difficult to have 2 people on the inside "reviewing" each other's malicious commits.
For what it's worth, my org also has the same policy, but it's intended to catch mistakes, not to protect against malicious actors inside the company.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#6I am curious how this code actually made it in, based upon the following: > The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline. Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes. Unless this a compromise of the build machine, i…
It's not hard to envision code reviews that don't review every single line. Been on both sides of it. Code review isn't a security barrier, it's a (noisy) safety check. It can't even catch every silly bug, let alone deliberate covert sabotage.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#7> To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encoded in Base64, or their hashes are used instead.
ah so base64 is valid encryption after all.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#8Anyone else find it ironic that the country that is responsible for democratizing access to scientific research (via support of SciHub), the country protecting a whistleblower against government overreach (Snowden), the country pointing out how fundamentally insecure closed source, proprietary software is (SolarWinds), is...Russia?
How did we get here?
Re: Analyzing the compromised DLL file that started the Solorigate attack
#9I am curious how this code actually made it in, based upon the following: > The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline. Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes. Unless this a compromise of the build machine, i…
Spoken like a true dev There are other ways of checking code in besides the official channel. Almost every company on the planet could fall victim to this type of attack. Once a team gets past a certain size and “its not my job” comes into play. All kinds of doors swing open.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#10Any GitHub/GitLab/etc. employees here? I think you might be able to help mitigate some of these kinds of attacks:
> To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encoded in Base64, or their hashes are used instead.
There needs to be a quick tool that flags strings that appear to represent binary data before a merge, maybe even decoding them when possible and providing hints of what they might represent, especially inside source-code files. These shouldn't be common in checked code. And we should figure out a way to whitelist them in the repo that's both safe and convenient (I'm not sure how).
Is this a feature code-hosting sites like GitHub can add?