Hacked Malicious PyPI Python Libraries Identified
November 22, 2021 - How often do you review or examine the public packages leveraged as dependencies for your application project? Like many other developers, you probably do not and take for granted that the packages are legitimate.
Well, that DevOps behavior will likely to change as researchers from JFrog has identified at least 11 Python malicious packages that could be exploited using dependency confusion to steal Discord access tokens, and passwords.
The dependency confusion attack works as follows:
The perpetrator create the malicious packages.
The malicious package is then uploaded to the public repository giving a higher version than the legitimate package using compromised developer accounts.
During the build package, the latest version of the package is then fetched, allowing the perpetrator to gain access to the user machines and subsequently adding backdoors or remote code execution to the builds without any developer intervention.
Any public accessible repositories are vulnerable to the technique, especially the larger and more popular like Node Package Manage (NPM), JavaScript Registry, PyPI and RubyGems.
Microsoft outlined several mitigation strategies and they are summarized below:
Reference a single private feed. Configure the package manager to use only a single source, to isolate you from unexpected public feed changes including broken updates and removals as well as targeted substitution attacks.
Protect your package using controlled scopes. Most package managers provide capabilities to limit scopes, namespaces, and prefixes. Leverage these capabilities to identify specific package (e.g., usage of ID prefix in NuGet), or source of a package (e.g., use of scope prefix in NPM via npmrc, or .yarnrc.yml).
Use client-side verification features. Package managers provide client-side verification features to protect against supply chain attacks. These include options such as version pinning and integrity verification. Version pinning requires specific versions for packages (e.g., 4.1.4 vs. >=4.1 or 4.1*). Integrity verification requires comparing the file hash of the file downloaded vs. the intended original and will abort if any inconsistencies are found.
Comments