Excellent Write-up of the SolarWinds Security Breach
Robert Chesney wrote up the Solar Winds story as a case study, and it’s a really good summary.
Comments
mark • August 30, 2021 11:38 AM
Corrections to the write-up:
1. A build environment is not the development environment. The latter builds against a copy of the current release, but the developers’ new modules are built and tested there. Then it should be tested by someone else, before going to build.
2. Going to build means that the changed module is checked into the version control system (VCS), whatever they use, be it BitLocker or Git or whatever. The developer has to have authority for their account to check in that version.
3. The trick here is that, from the article, they seem to have written the .dll into the build environment… after assuring that there is no .dll with that name. If there had been, it would have been overwritten in the next build… since builds extract from a VCS and build the entire system from source.
Interesting question: did they get it into wherever the third-party libraries reside, or into the the location that the built system goes? I suspect the latter, since that would allow, when the VCS manager packages up the new release.
Jonathan R • August 31, 2021 12:55 AM
Which just goes to prove that keeping private keys in software in inherently vulnerable. Private keys should be safely stored within suitable cryptographic devices, such as tokens or HSMs
Winter • August 31, 2021 4:42 AM
@Jonathan R
“Which just goes to prove that keeping private keys in software in inherently vulnerable.”
It is like placing the key to the front door under the flower pot.
SpaceLifeForm • August 31, 2021 4:44 PM
What they actually did was monitor for a particular c# source code file being compiled by msbuild.exe, when found they replaced this file on disk for a version with the SUNBURST code appended, let msbuild finish compiling, then swapped the source code file back to the original.
A lot can happen in 10 NTFS seconds.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
anonymous • August 30, 2021 9:02 AM
For the injection of the SUNBURST backdoor into the build environment the DLL wasn’t directly embedded into the update package. What they actually did was monitor for a particular c# source code file being compiled by msbuild.exe, when found they replaced this file on disk for a version with the SUNBURST code appended, let msbuild finish compiling, then swapped the source code file back to the original. There is also a comparison against the hash of the original source code to pressumbly make sure they didn’t replace a version they weren’t yet aware of (ie Orion updated unexpectedly). This was probably to prevent accidentally breaking the application.
SUNBURST also never uninstalled itself. In instances where the implant was deemed not interesting enough to continue, it was disabled by changing a configuration entry that prevents future malicious call outs, but the backdoor stayed in disk.