131–140 of 149 posts
Earlier quoted context omitted.
That's just fancy technical terms to justify the propaganda. If these kinds of "hard proof" which definitively link hacks to nation state actors exist, why are they never publically revealed?
> why are they never publically revealed? To protect the source(s)?
Earlier quoted context omitted.
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…
SolarWinds themselves it claiming it. https://www.solarwinds.com/securityadvisory/faq > Our initial investigations point to an issue in the Orion software build system in which the vulnerability was insert which, if present and activated, could potentially allow an attacker to compromise the server on which the Orion Platform products run. Under "With these processes in place how was your code compromised?"
Earlier quoted context omitted.
> Funny how media coverage of this issue misses no chance of mentioning Russia and nobody else, not even possible suspects. 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…
Don't forget the "intelligence" community is paid to find Russian spooks hiding everywhere. The 2014 JP Morgan hack was blamed on Russian state backed hackers[1]. We know now that was pure speculation and not NSA inside knowledge, since some time later a small criminal gang were successfully prosecuted for it. Apparently they were running a pump-n-dump scheme. 1. https://eu.usatoday.com/story/tech/2014/08/28/russia-j…
> small criminal gang
They're the same picture.
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…
All you need is to be able to influence the behavior of the build system at runtime. If you have that, you do not need access to the source code, and you do not need to check anything in. This includes scenarios where the tool chain itself is checked into the source control system. Ken Thompson described this a long time ago: https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html At runtime, you alter the build sys…
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.
Is anyone ever pissed that one exploit getting caught reveals other hacker’s efforts? Like how that amateurish but high profile Wannacry attack revealed a much more lucrative Monero mining botnet that was running with the same exploit for weeks longer, but some script kiddie ruined it
It wasn't one of those "healing viruses" either; it was exploiting a weakness and preventing others from doing the same.
Earlier quoted context omitted.
> Funny how media coverage of this issue misses no chance of mentioning Russia and nobody else, not even possible suspects. 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…
> 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. This isn't how the game is supposed to be played and is a symptom of the erosion of the media's journalistic integrity. Anonymous sources can tell you where the bodies are buried, but you still need to dig up the bodies. One would think if you're going through all the troub…
"Finally, the backdoor composes a JSON document into which it adds the unique user ID described earlier, a session ID, and a set of other non-relevant data fields. It then sends this JSON document to the C2 server." Is there any further explanation of how this was achieved? One might expect as "par for the course" that all external connections be blocked aside from explicitly designated ranges. I would expect that an…
Earlier quoted context omitted.
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.
It’s too obvious even for a huge app. The empty catch alone is something I’d immediately “git blame” if I saw it. I work on a 20 year old massive enterprise app and there is lots of “not my job”, but someone would see it. Also, it would likely (or hopefully) trigger a static analysis warning in the build as soon as it’s added. For such a sophisticated attack this would be too much of a weak point. It would be much be…
An automated tool might have more of a chance, but again it’s kinda hard to have one that runs on binaries. If it runs after build, it’s typically some input/output checker, which would not detect code like this.
It’s a hard problem and I think it has just demonstrated that the security of build-related infrastructure should be taken more seriously than it currently is.
Earlier quoted context omitted.
It’s too obvious even for a huge app. The empty catch alone is something I’d immediately “git blame” if I saw it. I work on a 20 year old massive enterprise app and there is lots of “not my job”, but someone would see it. Also, it would likely (or hopefully) trigger a static analysis warning in the build as soon as it’s added. For such a sophisticated attack this would be too much of a weak point. It would be much be…
The issue here is that the code was added at build time . Do you do code-reviews after decompiling build output ? If you’re a sane person, probably not - so you’d fall for this too. An automated tool might have more of a chance, but again it’s kinda hard to have one that runs on binaries. If it runs after build, it’s typically some input/output checker, which would not detect code like this. It’s a hard problem and I…
Even if I did have source write access, rather than adding the poison to the runnable code, I’d add the poison to code run at build time (a unit test) which modified the build tool chain and then removed all traces of the poison code again.
Earlier quoted context omitted.
All you need is to be able to influence the behavior of the build system at runtime. If you have that, you do not need access to the source code, and you do not need to check anything in. This includes scenarios where the tool chain itself is checked into the source control system. Ken Thompson described this a long time ago: https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html At runtime, you alter the build sys…
This is really interesting - really seems to be an argument in favor of all code being open, shared source - along with deterministic builds, it would be easy enough for any organization to build Orion themselves and verify they get the correct build hash. Or if there was a disagreement in hashes between SolarWinds and their imagined community, it would serve as a red flag.
Carefully compiling a corrupted program doesn't fix it.