Java-Class-Hijack: Software Supply Chain Attack for Java based on Maven Dependency Resolution and Java Classloading

Federico Bono,Frank Reyes,Aman Sharma,Benoit Baudry,Martin Monperrus

2024-08-21

Abstract:We introduce Java-Class-Hijack, a novel software supply chain attack that enables an attacker to inject malicious code by crafting a class that shadows a legitimate class that is in the dependency tree. We describe the attack, provide a proof-of-concept demonstrating its feasibility, and replicate it in the German Corona-Warn-App server application. The proof-of-concept illustrates how a transitive dependency deep within the dependency tree can hijack a class from a direct dependency and entirely alter its behavior, posing a significant security risk to Java applications. The replication on the Corona-Warn-App demonstrates how compromising a small JSON validation library could result in a complete database takeover.

Cryptography and Security,Software Engineering

What problem does this paper attempt to address?

The problem that this paper attempts to solve is the software supply - chain attack problem based on Maven dependency resolution and Java class - loading mechanism in Java projects. Specifically, the author introduces a new software supply - chain attack method - Java - Class - Hijack. It constructs a malicious class with the same name as a legitimate class and takes advantage of the characteristics of Maven's dependency resolution and Java class loaders, so that the malicious class is loaded at runtime, thereby tampering with the behavior of the application.

### Main problems
1. **Class conflict and class - loading order**: Since Maven does not enforce that the Java package ID in a Maven artifact is consistent with the Group ID and Artifact ID during the packaging process, different Maven artifacts can contain classes with the same name. The default Java class loader will preferentially load the class that appears first in the class path, which may cause the malicious class to be loaded before the legitimate class, and then change the behavior of the application.
2. **Concealment**: Malicious classes can be hidden deep in the dependency tree, making it very difficult to detect and prevent such attacks.
3. **Security risks**: This attack can completely change the behavior of the application by tampering with key classes in the dependency library, and even lead to serious consequences such as database takeover.

### Specific implementation of the attack
- **Malicious class construction**: The attacker constructs a malicious class with the same fully - qualified name as the legitimate class.
- **Dependency embedding**: Embed the malicious class into a dependency, ensuring that this dependency appears earlier in the class path than the dependency containing the legitimate class during dependency resolution.
- **Class loading**: Since the Java class loader loads classes in depth - first search (DFS) order, the malicious class will be loaded and executed before the legitimate class.

### Proof - of - concept and actual cases
- **Abstract proof - of - concept**: By constructing a simple example project, it shows how to make the malicious class be loaded preferentially by adjusting the order of dependency declarations.
- **Actual case**: Replicated this attack in the backend service `cwa - server` of the German Corona - Warn - App, showing how to achieve control over the entire database connection layer by tampering with a small JSON validation library (everit - json - schema).

### Summary
This paper reveals the security risks in Java project construction and dependency management by introducing the Java - Class - Hijack attack, and proposes several possible mitigation measures, such as using the Maven Enforcer Plugin, sealing JAR files, and adopting the Java modular system.