Dropbox uses vulnerable dependencies, supply chain attacks possible

Sharing/ListSharedFolders-pom.xml から始めて、com.opencsv:opencsv:3.4 依存関係とそのリポジトリ設定を調査します。安全なテスト環境で、提供されたローカルリポジトリのみを使用して、文書化されている Maven コマンドを実行します。その後、依存関係の変更後にビルドされた jar に報告された脆弱なアーティファクトが含まれていないことを確認します。

Hey,

I wasn't able to report this security vulnerability via the only given channel on BugCrowd. The BugCrowd triage team said that Dropbox OOS isn't in scope and those projects are too old, so such vulnerabilities cannot be reported via that platform. The only place where I can report is here.

Description

This project and dropbox/mypy-pycharm-plugin are vulnerable to MavenGate supply chain attack. There are the following vulnerable dependencies:

Group ID: com.opencsv, domain available for registration: opencsv.com

• https://github.com/dropbox/dropboxbusinessscripts/blob/master/Sharing/ListSharedFolders-pom.xml

Group ID: org.ini4j, domain available for registration: ini4j.org (however, this project uses only Maven Central repository, so see comments below)

• https://github.com/dropbox/mypy-pycharm-plugin/blob/master/build.gradle

The attack looks as follows:

1. An attacker can take over groupId values on public repositories because they all require DNS TXT verification (this is verified for MavenCentral, JitPack, and Gradle). This verification is possible when an attacker can purchase the domain.
2. Additionally, this attack isn't possible automatically for MavenCentral. If the groupId value is registered in their system, they require manual verification, as they say: "Any future attempts to leverage current and future expired domains will undergo a thorough assessment by our team, ensuring evidence of ownership of not just the domain but also the underlying project".
3. So now we have all other public repositories left. When the verification is complete, an attacker can upload any artifacts they want to the owned groupId.

Reproduction Steps

I'm providing an attack example for this project that includes vulnerable com.opencsv:opencsv:3.4. The opencsv.com domain can be purchased:

To avoid purchasing the domain and breaking the CI/CDs of other developers, I created a local repository to demonstrate the attack. So to reproduce the attack using a local repository, do the following:

1. Download EVIL_REPO.zip, unzip it, and add its path to the ~/.m2/settings.xml, in my case it looks as follows

<?xml version="1.0" encoding="UTF-8"?>
<settings xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.2.0 http://maven.apache.org/xsd/settings-1.2.0.xsd" xmlns="http://maven.apache.org/SETTINGS/1.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <servers>
    </servers>
    <localRepository>${user.home}/.m2/repository</localRepository>
    <profiles>
        <profile>
            <id>mainProfile</id>
            <repositories>
                <repository>
                    <id>EVIL_REPO</id>
                    <name>EVIL_REPO</name>
                    <url>file:///Users/me/Downloads/EVIL_REPO/</url>
                </repository>
                <repository>
                    <id>central</id>
                    <name>central</name>
                    <url>https://repo.maven.apache.org/maven2/</url>
                </repository>
            </repositories>
        </profile>
    </profiles>
    <activeProfiles>
        <activeProfile>mainProfile</activeProfile>
    </activeProfiles>
</settings>

2. git clone https://github.com/dropbox/DropboxBusinessScripts
3. cd DropboxBusinessScripts/Sharing
4. mvn clean compile assembly:single --file ListSharedFolders-pom.xml. The build will generate the DropboxBusinessScripts/Sharing/target/ListSharedFolders-0.0.1-jar-with-dependencies.jar runnable jar which will be poisoned. To verify that, decompile the file or unzip it:
   

So the conclusion things:

1. Injecting the evil.Evil class is an example, an attacker can modify sources of this library in any way too.
2. The root problem of MavenGate is repositories. It's typical to have a few of them when building a project. When an attacker uploads artifacts to a public one that is included in the project (or declared in ~/.m2/settings.xml in the case of Maven), it will lead to artifact poisoning when attacking dependencies.
3. The common fix would be avoiding the use of vulnerable dependencies.