PortSwigger Web Security · Report #506161
Build fetches jars over HTTP
Summary
This report was part of a 4 month research project into the general supply chain security of the JVM ecosystem. This vulnerability impacted organizations like the Apache Foundation, Eclipse Foundation, Elastic Search, JetBrains, Jenkins, Oracle, Google, Gradle and many other open source projects including both the Kotlin and Groovy compiler.
The full blog post about this research can be found here: Want to take over the Java ecosystem? All you need is a MITM!
In the case of BurpSuite, this vulnerability impacted the build infrastructure for their TeamCity and Jenkins Integration plugins.
How it was found
CWE-829: Inclusion of Functionality from Untrusted Control Sphere CWE-494: Download of Code Without Integrity Check
PortSwigger maintains several Open Source Projects under the PortSwigger GitHub organization. Some of these projects contain build files that indicate that some of these projects are resolving dependencies over HTTP instead of HTTPS. This allows these artifacts to be potentially MITMed to maliciously compromise them and infect the build artifacts that are produced. Additionally, if any of these JARs or other dependencies were compromised, any developers or production servers using these could continue to be infected past updating to fix this.
Description:
This attack leverages the build infrastructure loading dependencies over HTTP without any other sort of integrity check to allow them to be maliciously compromised.
This isn't just theoretical
POC code has existed since 2014 to maliciously compromise a JAR file inflight. See:
- https://max.computer/blog/how-to-take-over-the-computer-of-any-java-or-clojure-or-scala-developer/
- https://github.com/mveytsman/dilettante
MITM Attacks Increasingly Common
See:
- https://serverfault.com/a/153065
- https://security.stackexchange.com/a/12050
- Comcast continues to inject its own code into websites you visit (over HTTP)
Source Locations
Insecure Download
TeamCity Integration
Jenkins Integration
Insecure Upload
Insecure upload of artifacts is pretty much always accompanied by credentials. Since these credentials are sent over HTTP, they are transmitted in plaintext and should be considered compromised.
Jenkins Integration
Fix and Public Disclosure
At a minimum, all of these code locations where artifacts are downloaded from an untrusted source needs to be fixed. Previous releases should be rebuilt with the fix applied. The checksum of the released artifacts and artifacts built in a trusted environment should be made. If the checksums match, you can be certain that they weren't compromised.
If the checksums don't match, indicating a compromised artifact, CVE numbers need to be issued for the potentially malicious artifacts.
The ability to check if checksums match assume that these projects have reproducible builds.
Steps To Reproduce:
- Cone the Impacted Project
- Change this line in Dilettante so it is targeting the repository used in the build. https://github.com/mveytsman/dilettante/blob/master/dilettante.py#L143
- Start Dilettante on your local machine.
- Proxy the HTTP traffic for the build through Dilettante
- Execute the Build's tests.
- You should be greeted with the image of a cat.
Other Places to Look
Given how widely I'm finding this vulnerability externally, I'd advise that the Port Swigger Security team take some time to also analyze their internal infrastructure for similar vulnerabilities.
This responsible disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy).
Impact
By insecurely downloading code over an untrusted connection HTTP and executing the untrusted code inside of these JAR files as part of the unit/integration tests before a release opens these artifacts up to being maliciously compromised.
Remote code execution on a production server. Malicious compromise of build artifacts.