MalPacDetector: An LLM-Based Malicious NPM Package Detector

Cornell University - arXiv, 2022

Open source code is considered a common practice in modern software development. However, reusing other code allows bad actors to access a wide developers' community, hence the products that rely on it. Those attacks are categorized as supply chain attacks. Recent years saw a growing number of supply chain attacks that leverage open source during software development, relaying the download and installation procedures, whether automatic or manual. Over the years, many approaches have been invented for detecting vulnerable packages. However, it is uncommon to detect malicious code within packages. Those detection approaches can be broadly categorized as analyzes that use (dynamic) and do not use (static) code execution. Here, we introduce Malicious Source code Detection using T ransformers (MSDT) algorithm. MSDT is a novel static analysis based on a deep learning method that detects real-world code injection cases to source code packages. In this study, we used MSDT and a dataset with over 600,000 different functions to embed various functions and applied a clustering algorithm to the resulting vectors, detecting the malicious functions by detecting the outliers. We evaluated MSDT's performance by conducting extensive experiments and demonstrated that our algorithm is capable of detecting functions that were injected with malicious code with precision@k values of up to 0.909.

Data Analytics and Management, 2021

Node.js has a default package manager called Node Package Manager (NPM). There exists a command line client, called NPM, and an online database of public and paid-for private packages, known as the NPM registry. The registry is accessed via the user, and the available packages can be browsed and searched through the NPM Web site. Given a new project description, it is crucial to determine the most favorable NPM packages that can be used for the overall success of the project because of the reusable nature of these packages for rapid development. Though the hurdle faced by most of the developers is to select the right one from the vastly present number of NPM packages. Thus, to solve this issue, we propose a method called NPMREC known as NPM package and Similar Projects Recommendation System. It takes a project description as an input and gives a ranked list of NPM packages as the output that can then be used to implement the project with better efficiency. We used custom-built datasets for our approach using libraries.io Web site. The training dataset contains two datasets, firstly, the past project dataset with 589 NPM projects/NPM modules with information about their dependencies/NPM packages; secondly, the NPM package dataset with 759 NPM packages containing the detailed information about the dependencies of these 589 NPM projects/NPM modules. The test dataset contains 105 NPM projects/NPM modules along with information about their dependencies.

Malicious scripts are an important computer infection threat vector. Our analysis reveals that the two most prevalent types of malicious scripts include JavaScript and VBScript. The percentage of detected JavaScript attacks are on the rise. To address these threats, we investigate two deep recurrent models, LaMP (LSTM and Max Pooling) and CPoLS (Convoluted Partitioning of Long Sequences), which process JavaScript and VBScript as byte sequences. Lower layers capture the sequential nature of these byte sequences while higher layers classify the resulting embedding as malicious or benign. Unlike previously proposed solutions, our models are trained in an end-to-end fashion allowing discriminative training even for the sequential processing layers. Evaluating these models on a large corpus of 296,274 JavaScript files indicates that the best performing LaMP model has a 65.9% true positive rate (TPR) at a false positive rate (FPR) of 1.0%. Similarly, the best CPoLS model has a TPR of 45.3% at an FPR of 1.0%. LaMP and CPoLS yield a TPR of 69.3% and 67.9%, respectively, at an FPR of 1.0% on a collection of 240,504 VBScript files.

IEEE Transactions on Software Engineering, 2022

Nowadays, developing software would be unthinkable without the use of third-party packages. Although such code reuse helps to achieve rapid continuous delivery of software to end-users, blindly reusing code has its pitfalls. For example, prior work has investigated the rationale for using packages that implement simple functionalities, known as trivial packages. This prior work showed that although these trivial packages were simple, they were popular and prevalent in the npm ecosystem. This popularity and prevalence of trivial packages peaked our interest in questioning the 'triviality of trivial packages'. To better understand and examine the triviality of trivial packages, we mine a large set of JavaScript projects that use trivial npm packages and evaluate their relative centrality. Specifically, we evaluate the triviality from two complementary points of view: based on project usage and ecosystem usage of these trivial packages. Our result shows that trivial packages are being used in central JavaScript files of a software project. Additionally, by analyzing all external package API calls in these JavaScript files, we found that a high percentage of these API calls are attributed to trivial packages. Therefore, these packages play a significant role in JavaScript files. Furthermore, in the package dependency network, we observed that 16.8% packages are trivial and in some cases removing a trivial package can impact approximately 29% of the ecosystem. Overall, our finding indicates that although smaller in size and complexity, trivial packages are highly depended on packages by JavaScript projects. Additionally, our study shows that although they might be called trivial, nothing about trivial packages is trivial.

2016

JavaScript is a common attack vector for attacking browsers, browser plug-ins, email clients and other JavaScript enabled applications. Malicious JavaScripts redirect victims to exploit kits, probe for known vulnerabilities to select a fitting exploit or manipulate the Document Object Model (DOM) of a web page in a harmful way. Malicious JavaScript code is often obfuscated in order to make it hard to detect using signature-based approaches. Since the only other reason to use obfuscation is to protect intellectual property, the share of scripts which are both benign and obfuscated is quite low, and could easily be captured with a whitelist. A detector that can reliably detect obfuscated JavaScripts would therefore be a valuable tool in fighting malicious JavaScripts. In this paper, we present a method for automatic detection of obfuscated JavaScript using a machine-learning approach. Using a dataset of regular, minified and obfuscated samples from a content delivery network and the A...

2020 IEEE International Conference on Software Maintenance and Evolution (ICSME), 2020

Node.js has been popularly used for web application development, partially because of its large software ecosystem known as NPM (Node Package Manager) packages. When using open-source NPM packages, most developers download prebuilt packages on npmjs.com instead of building those packages from available source, and implicitly trust the downloaded packages. However, it is unknown whether the blindly trusted prebuilt NPM packages are reproducible (i.e., whether there is always a verifiable path from source code to any published NPM package). Therefore, for this paper, we conducted an empirical study to examine the reproducibility of NPM packages, and to understand why some packages are not reproducible.Specifically, we downloaded versions/releases of 226 most popularly used NPM packages and then built each version with the available source on GitHub. Next, we applied a differencing tool to compare the versions we built against versions downloaded from NPM, and further inspected any rep...

2022 IEEE/ACM 44th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP)

Static analysis has established itself as a weapon of choice for detecting security vulnerabilities. Taint analysis in particular is a very general and powerful technique, where security policies are expressed in terms of forbidden flows, either from untrusted input sources to sensitive sinks (in integrity policies) or from sensitive sources to untrusted sinks (in confidentiality policies). The appeal of this approach is that the taint-tracking mechanism has to be implemented only once, and can then be parameterized with different taint specifications (that is, sets of sources and sinks, as well as any sanitizers that render otherwise problematic flows innocuous) to detect many different kinds of vulnerabilities. But while techniques for implementing scalable inter-procedural static taint tracking are fairly well established, crafting taint specifications is still more of an art than a science, and in practice tends to involve a lot of manual effort. Past work has focussed on automated techniques for inferring taint specifications for libraries either from their implementation or from the way they tend to be used in client code. Among the latter, machine learning-based approaches have shown great promise. In this work we present our experience combining an existing machine-learning approach to mining sink specifications for JavaScript libraries with manual taint modelling in the context of GitHub's CodeQL analysis framework. We show that the machinelearning component can successfully infer many new taint sinks that either are not part of the manual modelling or are not detected due to analysis incompleteness. Moreover, we present techniques for organizing sink predictions using automated ranking and codesimilarity metrics that allow an analysis engineer to efficiently sift through large numbers of predictions to identify true positives. CCS CONCEPTS • Software and its engineering → Automated static analysis.

2020

Authorship identification of source code is the process of identifying the composer of given source code. Code authorship identification plays an important role in many real-world scenarios, such as the detection of plagiarism and ghost writing in both education and workplace settings. Additionally, it can allow the identification of individuals or organisations that produce and distribute malware programs. In this paper we describe the experimentation and submission by team UoB to the AI-SOCO track at FIRE 2020, which achieved first place. We first perform extensive testing on a variety of techniques used in source code authorship identification including n-gram, stylometric, and abstract syntax tree derived features. We also investigate the application of CodeBERT, a new pre-trained model that demonstrates state-of-the-art performance in natural and programming language tasks. Finally, we explore the potential of ensembling multiple models together to create a single superior mode...

The dynamic features of the JavaScript language not only promote various means for users to interact with websites through Web browsers, but also pose serious security threats to both users and websites. On top of this, obfuscation has become a popular technique among malicious JavaScript code that tries to hide its malicious purpose and to evade the detection of anti-virus software. To defend against obfuscated malicious JavaScript code, in this paper we propose a mostly static approach called JStill. JStill captures some essential characteristics of obfuscated malicious code by function invocation based analysis. It also leverages the combination of static analysis and lightweight runtime inspection so that it can not only detect, but also prevent the execution of the obfuscated malicious JavaScript code in browsers. Our evaluation based on real-world malicious Jav-aScript samples as well as Alexa top 50,000 websites demonstrates high detection accuracy (all in our experiment) and low false positives of JStill. Meanwhile, JStill only incurs negligible performance overhead, making it a practical solution to preventing obfuscated malicious JavaScript code.

2021

Third-party package usage has become a common practice in contemporary software development. Developers often face different challenges, including choosing the right libraries, installing errors, discrepancies, setting up the environment, and building failures during software development. The risks of maintaining a third-party package are well known, but it is unclear how information from Stack Overflow (SO) can be useful. This paper performed an empirical study to explore npm co-usage in SO. From over 30,000 SO posts, we extracted 2,100 SO posts related to npm and matched them to 217,934 npm library packages. We find that, popular and highly used libraries are not discussed as often in SO. However, we can see that the accepted answers may prove useful, as we believe that the usage examples and executable commands could be reused for tool support.