Who’s Vulnerable?

Long story short; some of the most popular JVM based projects on GitHub were or still are vulnerable.

Note: Projects marked ‘Done’ as ‘TRUE’ have completely fixed the issue and have either audited or have a CVE number issued for their previous releases.

Here’s a direct link to the Google Sheets for those who are interested.

In addition to the projects listed above, there are some big communities and organizations that this vulnerability also impacted.

Minecraft Modders

This was the first place I began looking and was unsurprised to immediately start finding this vulnerability in the build infrastructure in almost all of the Minecraft mods I looked at.

JetBrains

Thinking that there was a chance that the Ktor incident wasn’t just a one-off incident, I started looking at the JetBrains GitHub projects.

Kotlin Compiler

Kotlin is a programing language developed by JetBrains that compiles to the JVM, LLVM, and Javascript. It has gained significant popularity with Android developers. Google has recently designated that Kotlin is now the preferred language for Android development.

I found multiple instances across the Kotlin compiler codebase where the build infrastructure and tests were downloading dependencies over HTTP. Not only were the Kotlin compiler’s source dependencies vulnerable, but vulnerable repositories were also used for the Gradle buildscript classpath leaving open the potential for release artifacts to have been compromised. If this weren’t bad enough, the buildscript classpath was also used to resolve the previous version of the Kotlin Compiler thus leaving the compiler open to the ‘Trusting Trust’ attack (see more on this below).

IntelliJ IDEA

Not only was IntelliJ and several of the official plugins vulnerable to this, but there were many cases where the code generators for creating starter projects with IntelliJ generated projects that are vulnerable.

Gradle

Gradle was an interesting case. As a contributor to Gradle, you would not have been impacted by this vulnerability, however, when Gradle was used to build the Gradle repository on Gradle Inc’s Team City CI infrastructure, that infrastructure overrode the defaults to instead use a corporate JFrog Artifactory instance that served artifacts over HTTP. Thankfully, this infrastructure is colocated on the same network as the Gradle JFrog Artifactory server.

That being said, the Gradle corporate JFrog Artifactory server was mirroring other artifact servers over HTTP thus potentially exposing those mirrors to a MITM based cache poisoning attack.

Elastic Search

As of writing this, the Elastic Search repository has 38.6k stars, thus making it the most stared Java-based project on GitHub. The main Elastic Search project has had over 1.1k contributors. The test logic in the Elastic build was determined to be vulnerable to this.

Apache

I found this vulnerability in several of the Apache Software Foundation projects. The notable ones are listed below.

As of the publication date of this article, the Apache Software Foundation has decided not to issue CVE numbers for the impacted projects even though, in most cases, no audit was performed to determine if these projects were maliciously compromised by this vulnerability.

Groovy Compiler

Apache Groovy, one of the most popular alternatives for developing for the JVM was also found to be vulnerable to this. As of writing this, Groovy is the 19th most popular programing language in the world according to the Tiobe index. Similar to Kotlin, the Groovy compiler’s buildscript classpath had dependencies resolved over HTTP. This also left open the potential for release artifacts to have been compromised.

Thankfully, the Groovy compiler is built with a bootstrap compiler written entirely in Java, thus making the potential for the ‘Trusting Trust’ attack very small.

Additionally, the Groovy-Eclipse Plugin was also found to be vulnerable.

Hadoop

Apache Hadoop has over 193 contributors, making it the project with the most contributors. All of those contributors who ran the Hadoop build on their machines could have been compromised by a MITM.

Kafka

Apache Kafka was originally written by the LinkedIn team to be a fast Event Broker. LinkedIn has used Kafka internally to ingest over 1 trillion messages per day. I found that Kafka’s build system was loading Gradle Plugins over HTTP instead of HTTPS.

Other Apache Projects

The list of Apache projects that I found that were vulnerable include but are not limited to the following: Casandra, Geode, Storm, Bigtop, Fink, OpenJPA, Royal Compiler & Airavata.

Jenkins

Over 1,000,000 Jenkins users worldwide make Jenkins the most widely-used, open source automation server.

- Jenkins Community Announces Record Growth and Innovation in 2017

Jenkins is used as a self-hosted CI pipeline to automate building and testing software.

Jenkins and many of the Jenkins official plugins all ships with dependencies that were downloaded over HTTP.

Spring

The first location that I found was in the spring-security-oauth project. The Spring project was the first Maven based project I started looking at, forcing me to establish a whole different search methodology for inspecting Maven POM files with the GitHub search functionality. Once I started looking, I found that this vulnerability existed in many of the other projects under the Spring organization.

The Spring Team responded immediately to the vulnerability and began patching all of their projects. Due to the overwhelming number of Pivotal projects impacted, Pivotal developed a tool to find and replace all uses of HTTP across the repository. That tool can be found here:

Red Hat

This vulnerability also impacted many projects maintained by Red Hat. These projects include but are not limited to Hibernate ORM, RestEasy and many projects in the Wildfly (formerly JBoss) ecosystem.

Eclipse Foundation

Similar to Red Hat & Apache Foundation, this also impacted the Eclipse Foundation projects Vorto, Buildship, xtext, Orion & Birt.

Oracle

This vulnerability additionally impacted a few of Oracle’s open source projects including VisualVM, PGQL, OpenGrok & Helidon.

Testing Libraries and Frameworks

A few very popular JVM testing libraries and frameworks were also vulnerable to this including TestNG, Spock & PowerMock.

Other Projects

Other projects this vulnerability was discovered in include Grails, the Scala module for FasterJacksonXML & Ehcache3. Additionally, I found this vulnerability in the Open Source projects of Netflix, Google, Twitter, the National Security Agency (NSA), Stripe, Gluon (Scene Builder) PortSwigger, Black Duck, Snyk, LinkedIn, and PayPal. Ironically, when this was reported to PayPal’s security team, they closed it as they consider MITM attacks ‘out of scope’ for their HackerOne program.