Dropbox uses vulnerable dependencies, supply chain attacks possible

Hey,

I wasn't able to report this security vulnerability via the only given channel on BugCrowd. The BugCrowd triage team [said](https://bugcrowd.com/submissions/bbddd1d9-bc6b-4dee-93df-17c4532d9820) 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](https://blog.oversecured.com/Introducing-MavenGate-a-supply-chain-attack-method-for-Java-and-Android-applications/) 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](https://github.com/dropbox/DropboxBusinessScripts/files/14111280/EVIL_REPO.zip), unzip it, and add its path to the `~/.m2/settings.xml`, in my case it looks as follows
```xml

${user.home}/.m2/repository


mainProfile


EVIL_REPO
EVIL_REPO
file:///Users/me/Downloads/EVIL_REPO/


central
central
https://repo.maven.apache.org/maven2/





mainProfile

```
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.