31–40 of 149 posts
(Ideally with some automated tooling, too.)
Interesting tidbit at the bottom ... > In an interesting turn of events, the investigation of the whole SolarWinds compromise led to the discovery of an additional malware that also affects the SolarWinds Orion product but has been determined to be likely unrelated to this compromise and used by a different threat actor.
This makes me think of a common refrain when dealing with parasite infestations: If you see one, there's way more than just one. Deterministic builds cannot come soon enough. And really, builds are not enough, we need to be able to extend confidence in the execution of the programs we write much deeper than just builds.
This doesn't do anything for people who buy SolarWinds Orion, which is a closed-source off-the-shelf tool that gets picked up everywhere because of a combination of good sales tactics, compliance checkboxes, and ability to remove work from all involved.
Going back up the chain, a technical solution probably won't solve the issues inside SolarWinds either. Systemic organizational issues lead to RCE backdoors and implants distributed on official update servers, signed with authentic keys.
Any 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…
That's just going to cause annoying false positives, and it's not that difficult to get around such detection. I'll bet the only result would be confused developers.
Earlier quoted context omitted.
That's just going to cause annoying false positives, and it's not that difficult to get around such detection. I'll bet the only result would be confused developers.
I presume it would be opt in, would make for a handy github action tbh
>In an interesting turn of events, the investigation of the whole SolarWinds compromise led to the discovery of an additional malware that also affects the SolarWinds Orion product but has been determined to be likely unrelated to this compromise and used by a different threat actor. Either that one was used to compromise the supply chain (in which case it makes little to no sense to keep it around and risk detection…
There are parts of the intelligence community that know with confidence who the true attacker is. Even if they had no idea they were being exploited, there are many ways to perform post-mortem analysis when you're, e.g., the NSA. So, someone has 100% confidence, or close to it.
In terms of what the media says: typically, they report on off-the-record remarks from officials and leaks. That's just how the game is played. It's an unfortunate byproduct of everyone wanting to tell, but nobody wanting to be caught telling. The value of Reuters and AP is that they typically do enough due diligence on their own sources to make sure that they're not just spouting nonsense. "Top of the food chain" sources like them are very regularly correct, but fallible.
I 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…
Assume compromise of the build machine. Start with, who builds the build machine, and how do they maintain it? Can humans get into it at all, such as in a break glass scenario?
Also, GitHub, GitLab, and the like, may not actually guarantee what you are relying on to enforce “the only way”.
Earlier quoted context omitted.
So you're saying that Russia's interests are entirely altrustic? That's quite a stretch. I don't think they hacked SolarWinds to "prove how insecure closed source, proprietary software is". Why don't they prove how "insecure" Kaspersky AV is, in that case? Seems strange to pick a software package that nobody's heard of, but happens to be used by thousands of juicy industrial espionage targets of their primary politic…
I have no idea what Russia's interests are. I'm just genuinely curious and in the dark. I've never been to the country and grew up in the West during the Cold War, so when I think of Russia I was indoctrinated to think of "the bad guys". The country is an enigma to me—very good at math but from what I read a corrupt place with rule by power and not law. So yeah, I'm just genuinely asking, how are they the ones doing…
Obviously, Russia has a policy to support whatever the US is angry about (SciHub, Snowden, ...). To paint these as altruistic is just silly - there is no chance on earth they would support Snowden if his leaks were about Russia rather than about the US.
To paint the SolarWinds hacking as "showing the world proprietary systems are dangerous" is intellectually dishonest at best.
You are not genuinely curious. You are not genuinely asking. You do not genuinely wonder if there is altruism involved.
GTFO with your doublespeak.
I would very much like to see prevention advice tacked on to analyses like these. It's very interesting to see how the vulnerabilities were exploited, but I think it would be extremely valuable to understand how to prevent future attacks such as this. What were the root causes of the vulnerability, and how can the community prevent similar ones from being created in the future? (Ideally with some automated tooling, t…
I 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…
The issue is that most developers view "the code pipeline" as a trusted and complete system, for the most part. In the vast majority of cases, that's okay. The issue is that SolarWinds should have known, based on their very own customer list, that they were in an advantageous position in many organizations that are valuable targets. That should have _caused_ all of this thinking to happen, and led to changes internally to accommodate the new risk. That threat modeling/analysis either didn't happen, or the outputs weren't good enough.
Earlier quoted context omitted.
The relevant code was (allegedly) not part of source control, but inserted during the build process.
Hmm, interesting. I'm confused if that's how I should read this. You might be right. I assume you're referring to this paragraph? > Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes. Therefore, insertion of malicious code into the SolarWinds.Orion.Core.BusinessLayer.dll likely occurred at an early stage, before the final stages of t…
1. Source code as available on development machines and version control
2. Source code as available on build machines
3. .dll generated by build machines
I would assume (based on the article's language that you quoted) that manipulation happened on (2), not (1) or (3).