In October 2023, our tool detected that the scope @bitcoin-oracle was being used by the crypto company ALEX in their bitcoin oracle repository at https://github.com/alexgo-io/bitcoin-oracle, and we found that the scope was not claimed on the public npm registry.
We were able to register the scope name on npm, and uploaded two PoC placeholder packages that contained minimal code:
We discovered that after uploading the packages, they were being downloaded by the developers of the project while they were working on it.
This is visible in this commit to the pnpm-lock.yaml file on GitHub: a16c1f7e3d33e0aaff2b6a093cdc76435e0450b3
To verify that the placeholder packages we had ownership of were being downloaded, you can compare the integrity hashes in the pnpm-lock.yaml file with the integrity hashes of the packages uploaded to npm and notice that they are the same.
This means that if an attacker was able to exploit this before we discovered the issue, remote code execution (RCE) would've occurred on the developer's computers, leading to the organization getting hacked and cryptocurrency possibly stolen.
Exploiting npm dependency confusion
A malicious npm package can contain code that will be executed during the installation of the package.
An attacker can insert arbitrary system commands in the package's preinstall script defined in the package.json file, or have arbitrary JavaScript executed during the installation process.
A PoC npm package would look like:
When this example PoC package is installed via a command like npm install, the output of the system command id would be saved to rce.txt and the content's of the user's /etc/passwd file would be saved to etc_passwd.txt.
In a real-world attack, the exploitation would not look this obvious, but an attacker would be able to execute anything on a developer's computer or application server where the package is installed.
An attacker could use this type of vulnerability to install malware on the developer's computer and then pivot to gain access to more parts of the organization.
Bug fix
The vulnerability is partially fixed, but the vulnerability is still present in the application. The vulnerability can't be exploited by anyone malicious while we maintain ownership of the @bitcoin-oracle scope on the public npm registry.
Since the placeholder packages we uploaded contained no working code, the application was broken and to fix this the ALEX team replaced the scopes of the commons and persistent packages to make the application work again, but there are still packages with the @bitcoin-oracle scope in the application.
This vulnerability can be completely remediated by changing the remaining @bitcoin-oracle scoped packages to their new scope name, or by us transferring ownership of the @bitcoin-oracle scope, which we would still be happy to arrange.
Disclosure timeline
- Oct 14, 2023 : Bug reported on their Immunefi Bug Bounty program.
- Oct 14, 2023 : Report closed automatically as out-of-scope by Immunefi's bot.
- Oct 14, 2023 : Reached out to Immunefi to make sure the ALEX team has visibility of the report.
- Oct 15, 2023 : Bug partially fixed. No bounty or acknowledgement.
- Oct 16, 2023 : Immunefi responded that the ALEX team had visibility of the report, and that public disclosure is permitted 30 days after the bug was closed.
How attacks like this can be prevented
This vulnerability could have been avoided by:
- Claiming the package's scope on the npm registry in the beginning of development.
- Using file:../foo/bar instead of a wildcard (*) in the package.json file.
- Using SupplyShark to detect the issue immediately!
SupplyShark detects this type of vulnerability in our continuous monitoring services and will alert you immediately if an npm scope being used in your project is available to be registered.
Sign up for SupplyShark to get started securing your supply chain!