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

71–80 of 149 posts

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

#71

Post by chris_wot »

roywiggins wrote: post #44
Shank wrote: post #35

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…

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.

Trump said it was China

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

#72

Post by Osiris »

pnutjam wrote: post #66
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

Mdt hashes and signing could have avoided this. Open source stuff always verifies, vote closed source doesn't have that habit.

An article I read said that they did provide hashes but they also provided instructions on how to install it anyway if the hashes didn't match.

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

#73

Post by allyant »

chris_wot wrote: post #68

I am curious what network detection could be done to detect this sort of thing. Clearly the code needed to make outbound connections to hosts. Some thoughts: if there is an encoded sub domain, flag this as suspicious. Any code that uses a function to decode a base64 encoded string should be a red flag. Any newly created thread code should be detected and checked most carefully. Any others people can think of?

Any decent static code analysers should be able to detect things like this (catch all’s statements, base64 encoding etc), I am surprised none seem to be used for production code.

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

#74

Post by stevenicr »

danielovichdk wrote: post #67
efdee wrote: post #37

Earlier quoted context omitted.

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…

On a side note. I Wonder why Snowden chose Russia as his safe haven, thinking about the politics and rulings the country is known for. Have Snowden ever told why he chose Russia?

I vaguely recall that he had chosen somewhere else - but in the midst of the flights from HK(?) to other places, his passport was nulled by the US so he had to stay in Russ, could no longer board int'l flights or something (?)

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

#75

Post by Osiris »

Osiris wrote: post #72
pnutjam wrote: post #66

Earlier quoted context omitted.

Mdt hashes and signing could have avoided this. Open source stuff always verifies, vote closed source doesn't have that habit.

An article I read said that they did provide hashes but they also provided instructions on how to install it anyway if the hashes didn't match.

https://mobile.twitter.com/KyleHanslovan/status/133841999966...

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

#76

Post by meowface »

yread wrote: post #59
meowface wrote: post #53

Earlier quoted context omitted.

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.

Yep, all enabled by the fact that Russia is so corrupt, anyone can pretty easily buy any data about anything on anyone. So any private citizen with a bit of money and some skills can effectively act like a para-intelligence agency, which is essentially what Bellingcat is.

For anyone curious, they have two excellent articles on this from a few days ago:

https://www.bellingcat.com/resources/2020/12/14/navalny-fsb-...

https://www.bellingcat.com/news/uk-and-europe/2020/12/14/fsb...

There was also an amazing investigation into this published yesterday by a Russian outlet, interviewing some of the black market data brokers and law enforcement officers (both of whom claim some of the brokers will be hunted and killed by the state, now):

https://translate.google.com/translate?sl=auto&tl=en&u=https...

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

#77

Post by rurban »

newhouseb wrote: post #42
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 i…

They did sign it with the key they found there, virus vendors detected fancy bear or such, customer support was in denial and recommended all customer to ignore this warning and disable scanning this binary, whitelist.

You don't need the GRU with such a company. Microsoft Defender would not help. Even a 12 year old from mom's basement could have intruded the nuclear arsenal this way. The nation state allegation came from the stealth CC stuff they found. But apparently someone else also took the invitation via writable ftp.

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

#78

Post by alkonaut »

nwellinghoff wrote: post #9
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…

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 better to have access to a point in the build system that enabled you to inject that code in or after the compilation, e.g by tampering with the tool chain on the build machines.

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

#79

Post by derwiki »

allyant wrote: post #73
chris_wot wrote: post #68

I am curious what network detection could be done to detect this sort of thing. Clearly the code needed to make outbound connections to hosts. Some thoughts: if there is an encoded sub domain, flag this as suspicious. Any code that uses a function to decode a base64 encoded string should be a red flag. Any newly created thread code should be detected and checked most carefully. Any others people can think of?

Any decent static code analysers should be able to detect things like this (catch all’s statements, base64 encoding etc), I am surprised none seem to be used for production code.

Is SCA often set up to run on the fully built end result running on the production machine? I’ve generally seen them as pre-merge-to-source-control.

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

#80

Post by slaymaker1907 »

alkonaut wrote: post #78
nwellinghoff wrote: post #9

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…

I was thinking something similar. My first comment on review or even looking at the code is why the exception is swallowed up without logging or a comment about why there is no logging.

That of course leads one to ask what this code is actually doing.

Post reply on HN