Security chief Mike Hanley posted an article yesterday on the issue, which was reported by security researchers Kajetan Grzybowski and Maciej Piechota on November 2 and corrected within six hours. This impressive speed contrasts with the duration of existence of the vulnerability, which would be longer than “the period for which we have available telemetry, which dates back to September 2020”.
The vulnerability was based on a familiar insecurity model, where the system correctly authenticates a user but then allows access beyond what that user’s permissions should allow. In this case, the NPM service successfully validated that a user has permission to update a package, but “the service that performs the underlying registry data updates determined which package to publish based on the contents of the downloaded package file.
“This discrepancy provided a means by which requests to release new versions of a package would be allowed for one package, but would in fact be made for a different and potentially unauthorized package.”
Hanley also revealed that the names of some privately published packages, which should not be listed in the public registry, were inadvertently exposed via a public NPM replica, for about a week. However, the content of the packages was not accessible and this was fixed on October 29.
GitHub plans to strengthen the security of the NPM registry by requiring two-factor authentication (2FA) for managers and administrators of the most popular packages, starting in Q1 2022. 2FA is already possible but not required. The 2FA technology used will be WebAuthn. Details on how this will work will be released “in the coming weeks,” Hanley said.
The goal is to prevent account takeovers, like last month’s incident involving ua-parser-js. At the time, GitHub warned, “Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on this computer should be immediately transferred from another computer. “
The NPM community also discussed strengthening security through code signing. It is already possible to verify the PGP (Pretty Good Privacy) signature of an NPM package but this only guarantees that the downloaded package matches what was published, and would not help in the event that a package is published but without appropriate authorization. ®