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 in their OS platform allowing these types of issues to proliferate repeatedly year after year with no real changes happening in the ways that applications are locked down.
Analyzing the compromised DLL file that started the Solorigate attack
91–100 of 149 posts
Re: Analyzing the compromised DLL file that started the Solorigate attack
#92I 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…
Do you code review the output of your build system? Imagine you had to write Java for a minute. Are you going to open up JAR files and look at strings to ensure no one is inserting code from your build server?
Or if Java is a bridge too far, are you inspecting your minified webpack output to ensure no one is inserting malicious Javascript?
Re: Analyzing the compromised DLL file that started the Solorigate attack
#93Earlier quoted context omitted.
This makes me think of a common refrain when dealing with parasite infestations: If you see one, there's way more than just one. Deterministic builds cannot come soon enough. And really, builds are not enough, we need to be able to extend confidence in the execution of the programs we write much deeper than just builds.
> Deterministic builds cannot come soon enough. This doesn't do anything for people who buy SolarWinds Orion, which is a closed-source off-the-shelf tool that gets picked up everywhere because of a combination of good sales tactics, compliance checkboxes, and ability to remove work from all involved. Going back up the chain, a technical solution probably won't solve the issues inside SolarWinds either. Systemic organ…
Being liable for the consequences of poor software development and security practices would
Re: Analyzing the compromised DLL file that started the Solorigate attack
#94The handling of this whole event is in stark contrast to just a few years ago - when details on malicious activity were a closely guarded secret and useful threat data was safely locked away from anyone who might protect the public with it.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#95Earlier quoted context omitted.
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.
Google banned Windows machines from their workforce a decade ago (due to getting hacked by the Chinese). Has Google relaxed that ban in any way? I.e. does Google believe that Windows 10 is now secure? What other major corporations or government departments have followed Google’s example since 2010?
I think "banned" is an overstatement. There were/are people obligated to use Windows because they need professional EDA tools and suchlike software only available for that platform. And although it's by no means my speciality -- I'm a distributed systems developer, not a Windows sysop -- I was told a few years ago that the general belief was that Windows had the most sound security story of all the operating systems you could put on a laptop. The reputation of Windows is a combination of history and the fact that idiots are likely to use it, so it always looks like the OS people do stupid things with. But if your company culture isn't stupid you can make it work much better.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#96Earlier quoted context omitted.
> Deterministic builds cannot come soon enough. This doesn't do anything for people who buy SolarWinds Orion, which is a closed-source off-the-shelf tool that gets picked up everywhere because of a combination of good sales tactics, compliance checkboxes, and ability to remove work from all involved. Going back up the chain, a technical solution probably won't solve the issues inside SolarWinds either. Systemic organ…
Being liable for the consequences of poor software development and security practices would
If top management, maybe.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#97Earlier quoted context omitted.
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
but why? why cannot it just be "solarwinds hack"
If it fits, I prefer gate, but in this case the suffix is quite jarring so I agree
Re: Analyzing the compromised DLL file that started the Solorigate attack
#98Earlier quoted context omitted.
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
Trump said a thing and China was one of the words in that thing.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#99What's the thing about adding "-gate" to everything?
(not an answer but) It's less annoying than needlessly adding "Cyber" to criminal activity.
Re: Analyzing the compromised DLL file that started the Solorigate attack
#100I 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?
> what network detection could be done to detect this sort of thing. Clearly the code needed to make outbound connections to hosts.
Renting space that shares a netblock with a trusted host could make that more difficult.