Description

Dependency-Track allows administrators to configure custom package repositories,
which it uses to lookup version information about software components, e.g. their latest version.
To facilitate the usage of internal and/or private repositories, it is further possible to configure credentials for authentication.

Administrators can configure patterns to mark certain components as internal.
Information about internal components is supposed to not be sent to 3rd party services, including public package repositories.
They will however be sent to configured repositories that were explicitly marked as internal.

Interactions with repositories for .NET packages are performed using the NuGet Server API.
The API is based on a single entry point (the service index), from which resources provided by the API are linked.
Dependency-Track specifically relies on the PackageBaseAddress resource for its version lookups.
According to the NuGet API specification, repository servers are required to provide this resource.

Some servers implementing the NuGet API turned out to not provide the PackageBaseAddress resource
in their service index. This caused Dependency-Track to fall back to its default, which points to the public NuGet repository api.nuget.org. However, if authentication credentials were configured, they were still used.

Impact

• Dependency-Track may send credentials meant for a private NuGet repository to api.nuget.org via the HTTP Authorization header.
• Dependency-Track may disclose names and versions of components marked as internal to api.nuget.org.

Preconditions:

• The Dependency-Track instance contains .NET components.
• A custom NuGet repository has been configured.
• The custom repository has been configured with authentication credentials.
• The repository server does not provide PackageBaseAddress resource in its service index.

The vulnerability has originally been reported in combination with usage of JFrog Artifactory as NuGet server.

Patches

The issue has been fixed in Dependency-Track 4.13.5.

Workarounds

• Disable custom NuGet repositories until the patch has been applied.
• Invalidate the previously used credentials.
• Generate new credentials for usage after the patch has been applied.

Credit

Thanks to Colin Fyfe (@colinfyfe) for responsibly disclosing and fixing the issue.