Avast uses vulnerable dependencies, supply chain attacks possible

[bagipro]

Hey,

I wasn't able to report this security vulnerability via the only given channel on BugCrowd. The BugCrowd triage team said that Avast OOS isn't in scope and such vulnerabilities cannot be reported via that platform. So the only place where I can report is here.

Describe the bug

This project, avast/sst-seed.g8 and avast/gcp4cats are vulnerable to MavenGate supply chain attack. There are the following vulnerable dependencies:

Group ID: org.tpolecat, domain available for registration: tpolecat.org

• https://repo.maven.apache.org/maven2/com/avast/sst-doobie-hikari_3/0.18.4/sst-doobie-hikari_3-0.18.4.pom
• https://github.com/avast/scala-server-toolkit/tree/master/project/Dependencies.scala
• https://github.com/avast/sst-seed.g8/tree/master/src/main/g8/project/Dependencies.scala

Group ID: co.fs2, domain available for registration: fs2.co

• https://repo.maven.apache.org/maven2/com/avast/clients/rabbitmq/rabbitmq-client-api_2.13/9.4.4/rabbitmq-client-api_2.13-9.4.4.pom
• https://github.com/avast/rabbitmq-scala-client/blob/master/api/build.gradle
• https://github.com/avast/gcp4cats/tree/main/project/Dependencies.scala

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.

To Reproduce

I'm providing an attack example for this project (com.avast:sst-doobie-hikari_3:0.18.4) that includes vulnerable org.tpolecat:doobie-core_3:0.13.4. However, before the article was released, tpolecat.org and fs2.co were available for registration, but looks like they were purchased on Jan 19th and Jan 18th accordingly:

It could be a sign of an ongoing attack or a vulnerable company to MavenGate decided to secure themselves that way.

Check the attached Avast_PoC.zip, there is the project structure:

1. It's a Maven-based project, but it would be absolutely the same if using Gradle.
2. It directly includes only the com.avast:sst-doobie-hikari_3:0.18.4 dependency.
3. com.avast:sst-doobie-hikari_3:0.18.4 includes vulnerable org.tpolecat:doobie-core_3:0.13.4 which is placed to EVIL_REPO/. I've modified its jar and simply added the evil.Evil class.

When you run mvn clean package, it will fetch the infected artifact. After the build finishes, you will see the target/poc-1.0-jar-with-dependencies.jar that will include the dependencies (a typical runnable jar includes dependencies). After you decompile or unzip it, you will see the poisoning effect:

Additional context

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.

[jakubjanecek]

Hello, thank you for your report.

The way I understand it we can't really do anything about this. We could only stop using affected dependencies which doesn't make much sense as this library is about wrapping and improving those external dependencies. We are "just a messenger" in this. Even if we stopped including them I don't think our users would actually stopped using them as both doobie and FS2 are well-known and often used libraries.

[bagipro]

Hey @jakubjanecek,

I think adding signature verification would solve the problem.

Thanks!