A number of public and popular libraries that were abandoned but still used in Java and Android applications have been found to be vulnerable to a new software supply chain attack method called MavenGate.
“Access to projects can be hijacked through domain purchases,” Oversecured said in an analysis released last week. “Since most default build settings are vulnerable, it’s difficult to impossible to know if they’re being used.” Execute the attack.」
Successfully exploiting these flaws could allow a malicious actor to hijack artifacts in dependencies and inject malicious code into the application, or worse yet, even compromise the build process via a malicious plug-in.
The mobile security company added that all Maven-based technologies, including Gradle, are vulnerable, and that it has sent reports to more than 200 companies, including Google, Facebook, Signal, Amazon, and others.
Apache Maven is mainly used to build and manage Java-based projects, allowing users to download and manage dependencies (uniquely identified by their groupId), create files and release management.
While the repositories hosting such dependencies can be private or public, attackers can conduct supply chain poisoning attacks against the latter by leveraging obsolete libraries added to known repositories.
Specifically, it involves purchasing an expired reverse domain controlled by the dependency owner and gaining access to the groupId.
“An attacker can assert permissions to a vulnerable groupId via a DNS TXT record in a repository where no account exists to manage the vulnerable groupId,” the company said.
“If the groupId is already registered with the repository, an attacker can attempt to access the groupId by contacting the repository’s support team.”
To test attack scenarios, Oversecured uploaded its own test Android library (groupId: “com.oversecured”), which displays the toast message “Hello World!” to Maven Central (version 1.0), and also uploaded two versions to JitPack , where version 1.0 is a copy of the same library published on Maven Central.
But version 1.1 is an edited “untrusted” copy that also has the same groupId but points to a GitHub repository under its control and claims ownership by adding a DNS TXT record referencing the GitHub username to create Proof of ownership.
The attack then proceeds by adding Maven Central and JitPack to the dependency repository manifest in the Gradle build script. It is worth noting at this stage that the order of declarations determines how Gradle checks dependencies at execution time.
“When we moved the JitPack repository onto mavenCentral, the 1.0 version was downloaded from JitPack,” the researchers said. “Changing the library version to 1.1 causes the JitPack version to be used regardless of JitPack’s position in the repository list. .”
Therefore, an adversary seeking to disrupt the software supply chain could target existing versions of a library by releasing higher versions, or target new versions by pushing lower than legitimate versions.
This is another form of dependency obfuscation attack, where an attacker publishes a malicious package to a public package repository with the same name as the intended package in a private repository.
“Most applications do not check the digital signature of dependencies, and many libraries do not even publish it,” the researchers added. “If an attacker wants to remain undetected for as long as possible, then releasing a new version of the library with the malicious code embedded in it and It makes sense to wait for developers to upgrade.”
Of the 33,938 areas analyzed, 6,170 (18.18%) were found to be vulnerable to MavenGate, allowing threat actors to hijack dependencies and inject their own code.
Sonatype, which owns Maven Central, said the outlined attack strategy was “not feasible due to the automation in place” but noted that it had “disabled all accounts associated with expired domains and GitHub projects” as a security measure.
It also says it resolves a “regression in public key verification” process, making it possible to upload artifacts to repositories using non-public shared keys. It also announced plans to work with SigStore to digitally sign components.
“Ultimately the developer is responsible not only for the security of direct dependencies, but also for the security of transitive dependencies,” Oversecured said.
“Library developers should be responsible for the dependencies they declare and write public key hashes for their dependencies, while ultimately developers should only be responsible for their direct dependencies.”
