💾 Archived View for lists.sh › eke › resurrection-attacks captured on 2022-07-16 at 13:55:06. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Service Resurrection Attacks

01 Jun, 2022

on eke's (b|g)llog

---

What are the facts?

A service resurrection attack is when access to a dead service, such as an expired domain or other abandoned resource, grants some degree of access or(or perceived access) to another resource.
In Maven Central, software packages and related artifacts are organized into namespaces (referred to as groupId).
The Java convention is to use domain names as part of the namespace.
Maven Central requires a proof of namespace control in order to register or recover publish access to a namespace.
There are two types of proof that are currently accepted.
One type of proof is ability to add a DNS record to the domain.
Another type of proof is to create a public SCM repository.
About 80% of all new projects use a public SCM URL as the type of proof.

Maven Central coordinate reference

Software packages and related artifacts are published once to Maven Central - they are unable to be altered by publishers after they have been published.

Why is this important?

A bad actor may be able to introduce malicious code into other software applications.

How?

An SCM organization/account or DNS settings can be modified by a bad actor.
The bad actor requests and receives publish access to Maven Central by demonstrating proof of namespace control.
New versions of an existing software packages can be published to that namespace.
Any software applications which 1) depend on the latest version of the existing software package; and 2) are rebuilt may execute the malicious code.

Examples

A claimed (but unsubstantiated) takeover in the Javascript / NPM ecosystem.

Reasons this is not a really big deal

The risk is generally very low: best practice for Java applications is to specify versions for dependencies. If this is the case, then a newer version of dependencies will not be incorporated into an application.
Maven Central provides other information, such as PGP signatures, which allows users to validate provenance of software packages they depend on.
Maven Central provides assertions about control over a namespace and other information about software packages it hosts. But there are no implied guarantees about code quality or suitability to purpose of these packages: it is the responsibility of downstream quality and security toolchains to make this determination.

What might be done?

If a revalidation of namespace occurs, Maven Central can make this information readily accessible to downstream quality & security toolchains.
Maven Central can lock namespaces following a period of inactivity, and require revalidation in order to reuse it. Note this does not prevent a bad actor who controls the namespace from revalidating it.
Better determine the scope of the problem. For instance, what percentage of packages in Maven Central published in the last 3 years include dependencies without valid, semantic version information? How many revalidations are performed on an annual basis? How many expired domains are associated with active namespaces?

---

published with lists.sh