Sonatype Disables Unencrypted Access to Maven

Sonatype has disabled the ability to download Java dependencies from Maven Central over unencrypted HTTP, helping secure the software supply chain against injection attacks. The change also incorporates verification of Maven’s certificate to safe-guard against man-in-the-middle (MITM) attacks.

Many software build systems in the Java ecosystem, including Maven, Gradle, and SBT rely on Maven Central as a means for locating and downloading software dependencies. The switch to fully require HTTPS was announced by Sonatype product manager Terry Yanko and Gradle engineer Jonathan Leitschuh.

The work performed by Leitschuh builds upon work that was started in 2014, when Sonatype enabled SSL access to the Maven repository. At that time, Max Veytsman had created a write-up and tool explaining how to back-door JAR files coming from Maven as they went over a network. As a result of this attack, systems would unknowingly work with the artifact that they had downloaded. The code artifacts, however, could be modified in transit through a simple process that no longer functions as a result of Sonatype’s change.

1. A custom proxy server would capture items coming from Maven Central.
2. The proxy would analyze the incoming artifact as a ZipInputStream.
3. As it detected the binary of a ZipEntry, the proxy would pass the input to a Java bytecode library, such as ASM.
4. The custom ASM ClassVisitor would add or alter specific class’ methods, such as the static initializer method, <clinit>()V, to add custom bytecode that took action such as executing a system command.
5. The proxy would re-zip all contents into a ZipOutputStream that was passed through to the client.
6. The build system and/or any system that loaded or ran the back-doored classes would execute the payload that was put in place by the proxy server.

The risk required a MITM attack, and was not a vulnerability in Maven or Java itself. Exploitation examples were performed in lab environments and there is no known attack on the Java/Maven ecosystem that leveraged this bytecode injection attack. Large-scale attacks on network routes require significant effort by organizations with significant skill, funding, and access. Within the same time period, Trend Micro’s annual 2014 vulnerability analysis cited positive Java security improtements "Some good news - there were no Java zero-days in 2014!"

"Fortunately, application security transitioned from a single activity prior to release, to a holistic quality process applied throughout the development lifecycle. Improving supply chain security begins by each of us improving our own product security," explains Milton Smith, principal at AppSec Alchemy. In 2014, Smith was a product manager in Oracle’s Java Platform Group.

For users who require unencrypted HTTP access, Sonatype has created a workaround that enables systems to still function. Older systems that cannot be updated to recent maven versions can simply switch their download URLs from repo.maven.org or repo1.maven.org to insecure.repo1.maven.org. Sonatype has placed the word insecure into the hostname as a way of clearly communicating that making this change is an unambiguous security problem. Organizations with security controls can also choose to block or flag hosts that access this URL to balance between the build continuing to function and bocking potentially insecure downloads.