Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Analyzing the compromised DLL file that started the Solorigate attack

microsoft.com

Post reply on HN
Print view View original

51–60 of 149 posts

Re: Analyzing the compromised DLL file that started the Solorigate attack

#51

Post by codenesium »

raverbashing wrote: post #16
bob1029 wrote: post #4

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…

I'd be even more curious to know why people saw that code and thought nothing of it. No git blame? No bugs around that area? No one questioning what/how/why is that there?

They likely put a program on the build server to make the changes after checkout before build. Which would be impossible to detect.

Re: Analyzing the compromised DLL file that started the Solorigate attack

#52

Post by raverbashing »

codenesium wrote: post #51
raverbashing wrote: post #16

Earlier quoted context omitted.

I'd be even more curious to know why people saw that code and thought nothing of it. No git blame? No bugs around that area? No one questioning what/how/why is that there?

They likely put a program on the build server to make the changes after checkout before build. Which would be impossible to detect.

"impossible to detect" except for all the merge conflicts and build breaking changes, etc

Re: Analyzing the compromised DLL file that started the Solorigate attack

#53

Post by meowface »

cogs wrote: post #49
DethNinja wrote: post #18

Earlier quoted context omitted.

I assume huge percentage of this site is IT professionals and software engineers. I’ll have to ask then, what proof is there that Russia did this hack? Do you realise how hard it is to track professional hackers? You will have to trace the entire network commands up to a source and hope that it is registered under their name. I genuinely cannot believe people here think that government managed to find the source of t…

Attribution is not from tracing connections or domain ownership, it's from looking at the coding style, the "Tactics, Techniques and Procedures" and the choice of targets.

It's a complex combination of all of those things, in addition to more "offensive" type intelligence collection (spying on GRU/SVR buildings, communications, and officers, essentially, and compromising their infrastructure).

You might be surprised about how even the world's top intelligence agencies sometimes do make simple mistakes with domain and network registration which really are just genuine fuckups rather than false flag subterfuge. This is very rarely a matter of something silly like "Russian IP = Russian intelligence" and more like sloppily re-using an ostensibly non-attributable network or nameserver they didn't realize was already burned.

We're still kind of in the infancy of cyberwarfare. Attribution will probably be harder in a few decades.

But, yes, it's generally a matter of TTPs, target selection, goal analysis, and style.

Re: Analyzing the compromised DLL file that started the Solorigate attack

#54

Post by robocat »

meowface wrote: post #45
jeffbee wrote: post #38

Earlier quoted context omitted.

The root cause? It's that people buy snake oil from vendors to check boxes on meaningless compliance tests.

It can affect non-snake oil from good vendors who provide useful solutions for meaningful compliance tests, too, though. Or just any popular B2B software provider. If one of the big 3 superpowers really wants to backdoor your product, then even a top-notch company might fall victim. Hopefully this increased awareness will make it harder to pull off these subtle compromises without it getting caught sooner, though.

Google banned Windows machines from their workforce a decade ago (due to getting hacked by the Chinese).

Has Google relaxed that ban in any way? I.e. does Google believe that Windows 10 is now secure?

What other major corporations or government departments have followed Google’s example since 2010?

Re: Analyzing the compromised DLL file that started the Solorigate attack

#55

Post by vsareto »

raverbashing wrote: post #52
codenesium wrote: post #51

Earlier quoted context omitted.

They likely put a program on the build server to make the changes after checkout before build. Which would be impossible to detect.

"impossible to detect" except for all the merge conflicts and build breaking changes, etc

Huh? After the build server checks out the code, write malicious code to the source files directly just before the compilation step. No merge conflicts or breaking changes unless the added code failed to compile. It's reasonable to guess they had access to the source from the build server, so they could reproduce this environment themselves and test on their own.

Re: Analyzing the compromised DLL file that started the Solorigate attack

#56

Post by rossjudson »

bob1029 wrote: post #4

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 system to notice if a new compiler binary is being built. If so, inject code that, from then on, invisibly "injects the injector". Once you've shifted to this new compiler, the compiler binary itself is the attacker.

Since you have an injector, you can put other types of detections and alterations in...like watching for the compilation of the initialization of a Solarwinds DLL. Then you inject in what you need. No source code is involved.

There are probably lots of ways of getting around this, but unless you're actually looking for it, you won't see it.

Re: Analyzing the compromised DLL file that started the Solorigate attack

#57

Post by woodruffw »

mehrdadn wrote: post #10

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…

I'm not a GitHub employee, but this is probably something that could be (either today or with some changes) via secret scanning[1].

[1]: https://docs.github.com/en/free-pro-team@latest/github/admin...

Re: Analyzing the compromised DLL file that started the Solorigate attack

#58

Post by netsharc »

Shank wrote: post #35
smspf wrote: post #22

>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…

> 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…

But media can just add ", person X says" at the end of a sentence and then the burden of proof is no longer with them. They can report that "Obama is born in Kenya, President Trump claims" and, hey, they're reporting the true fact that Trump claimed something...

Re: Analyzing the compromised DLL file that started the Solorigate attack

#59

Post by yread »

meowface wrote: post #53
cogs wrote: post #49

Earlier quoted context omitted.

Attribution is not from tracing connections or domain ownership, it's from looking at the coding style, the "Tactics, Techniques and Procedures" and the choice of targets.

It's a complex combination of all of those things, in addition to more "offensive" type intelligence collection (spying on GRU/SVR buildings, communications, and officers, essentially, and compromising their infrastructure). You might be surprised about how even the world's top intelligence agencies sometimes do make simple mistakes with domain and network registration which really are just genuine fuckups rather tha…

You can see it in Bellingcat's investigations - carelessly reusing burners, calling from GRU offices, reusing passports, calling from two burners one immediately following the other.

Re: Analyzing the compromised DLL file that started the Solorigate attack

#60

Post by toast0 »

Shank wrote: post #32
infogulch wrote: post #29

Earlier quoted context omitted.

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.

> Deterministic builds cannot come soon enough. 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 organ…

Deterministic builds can be done with closed source too. It doesn't directly help the users, but if they had setup a second build machine and noticed the build output was different, they could have addressed this sooner.

Of course, if following best practices, all build machines should be equally compromised. ;p

Post reply on HN