No way. So far there have been zero APT attacks traced back to inside jobs. That's not how modern spy agencies work anymore.
Code signing hardly means much. All you have to do is compromise CI to make an organisation sign a binary that isn't based on reviewed code.
How hard is that? I think for the vast majority of us we have to admit our CI would be very easy to compromise. Especially if you can get administrator credentials as easily as these guys apparently can. But even without that, CI executes and runs arbitrary code that's intended to only come from trusted individuals.
Step 1. Find a third party package or library that is being downloaded by a package manager onto a CI box.
Step 2. Compromise the open source dev's laptop by phishing them or something else really basic.
Step 3. Put a back door into that package.
Step 4. Wait for it to be downloaded to and executed on SolarWinds CI.
Step 5. Insert a rootkit into CI.
Now that rootkit can just systematically insert the final back door into any build of that file it sees using link time editing. Every build will have the back door and the owners will eventually sign the binary and push it out to production.
In many orgs CI can actually request signing of any binary it wants, so you don't even have to do that. You can just hack the CI machine, grab the credential used to authenticate to the HSM, sign your preferred binary and then ensure users are downloading it.
> So far there have been zero APT attacks traced back to inside jobs.
That means we're not finding them, not that they don't exist.
Considering how easy it is to create plausible external attack vectors from the inside, I would be surprised if it didn't exist.
As you said, intelligence agencies have had people on the inside of important organisations since forever. That's what they do. It's not like everyone decided inside access is useless, it's more likely it has become easier to not burn insiders by them having to work hands on.
And so perhaps the question that should be keeping the rest of us up at night this week is this:
What if this exploit came through a compromised third-party dependency (eg npm or pypy or deb or rpm or docker image) that made its way into SolarWinds CI system?
The attack you describe is plausible but very visible (your backdoor code will be visible on the package manager and generally not easy to take down). I doubt it's the kind of thing that is likely to be used as part of this kind of attack, which wants to remain invisible for as long as possible.
You just have to make it look like a plausible error. There are enough ways to construct accidental RCE bugs in most languages that it's not an issue. And let's face it, how many people are reverse engineering compiled binaries on repos to look for back doors? It doesn't matter if it gets detected a year later when people go looking, as by then it's achieved its purpose already.
Code signing hardly means much. All you have to do is compromise CI to make an organisation sign a binary that isn't based on reviewed code.
How hard is that? I think for the vast majority of us we have to admit our CI would be very easy to compromise. Especially if you can get administrator credentials as easily as these guys apparently can. But even without that, CI executes and runs arbitrary code that's intended to only come from trusted individuals.
Step 1. Find a third party package or library that is being downloaded by a package manager onto a CI box.
Step 2. Compromise the open source dev's laptop by phishing them or something else really basic.
Step 3. Put a back door into that package.
Step 4. Wait for it to be downloaded to and executed on SolarWinds CI.
Step 5. Insert a rootkit into CI.
Now that rootkit can just systematically insert the final back door into any build of that file it sees using link time editing. Every build will have the back door and the owners will eventually sign the binary and push it out to production.
In many orgs CI can actually request signing of any binary it wants, so you don't even have to do that. You can just hack the CI machine, grab the credential used to authenticate to the HSM, sign your preferred binary and then ensure users are downloading it.