Several public and popular libraries abandoned but still used in Java and Android applications have been found susceptible to a new software supply chain attack method called MavenGate.
"Access to projects can be hijacked through domain name purchases and since most default build configurations are vulnerable, it would be difficult or even impossible to know whether an attack was being performed," Oversecured said in an analysis published last week.
Successful exploitation of these shortcomings could allow nefarious actors to hijack artifacts in dependencies and inject malicious code into the application, and worse, even compromise the build process through a malicious plugin.
The mobile security firm added that all Maven-based technologies, including Gradle, are vulnerable to the attack, and that it sent reports to more than 200 companies, including Google, Facebook, Signal, Amazon, and others.
Apache Maven is chiefly used for building and managing Java-based projects, allowing users to download and manage dependencies (which are uniquely identified by their groupIds), create documentation, and release management.
While repositories hosting such dependencies can be private or public, an attacker could target the latter to conduct supply chain poisoning attacks by leveraging abandoned libraries added to known repositories.
Specifically, it involves purchasing the expired reversed domain controlled by the owner of the dependency and obtaining access to the groupId.
"An attacker can gain access to a vulnerable groupId by asserting their rights to it via a DNS TXT record in a repository where no account managing the vulnerable groupId exists," the company said.
"If a groupId is already registered with the repository, an attacker can attempt to gain access to that groupId by contacting the repository's support team."
To test out the attack scenario, Oversecured uploaded its own test Android library (groupId: "com.oversecured"), which displays the toast message "Hello World!," to Maven Central (version 1.0), while also uploading two versions to JitPack, where version 1.0 is a replica of the same library published on Maven Central.
But version 1.1 is an edited "untrusted" copy that also has the same groupId, but which points to a GitHub repository under their control and is claimed by adding a DNS TXT record to reference the GitHub username in order to establish proof of ownership.
The attack then works by adding both Maven Central and JitPack to the dependency repository list in the Gradle build script. It's worth noting at this stage that the order of declaration determines how Gradle will check for dependencies at runtime.
"When we moved the JitPack repository above mavenCentral, version 1.0 was downloaded from JitPack," the researchers said. "Changing the library version to 1.1 resulted in using the JitPack version regardless of the position of JitPack in the repository list."
As a result, an adversary looking to corrupt the software supply chain can either target existing versions of a library by publishing a higher version or against new versions by pushing a version that's lower than that of its legitimate counterpart.
This is another form of a dependency confusion attack where an attacker publishes a rogue package to a public package repository with the same name as a package within the intended private repository.
"Most applications do not check the digital signature of dependencies, and many libraries do not even publish it," the researchers added. "If the attacker wants to remain undetected for as long as possible, it makes sense to release a new version of the library with the malicious code embedded, and wait for the developer to upgrade to it."
Of the 33,938 total domains analyzed, 6,170 (18.18%) of them were found to be vulnerable to MavenGate, enabling threat actors to hijack the dependencies and inject their own code.
Sonatype, which owns Maven Central, said the outlined attack strategy "is not feasible due to the automation in place," but noted that it has "disabled all accounts associated with expired domains and GitHub projects" as a security measure.
It further said it addressed a "regression in the public key validation" process that made it possible to upload artifacts to the repository with a non-publicly shared key. It has also announced plans to collaborate with SigStore to digitally sign the components.
"The end developer is responsible for security not only for direct dependencies, but also for transitive dependencies," Oversecured said.
"Library developers should be responsible for the dependencies they declare and also write public key hashes for their dependencies, while the end developer should be responsible only for their direct dependencies."
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.