Software Supply Chains are more insecure then we give our self credit. This is a small case study of how easy it is to find suitable targets to compromise a supply chain.
For this case study I am going to use a 2023 package that was compromised in a supply chain attack ‘fsevents’.
This particular supply chain attack was interesting because the attackers did not need to compromise a maintainers account, or even touch the source code. It took just a little patience.
We will be using the package fsevents as a case study.
December 2019 the fsevents team released 1.2.11 which removed a reference the a S3 bucket that was being used to deliver binaries as part of their build dependencies. The reason for this was lost credentials to the S3 bucket. The team was aware of the risk in 2019 and did not release the S3 resource.
but nothing last forever… except technical debt and outdated dependencies.The cloud resource was eventually released and attackers registered the S3 bucket and uploaded malicious binaries in 2023. As a result, projects still using the deprecated version of fsevents began to download and execute the malware of part of the intended build process that the deprecated version of fsevents was using.
How many could that have been? Well, a lot. As of today, 10/16/2024 I would say with more than 22 million weekly downloads and 4,664 packages using fsevents as a dependency… it’s kind of of a large impact.
Lets see how many times the deprecated versions are being downloaded as of 10/16/2024.
It’s not insignificant…. take care of your technical debt. “Vulnerable and Outdated” components is one of the OWASP top 10.
I think it’s safe to assume these numbers were even higher in april 2023.
This is just evidence that out of date libraries are great attack vectors.
There are a number of tools for this type of OSINT is enormous and freely availible. We are doing code search across open source repositories on the internet. A search engine that lets you filter by extension and parse content using pattern matching is the most efficant.
Well we want to compromise the softeware supply chain, to do this we wantto focus our attention on files that are used during build time.
The developer and build system place trust in open source. Since we neivly place trust in package managers to handle the resolution and management of opensource packages we primarly want to focus on package manager manifest files.
In this case we are foucsing on the JS ecosystem which relies on the ‘package.json’ file to declare the packages that are being used AND contains other properties that provide build time instrustions.
Regardless of the build systems or package manager we want something that can satisfy this condition. During build time we want the build system to execute a script or binary downloaded from a external host. The external host should be something that has a high likely hood of being controlled by a threat actor.
// fsevents v1.1.1 package.json sometime 2019
"binary": {
"module_name": "fse",
"module_path": "./lib/binding/{configuration}/{node_abi}-{platform}-{arch}/",
"remote_path": "./v{version}/",
"package_name": "{module_name}-v{version}-{node_abi}-{platform}-{arch}.tar.gz",
"host": "https://fsevents-binaries.s3-us-west-2.amazonaws.com"
}
What’s dangerous here is that cloud resource. This is what attackers took advantage of. When the maintainers of fsevents deprecrated this package, they were aware that releaseing this resource was dangerous and said it was not going to be released. It was a good intintion, but eventaully the resource was released, it just took a few years. The attackers registered the domain and crafted a malcious binay. As soon as they publised the malicious binary, any system building a project with this dependency now had malware.
Let’s follow in the path of ‘fsevents’ and look at npm’s package.json file. I am going to be using a source code search engine sourcegraph.com.
