
Towards the Detection of Malicious Java Packages
Vu et al. [
34
] analyze the discrepancy between source code and
the deployed package in PyPI as a way to detect malicious injections
in the Python ecosystem. Scalco et al. [
29
] perform the same in the
context of JavaScript. Conversely, we do not consider the source
code.
Duan et al. [
13
] propose a classier based both on dynamic and
static analysis to classify packages in npm, PyPI, and RubyGems.
Among the selected features for the static analysis, they also suggest
considering sensitive APIs and to perform data ow analysis to
highlight dangerous ows.
Ohm et al. [
25
] leverage sandboxes to collect forensic artifacts re-
lated to the execution of malicious JavaScript and Python packages
and describe the observed dynamic behaviors. In another work [
23
]
they propose a clustering model based on signatures produced from
the Abstract Syntax Tree (
AST
) of malicious JavaScript samples.
Our approach is instead only static and focuses on Java.
Garret et al. [
16
] propose an anomaly detection approach based
on the observation of code features in JavaScript (e.g., opening of
connections, read/write to the le system).
Fass et al. [
14
] extract features from the
AST
of JavaScript codes
to build a classier capable of detecting obfuscation.
In the scope of Java malware detection, related works focus on
the detection of malicious code in applets or purely malicious JARs.
Schlumberger et al. [
30
] propose a static approach for applets
based on machine learning. Among the selected features they con-
sider sensitive APIs (e.g., for obfuscation and code behavior). Com-
pared to their work, our focus is on
OSS
packages that may contain
a small portion of malicious code, while malicious applets do not
need to piggyback on existing benign functionalities. In addition,
some of the APIs for applets are not relevant in the scope of Java
libraries (e.g., APIs for MIDlets).
Pinheiro et al. [
28
] propose a dynamic approach for the auto-
mated detection of malicious JARs. They extract forensic features
related to the execution of purely malicious samples in a sandboxed
environment to train a classier based on articial neural networks.
Instead, we perform a static analysis of packages where malicious
code was injected.
Other relevant works come from the Android ecosystem [
10
,
11
,
19
,
20
], especially the ones about the static inspection of Dalvik
bytecode. In this case, Aafer et al. [
9
] analyze Android malware
samples to extract their commonly used APIs, then build a KNN
classier. As opposed to their work, not having many malicious
samples available, our search for relevant APIs is based on the
manual inspection of malicious packages. Specic aspects of the
Android ecosystem make the problem of detecting malicious Java
libraries dierent. On the one hand, because malware running
on mobile devices has dierent objectives, e.g., nancial gain by
sending SMS or reading contacts. On the other hand, there are
technical dierences between Java for Android and for the JVM
(e.g., permissions, intents, or APIs existing only for Android).
3 MOTIVATION
This section motivates our work by presenting
OSS
supply chain
attacks and reports on the detection capabilities of popular An-
tiviruses (AVs).
Reference Year
Ruby
Python
JavaScript
Java∗
Seja et al. [31] 2022 ✓
Scalco et al. [29] 2022 ✓
Duan et al. [13] 2021 ✓ ✓ ✓
Vu et al. [34] 2021 ✓
Ohm et al. [25] 2020 ✓ ✓
Ohm et al. [23] 2020 ✓
Garret et al. [16] 2019 ✓
Fass et al. [14] 2018 ✓
Table 1: Ecosystems covered by recent scientic works on
the detection of malicious open-source packages. (∗): here
we intend the case of JVM bytecode
3.1 Open-Source Software Supply Chain
Attacks
Listing 1: Malicious code snippet from HpServlet.java con-
tained in com.github.codingandcoding:servlet-api@3.2.0
1protected void doG et ( H tt pS er vl e tR eq ue st re q )
2throws Se rv le tE xc ep ti on , IO Excep ti on {
3Ru ntime . getR unt im e ()
4. ex ec ( " bash -c { echo , Y mFz ** S HOR TE NE D ** J jE =}
5|{ b ase6 4 , -d } |{ bas h , - i} " );
6}
OSS
supply chain attacks target open-source components as a
means of spreading malware. As Ladisa et al. [
18
] pointed out, there
are many possible attack vectors.
As demonstrated by multiple examples of malicious
OSS
pack-
ages [
24
], most of them prove to have a small fraction of harmful
code hidden in a bigger corpus of legitimate code. This is similar to
the case of piggybacking in Android malwares, where a legitimate
application (carrier) is repackaged by grafting a malicious code
(rider) [11, 19, 20].
Listing 1 shows the malicious code snippet present in the package
com.github.codingandcoding:servlet-api@3.2.0. Its source version
consists of 149 les, 77 of which are in java format and a total of
13458 Lines Of Code (
LOC
). The malicious payload is present in
only one line of code of the le HttpServlet.java, which consists of
a total of 749 LOC.
3.2 VirusTotal Scan
To understand the level of detection by common
AVs
we submitted
the 2886 samples available in the Backstabber’s Knife Collection
(
BKC
) [
24
] (813 Ruby samples, 261 in Python, 1807 in JavaScript,
and 4 in Java) to VirusTotal
2
(as of July 2022). The latter oers the
possibility to inspect les or hashes with over 70 Antivirus (
AV
)
softwares.
Figure 1 depicts the percentage of responses provided by all the
AVs
accessible through the VirusTotal API. The results show the
average calculated per ecosystem.
2https://www.virustotal.com