Really, really, really looking for the eventual analysis of how the attackers were able to compromise SolarWinds' build server. And to that point, while SolarWinds' bending over backward to characterize it as "an incredibly complex and sophisticated attack" is predictable, it's also ludicrous without saying how the initial intrusion occurred. That is, everything I've read has explained how the actual payload that was delivered to the victims' networks was sophisticated and complex, but it's possible the original build server vulnerability was braindead simple. We just don't know until that is revealed.

Pure conjecture. But let’s say solar winds is using a known popular build server, and this build server was only ever going to be accessed by internal resources and employees.

Then let’s say this build server had an unusually high usage of build plugins. And the upgrading of that product was difficult and sometimes troublesome because of these custom plugins and their interdependencies. And so they at some point they missed an upgrade or two on accident, or because upgrading is hard.

Now they are running an build server with several know vulnerabilities. But because that build server isn’t public. It’s really no big deal that it’s a bit out of date. Until it is.

Ah, it was the butler - in the server room - with the ethernet cable.

(Come to think of it, security Cluedo would be quite fun ...)

Let me guess, was there a certain butler involved?

And said build server application has 150 CVEs, and if people get lazy will provide shells to unauthenticated web users:

https://www.cvedetails.com/vulnerability-list/vendor_id-1586...

That sounds very interesting and frightening at the same time.

Could it be that there are more companies out there in a kind of similar situation? It would be quite bad of course if such information would become widely know I could imagine.

Now that it's come out that SolarWinds's default password on their deployed systems was 'solarwinds123', it's quite possible that the break-in to their build server wasn't all that hard.

It also doesn't really matter if I understood correctly AFA establishing incompetent defense for simple attacks. You could ftp in and upload a binary? but it wouldn't be signed! What about an old binary? Already we are into attacks on the anti-rollback on individual clients and we didn't need anything a beginner wouldn't try.

(I would go so far as to say that if there was insufficient anti-rollback and they still burned 0-days to get into that build server then they were expending resources trying to either look sophisticated or had some other odd motivation.)

Whenever I hear statements like "incredibly complex and sophisticated attack" I'm reminded of the 2011 Comodo (now Sectigo) hack where the company said it had "clinical accuracy" and "likely to be a [Iranian] state-driven attack".

Days later, the perpetrator released a "manifesto" (and several other documents) all but confirming that it was the work of a lucky amateur.

Moxie (of Signal fame) has a hilarious account of the story in his 2011 Blackhat talk "SSL and the future of authenticity" (starts at around 5:00):

https://www.youtube.com/watch?v=UawS3_iuHoA

Unless one of the arbitrary executables was arbitrarily executed in the intranet, opening further doors.

> but they still wouldn't be signed like a valid SolarWinds update would be

Would it be detected though?