A technologist working and maintainer of a popular piece of open-source software has deliberately sabotaged his own code, apparently as a protest for not getting financial recompense from corporates for his work. This was performed to wipe data on computers that used the program in Russia and Belarus.
The two have faced a backlash for doing so, according to messages posted on coding repository Github.
Looking into the controversy for Digital Journal is Mark Waggoner, Principal Engineer at LogRhythm.
He adds: “While we have seen several recent examples of malicious actors inserting their own code into software supply chains, like NotPetya in 2017, SolarWinds in 2020 and Microsoft Exchange Server in 2021, this appears to be if not the first instance of a maintainer deliberately sabotaging their own project, at least the most egregious in recent memory.”
As to the consequences, Waggoner observes: “This action adds a new potential threat actor to our risk assessments for using FOSS or FOSS-derived software.”
And as to what the actual activity means, this is spelt out by Waggoner as: “This scenario is very eye opening and frankly frightening. Even organizations who are following best practice guidelines put out by NIST and CISA would have no way of identifying this type of sabotage before it was active in their environment.”
Expanding in the detail of the incident, Waggoner states: “Since this package was altered by the maintainer and then uploaded to the package manager through entirely valid workflows, it will have all the correct hashes and signatures that security professionals would check.”
Waggoner also finds: “In addition to that, it seems the maintainer also went out of his way to obfuscate their additions to the code base by using base64 encoding to make it even more difficult to identify by either automated means or human reading of the code.”
With the wider implications, Waggoner outlines: “Today, with almost all software having at least some reliance on FOSS products, this action seriously increases the risks for any software company, developer, or even end user of these products. Unfortunately, even such things as “software manifests” and other mitigations as outlined in U.S. National Institutes of Science and Technology (NIST) 800-171 or the recent U.S. Department of Homeland Security (DHS) report assessing supply chain risks would not have any impact on stopping this particular type of sabotage. However, having these risk awareness and mitigation policies in place should lead to quicker remediation once discovered.”