Live data from Hacker News

Analyzing the compromised DLL file that started the Solorigate attack

microsoft.com

11–20 of 149 posts

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

#11
post #6
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…

It's not hard to envision code reviews that don't review every single line. Been on both sides of it. Code review isn't a security barrier, it's a (noisy) safety check. It can't even catch every silly bug, let alone deliberate covert sabotage.

The chunk of code that unzips the Base64 encoded strings looks super dodgy and should jump right out even at a casual reviewer.

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

#12
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?

So you're saying that Russia's interests are entirely altrustic? That's quite a stretch. I don't think they hacked SolarWinds to "prove how insecure closed source, proprietary software is". Why don't they prove how "insecure" Kaspersky AV is, in that case? Seems strange to pick a software package that nobody's heard of, but happens to be used by thousands of juicy industrial espionage targets of their primary political enemy.

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

#13

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…

That's just going to cause annoying false positives, and it's not that difficult to get around such detection.

I'll bet the only result would be confused developers.

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

#14
post #13

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…

That's just going to cause annoying false positives, and it's not that difficult to get around such detection. I'll bet the only result would be confused developers.

I can imagine it failing or succeeding depending on how intrusive the UX is. It's worth trying out I think, especially in an opt-in fashion. They can improve it gradually and people can leave it disabled if they don't like it.

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

#15
post #12
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?

So you're saying that Russia's interests are entirely altrustic? That's quite a stretch. I don't think they hacked SolarWinds to "prove how insecure closed source, proprietary software is". Why don't they prove how "insecure" Kaspersky AV is, in that case? Seems strange to pick a software package that nobody's heard of, but happens to be used by thousands of juicy industrial espionage targets of their primary politic…

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 these things which make the world a better place, and why isn't it us leading the charge in these 3 issues? Maybe it is just a coincidence that those 3 things align with their selfish interests, and their is no altruism involved? Or maybe there's a group in Russia that loves the ideals of the USA, and is able to actually help implement those ideals from there, because if you tried to do those 3 things from here you would be thrown in prison due to some bad laws/people here?

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

#16
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?

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

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

Code review and protected master are certainly important but not infallible. If I were a malware author with code running on an owned dev machine and my goal was to sneak code into a repo, I can think of a bunch of strategies that might increase the odds of slipping past a review.

Just running in the background, waiting to amend a big commit with many changed files/lines would probably go a long way. How often does a reviewer glaze over when reading through a diff where someone shuffled some modules around, causing a lot of line changes without any real implementation changes? Perfect opportunity to slip a few new lines into a long file amidst all the other changes.

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

#18
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 the hack in couple of days, that is just pure propaganda aimed for people with little to no knowledge about computer security.

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

#19
post #11
post #6

Earlier quoted context omitted.

It's not hard to envision code reviews that don't review every single line. Been on both sides of it. Code review isn't a security barrier, it's a (noisy) safety check. It can't even catch every silly bug, let alone deliberate covert sabotage.

The chunk of code that unzips the Base64 encoded strings looks super dodgy and should jump right out even at a casual reviewer.

Maybe, assuming it's all committed in one shot (rather than, say, a couple lines per review) and the reviewer scrolls through and glances at every chunk of code. It's some 4000 lines of code, so I wouldn't be surprised if at least one of those wasn't the case. (And all of this is assuming the reviewer was a typical one... if they were particularly known to be careless or compromised, then you don't need these either.)

P.S. Oh, one more thing: some workflows don't mandate a second review after the code is amended, so the initial code could be benign. And many don't require the merger to be the reviewer either. So this could've gotten in that way too.

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

#20
Interesting tidbit at the bottom ...

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

Post reply on HN