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

41–50 of 149 posts

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

#41

Post by mehrdadn »

ThePadawan wrote: post #40
mehrdadn wrote: post #28

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…

I was also thinking of manipulating source code. Let's say there are multiple stages: 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).

Oh interesting. So that would mean it would depend on a compromised build machine. Yeah, that would make sense, and I guess you couldn't prevent it like this in that case. Thanks!

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

#42

Post by newhouseb »

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…

Solarwinds accidentally leaked (via Github) the FTP credentials to the infrastructure used to distribute builds in late 2019 [1].

I'd be curious to see if the digitally signed bad versions are similar to digitally signed good versions, i.e. if there's any chance the attacker found/developed a hash collision against an otherwise legitimate build. AIUI it'd be a pretty big deal since it would point to a vulnerability in SHA-256 (which is usually how Windows binaries are signed), but this is apparently a nation state we're dealing with? ¯\_(ツ)_/¯

[1] https://twitter.com/vinodsparrow/status/1338431183588188160/...

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

#43

Post by breck »

efdee wrote: post #37
breck wrote: post #15

Earlier quoted context omitted.

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…

This comment, along with the original comment of the same person, is laughable at best and downright Russian astroturfing in a less favorable reading. 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 So…

Big words coming from an anonymous coward.

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

#44

Post by roywiggins »

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…

The secretary of state has said as much, and pointed at Russia. Sure, he could be lying, but given the president's reflexive defense of Russia, that would be a weird lie to go with. If anything, it's an admission against interest, which strongly suggests to me that this is the assessment of the relevant security agencies.

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

#45

Post by meowface »

jeffbee wrote: post #38
otterley wrote: post #31

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…

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.

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

#46

Post by [deleted] »

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…

[deleted]

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

#47

Post by mrtesthah »

otterley wrote: post #31

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…

1. Don’t outsource 18,000 organizations’ security to the same vendor.

2. Don’t homogenize all the platforms.

3. Reproducible builds; in all likelihood the build server was compromised.

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

#48

Post by Threeve303 »

ThePadawan wrote: post #27
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…

The relevant code was (allegedly) not part of source control, but inserted during the build process.

If it was standard to compare a dependency graph of the program architecture pre and post build, then you would catch these sorts of things right away. Supply chain attacks are not new and I imagine at least some companies have a process like this in place already.

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

#49

Post by cogs »

DethNinja wrote: post #18
breck wrote: post #8

Anyone 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?

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.

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

#50

Post by ThePadawan »

Threeve303 wrote: post #48
ThePadawan wrote: post #27

Earlier quoted context omitted.

The relevant code was (allegedly) not part of source control, but inserted during the build process.

If it was standard to compare a dependency graph of the program architecture pre and post build, then you would catch these sorts of things right away. Supply chain attacks are not new and I imagine at least some companies have a process like this in place already.

What do you mean by "dependency graph" here?

Seems to me like this malware might as well have been added to the calling assembly.

Post reply on HN