Analyzing the compromised DLL file that started the Solorigate attack • Hacker News Board

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

#111

Post by dboreham » Sun, Dec 20, 2020, 1:01 AM UTC

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 offer up a glass of kool aid if you believe this works. Employee A is just going to DM slack Employee B asking them to approve their 7000 like PR because they're going on vacation next week and Employee C has been slow reviewing.

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

#112

Post by jjk166 » Sun, Dec 20, 2020, 1:01 AM UTC

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…

> 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 trouble to track down three different sources who are both competent and trustworthy to comment on who the government suspects, that you'd take the opportunity to ask a follow up question like "why do you think it was them?" Yeah, everyone wants to be the first to break a story, and real investigation is a lot harder than tabloid journalism, but that's the job, or at least that's what it used to be.

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

#113

Post by dboreham » Sun, Dec 20, 2020, 1:02 AM UTC

eternalny1 wrote: post #21

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…

They are claiming that their build system was compromised and the code was not under source control. > Based on our investigations to date, which are ongoing, we believe that the vulnerability was inserted within the Orion Platform products and existed in updates released between March and June 2020 (what we call the “relevant period”) as a result of a compromise of the Orion software build system and was not present…

Yarn cache? (or similar bogus feature in other language tooling).

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

#114

Post by dboreham » Sun, Dec 20, 2020, 1:04 AM UTC

saagarjha wrote: post #103

Spooky23 wrote: post #101

Earlier quoted context omitted.

The vast majority of software shops don’t even consider insider threat in any meaningful way. Imo it’s would be trivial to compromise many. Most companies have soft underbelly units like offshore maintenance engineering, tools teams and patching teams who don’t get a lot of meaningful oversight and can bypass many controls.

I mean, not even that. The cost to buy a software engineer and get them hired at the place you want to attack is really not that high. Once inside it’s generally possible to get things in (“the guild server was failing so I SSHed in and fixed it”).

Whispers for decades that NSA does this.

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

#115

Post by dboreham » Sun, Dec 20, 2020, 1:09 AM UTC

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…

Quick off the top of my head advice is to build on ephemeral systems a la GH Actions / Circle CI, not on long-lived build machines a la Jenkins.

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

#116

Post by jjk166 » Sun, Dec 20, 2020, 1:12 AM UTC

krapp wrote: post #88

tester756 wrote: post #87

What's the thing about adding "-gate" to everything?

it's been a common way to refer to a scandal since Watergate[0]. Don't know if that's actually the case here though. [0] https://en.wikipedia.org/wiki/Watergate_scandal

I wouldn't refer to getting hacked as a scandal. Unless it comes out that there was some sort of coverup, it seems innapropriate to refer to it as a -gate.

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

#117

Post by richardjennings » Sun, Dec 20, 2020, 1:12 AM UTC

"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 attempt at external comms would set off alarms.

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

#118

Post by dboreham » Sun, Dec 20, 2020, 1:12 AM UTC

EvanAnderson wrote: post #109

MarekKnapek wrote: post #3

Did SolarWinds' CA (certificate authority) reworked their code signing certificate?

I do work for a SolarWinds Customer. SolarWinds told us on Thursday that the certificate was going to be revoked on the 21st. Then yesterday they told us the certificate wasn't being revoked until February 2021. This says to me that the certificate itself probably wasn't compromised. The attacker must have found a place in the CI pipeline where they could insert code and get it signed automatically.

I'd be surprised if signing was done automatically, that would be really bad. More likely it was done manually on a package that came out their build system, without anyone stroking their beard to wonder if that system had had its compiler replaced or its cache of dependencies poisoned.

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

#119

Post by dboreham » Sun, Dec 20, 2020, 1:14 AM UTC

jijji wrote: post #91

I wonder how much different this would be had it been a linux application running under apparmor or in a container environment... One would expect from a security perspective that all of these remotely distributed applications would be running under some kind of chroot jail or container to prevent the kind of exposure that is obviously happening here. I think Microsoft is a little complicit in their lack of security…

Isn't the whole point to this that the targeted software is supposed to run at high privileges and is also supposed to phone home? So it's the ideal vector for an exfil attack. The only way to avoid it would be to do like Hillary and run your own email server with none of this cool stuff installed.

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

#120

Post by netsharc » Sun, Dec 20, 2020, 1:17 AM UTC

saagarjha wrote: post #103

Spooky23 wrote: post #101

Earlier quoted context omitted.

The vast majority of software shops don’t even consider insider threat in any meaningful way. Imo it’s would be trivial to compromise many. Most companies have soft underbelly units like offshore maintenance engineering, tools teams and patching teams who don’t get a lot of meaningful oversight and can bypass many controls.

I mean, not even that. The cost to buy a software engineer and get them hired at the place you want to attack is really not that high. Once inside it’s generally possible to get things in (“the guild server was failing so I SSHed in and fixed it”).

Or have them compromised? In the spy movies they'd send a female agent to seduce and then blackmail the married high ranking official, a scenario that bachelor software developers probably dream of.