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

101–110 of 149 posts

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

#101

Post by Spooky23 »

tsimionescu wrote: post #5
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…

If we're at the level where we think it's an inside job, it doesn't seem that difficult to have 2 people on the inside "reviewing" each other's malicious commits. For what it's worth, my org also has the same policy, but it's intended to catch mistakes, not to protect against malicious actors inside the company.

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.

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

#102

Post by saagarjha »

rossjudson wrote: post #56
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 sys…

Successfully pulling off such an attack, of course, is quite difficult.

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

#103

Post by saagarjha »

Spooky23 wrote: post #101
tsimionescu wrote: post #5

Earlier quoted context omitted.

If we're at the level where we think it's an inside job, it doesn't seem that difficult to have 2 people on the inside "reviewing" each other's malicious commits. For what it's worth, my org also has the same policy, but it's intended to catch mistakes, not to protect against malicious actors inside the company.

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”).

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

#104

Post by blastro »

Shank wrote: post #39
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…

If you view GitHub as a static infallible source, then yes -- your analysis is correct. But there are gaps anywhere. If you want perfect 1:1 mappings between source, the developers who make it, and the end builds, you essentially need a "chain of trust" that can be tested at every stage. For example: are all developers pushing code with encrypted SSH keys? Are the commits signed? Are the signing keys hardware backed?…

very well articulated, thanks.

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

#105

Post by saagarjha »

chris_wot wrote: post #70
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…

Can’t you just run a git rebase to disguise it?

Depending on what you rebase to and what the usual workflow is for developers. Those that rebase from remote frequently (guilty) won’t notice, but those that do merges might.

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

#106

Post by [deleted] »

pbronez wrote: post #89
toast0 wrote: post #60

Earlier quoted context omitted.

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

I wonder if you could gain security while preserving agility by having build servers with exceptional (and annoying) security maintained offline. Do your CI/CD work, then chop off a weekly release and build it from source on a machine that’s been powered off in a secure room the whole time. Still doesn’t help you if the attack is sufficiently upstream..

[deleted]

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

#107

Post by maccard »

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've said this before, but I work on a team of 5 or 6 people. If I (pre covid) sent them a PR and walked over to their desk, told them it was super urgent and a tiny change just needed a rubber stamp, one of them would do it (and I would likely do the same for them). Failing that I can name a handful of developers that wouldn't be familiar with the system but will review my change because I did the same for them a few months ago (and they'll comment on stylistic/clarity issues, rather than the work being done). Even if you think this is rare, it likely isn't and likely happens at every company to some degree.

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

#108

Post by diamondo25 »

saagarjha wrote: post #102
rossjudson wrote: post #56

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…

Successfully pulling off such an attack, of course, is quite difficult.

Nothing is difficult if theres a good reason to do it and you have money and time to do the attack :)

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

#109

Post by EvanAnderson »

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.

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

#110

Post by akadruid1 »

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…

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-jpmorga...
Post reply on HN