Practical Automated Detection of Malicious npm Packages

Abstract

The npm registry is one of the pillars of the JavaScript and Type-Script ecosystems, hosting over 1.7 million packages ranging from simple utility libraries to complex frameworks and entire applications. Each day, developers publish tens of thousands of updates as well as hundreds of new packages. Due to the overwhelming popularity of npm, it has become a prime target for malicious actors, who publish new packages or compromise existing packages to introduce malware that tampers with or exfiltrates sensitive data from users who install either these packages or any package that (transitively) depends on them. Defending against such attacks is essential to maintaining the integrity of the software supply chain, but the sheer volume of package updates makes comprehensive manual review infeasible. We present Amalfi, a machine-learning based approach for automatically detecting potentially malicious packages comprised of three complementary techniques. We start with classifiers trained on known examples of malicious and benign packages. If a package is flagged as malicious by a classifier, we then check whether it includes metadata about its source repository, and if so whether the package can be reproduced from its source code. Packages that are reproducible from source are not usually malicious, so this step allows us to weed out false positives. Finally, we also employ a simple textual clone-detection technique to identify copies of malicious packages that may have been missed by the classifiers, reducing the number of false negatives. Amalfi improves on the state of the art in that it is lightweight, requiring only a few seconds per package to extract features and run the classifiers, and gives good results in practice: running it on 96287 package versions published over the course of one week, we were able to identify 95 previously unknown malware samples, with a manageable number of false positives. CCS CONCEPTS• Security and privacy → Malware and its mitigation.

Taxonomy of Attacks on Open-Source Software Supply Chains

“…A comparable feature is not present in most compiled languages, like Java, C/C++ or Ruby. In such cases, Integrity check of dependencies through cryptographic hashes [9], [36], [83], [109], [131], [135], [138] 3.3 3.0 2.5 2.0 1.32 Y N 2.3 2.0 Maintain detailed SBOM [5], [8], [53], [183], [184] and perform SCA [8], [31], [43], [48], [51], [53], [55] [42], [123], [185] Code signing [47], [83], [109], [135], [138], [141] Application Security Testing [34], [39], [41], [46], [55], [56], [58], [66], [80], [122], [134], [187] 4 execution is achieved either at runtime, e.g., by embedding the payload in a specific function or initializer, or by poisoning test routines [19]. Differences also exist in regards to code obfuscation and malware detection.…”

“…In case of interpreted languages, downloaded packages contain the malware's source code, which makes it more accessible to analysts compared to compiled languages. The presence of encoded or encrypted code in such packages proofed being a good indicator of compromise [58], as there are few legimitate use-cases for open-source packages. Minification is one of them, however, matters primarily for frontend JavaScript libraries.…”

“…Still, recent publications focus on those ecosystems, esp. JavaScript and Python [15], [16], [57], [58], [74]), partly due to their popularity, but also because existing malware analysis techniques cannot be easily applied.…”

“…(AV-000) Conduct Open-Source Supply Chain Attack SL: [18], [19], [31]- [56] (AV-100) Develop and Advertise Distinct Malicious Package from Scratch SL: [16], [19], [57], [58] GL: [59]- [65] (AV-200) Create Name Confusion with Legitimate Package SL: [16], [58], [66], [67] GL: [68]- [70] (AV-201) Combosquatting SL: [71] GL: [72], [73] (AV-202) Altering Word Order SL: [74] (AV-203) Manipulating Word Separators SL: [74] (AV-204) Typosquatting SL: [15], [71], [74]- [76] GL: [77], [78] (AV-205) Built-In Package SL: [74] GL: [79] (AV-206) Brandjacking SL: [74] (AV-207) Similarity Attack SL: [71] (AV-001) Subvert Legitimate Package (AV-300) Inject into Sources of Legitimate Package SL: [19], [80]- [85] (AV-301) Introduce Malicious Code through Hypocrite Merge Request SL: [11], [85]- [87] GL: [88] (AV-304) Make Immature Vulnerability Exploitable SL: [11], [89] GL: [88] (AV-305) Exploit Rendering Weakness SL: [10] (AV-306) Exploit Unicode Bidirectional Algorithm SL: [10] GL:…”

Are your dependencies code reviewed?: Measuring code review coverage in dependency updates

“…Supply chain security: Recent works have focused on the secure use of open source dependencies as part of the software supply chain [24,31,40,41]. Duan et al have proposed static and dynamic analysis approaches to detect malicious packages for the interpreted languages [19], while Sejfia et al have proposed machine learning models to detect malicious npm packages [33]. Further, Ferreira et al have proposed a permission-based protection mechanism for malicious npm updates [20].…”