Various libraries public and popularabandoned but still used in Java and Android applications, were found to be vulnerable to a new supply chain attack method (or supply chain) software called MavenGate.
What we know about the MavenGate method
“Access to projects can be hijacked through purchasing domain names and since most default build configurations are vulnerableit would be difficult or even impossible to know if an attack is underway“, has stated Oversecured in an analysis published last week regarding the MavenGate method.
Successfully exploiting these loopholes could allow various attackers to hijack artifacts in dependencies and inject malicious code into the application, and worse, even compromise the compilation process through a malicious plugin.
The mobile security company added that all Maven-based technologies, including Gradle, are vulnerable to the attack, and that it has sent reports to over 200 companies, including Google, Facebook, Signal, Amazon and many others.
Apache Maven (hence the name MavenGate) is mainly 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 manage releases.
While the repositories hosting such dependencies can be private or public, an attacker using the MavenGate method could target the latter to conduct supply chain sabotage attacks by exploiting abandoned libraries added to known repositories.
In particular, this entails the purchase of reverse dominance expired checked by the dependency owner and gaining access to the groupId.
“An attacker can gain access to a vulnerable groupId asserting your rights via a DNS TXT record in a repository where there is no account managing the vulnerable groupId“, the company said, adding: “If a groupId is already registered in the repository, an attacker can attempt to gain access to that groupId by contacting the repository's support team.”.
To test the attack scenario, Oversecured uploaded its Android test library (groupId: “com.oversecured”), which displays the “Hello World!” toast message, to Maven Central (version 1.0), 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 a modified “untrusted” copy that has the same groupId, but which points to a GitHub repository under their control and is claimed by adding a TXT DNS record to reference the GitHub username in order to establish the proof of ownership.
The attack then works by adding both Maven Central and JitPack to the list of dependency repositories in the Gradle build script: it is therefore important to note at this stage that the order of declaration determines how Gradle will check dependencies during execution.
“When we moved the JitPack repository over to mavenCentral, version 1.0 was downloaded from JitPack“, the researchers said, and then added that “changing the library version to 1.1 resulted in using the JitPack version regardless of JitPack's position in the repository list“.
As a result, an adversary trying to corrupt the program supply chain via the MavenGate method It can target either existing versions of a library by pushing a higher version or new versions by pushing a lower version than its legitimate counterpart.
This is another kind of “confusion attack” of the dependencies in which an attacker publish a fake package to a public package repository with the same name as a package within the intended private repository, basically a method very similar to phishing or ransomware with fake files or links.
“Most applications do not verify the digital signature of dependencies, and many bookstores don't 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 update it“.
Of the total 33,938 domains analyzed, 6,170 (18.18%) of them were found to be vulnerable to MavenGate, allowing cybercriminals to hijack dependencies and inject their own code.
Sonatype, owner of Maven Central, has declared that the attack strategy outlined “it is not feasible due to the automation taking place“, but then made it known that he had “disabled all accounts associated with expired domains and GitHub projects” as a security measure.
He further stated that he faced a “regression in public key validation” That made it possible to upload artifacts to the repository with a key that was not publicly shared and has also announced plans to collaborate with SigStore For digitally sign the components.
“The front-end developer is responsible for the safety of not only direct dependencies, but also transitive dependencies“Oversecured said, adding “library developers should be responsible for the dependencies they declare and should also write the public key hashes for their dependencies, while the front-end developer should only be responsible for his direct dependencies“.
#MavenGate #Vulnerabilities #older #Java #Android #libraries
