[p932]

Your quote seems to be describing what Microsoft observed from the attackers on the compromised machines with SolarWinds Orion not how the software was compromised in the first place.

See detailed version: https://msrc-blog.microsoft.com/2020/12/13/customer-guidance...

> In actions observed at the Microsoft cloud, attackers have either gained administrative access using compromised privileged account credentials (e.g. stolen passwords) or by forging SAML tokens using compromised SAML token signing certificates.

> Although we do not know how the backdoor code made it into the library, from the recent campaigns, research indicates that the attackers might have compromised internal build or distribution systems of SolarWinds, embedding backdoor code into a legitimate SolarWinds library with the file name SolarWinds.Orion.Core.BusinessLayer.dll.

[dane-pgp]

> the attackers might have compromised internal build or distribution systems of SolarWinds

It should probably become a requirement (for both open and closed source software) that any updates be not just signed but have their hashes available in a Binary Transparency log[0].

When you first install a piece of software, you might need to calculate the hash locally and manually search for it in a log's web interface, but after that, its software-update routine should check that the new version it is downloading has had its hash published in a known place. That way, software publishers can check an append-only independently-run log to see what has been signed with their keys.

I suppose there is a risk that an attacker could prevent users from receiving security updates by DoS'ing the transparency logs, but that should be harder than just DoS'ing the servers that host the software updates themselves. Large organisations could also maintain mirrors of these logs on their internal networks, which would help with privacy/latency/availability, and the logs should ideally be available as Tor hidden services too.

For non-critical updates, the log checking routine should require that the update's hash had been in the log for a certain period of time, long enough for the software publisher to notice and raise the alarm to their users. Updates marked as critical should default to stopping the software from running until the necessary period had elapsed, for which the workaround would be a fresh install of the newer version by whomever has the admin privileges to do that.

[0] https://wiki.mozilla.org/Security/Binary_Transparency

[SoSoRoCoCo]

Is there any indication that there was an inside operative(s)? Or was this purely an external hack?