On June 10th, 2019 I publicly disclosed an industry-wide vulnerability impacting the Java ecosystem in an article titled ‘Want to take over the Java ecosystem? All you need is a MITM!’ In that article, I detailed how many of the most popular JVM based libraries were resolving their dependencies via their build tool over HTTP instead of HTTPS.
As a part of this research, I reached out to the security teams of several of the Java ecosystem’s most used artifact servers, and on January 15th, 2020 many of these artifact servers will drop support for HTTP in favor of only supporting HTTPS. It’s important to remember that as of June 2019, 25% of Maven Central downloads were still using HTTP. …
Over 6 years ago I was working on a project called WPILib. WPILib is a library used by High School FIRST Robotics teams to program their robots. This particular year, the development team decided to use MDNS to resolve the IP address of the robot. When tested, everything worked for the devs so they moved forward with using it.
I joined the team at the beginning of the summer between my Sophomore and Junior year of college and was using a Mac for development. …
As far as I can tell this vulnerability also impacts Ringcentral. Ringcentral for their web conference system is a white labeled Zoom system.
According to Zoom, they will have a fix shipped by midnight tonight pacific time removing the hidden web server; hopefully this patches the most glaring parts of this vulnerability. The Zoom CEO has also assured us that they will be updating their application to further protect users privacy.
If you have updated Zoom to the latest version, you are now greeted with this new UI confirming you would actually like to join the meeting. …
What started as a simple vulnerability report for a small project, quickly unearthed an industry-wide security vulnerability impacting huge swaths of the Java Virtual Machine (JVM) development ecosystem.
This work builds off of the excellent 2014 writeup by Max Veytsman titled: “How to take over the computer of any Java (or Closure or Scala) Developer”.
Back in 2014, when it was published, the Maven Central Repository, run by Sonatype, didn’t support SSL (HTTPS) for serving JAR files. Thanks to Max’s writeup, Sonatype fixed this within only a few days. I highly recommend that you at minimum skim his writeup before continuing. …
This Article is an addendum to Want to take over the Java ecosystem? All you need is a MITM!
A natural question might be, “Why should I care if one of my dependencies builds could have been compromised by a MITM? Their build isn’t running in my production environment! I’ve got nothing to worry about, right?” What this fails to recognize is that any malicious code being executed in the same environment as a library is being produced can be used to compromise that library.
Using the assumption that a malicious actor can compromise a JAR file in flight to a build server being used to build and publish a library; how could we use this to compromise the end user? …
Responsible Disclosure: October 22nd, 2018
Vulnerabilities Patched: October 31st, 2018
Disclosure Published: January 9th, 2019
Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker. …
Responsible Disclosure: September 6th, 2018
Exploit Patched: October 18th, 2018
The exploit stems from the ability to publish artifacts with group names that your Gradle account shouldn’t be able to publish to.
The group id for this plugin is
gradle.plugin at the beginning is added by Gradle).
Due to a bug in the Gradle Plugin Portal, a malicious actor could set their plugin’s group id to the same group id as any plugin already on the portal and publish malicious plugins under a group they shouldn’t own. The malicious actor could not overwrite existing versions of artifacts, but they could publish newer versions. When a user is using a wildcard version for their dependency the newest version of the plugin (which is now malicious) would be downloaded by Gradle the next time the user runs their build. …