Sonatype Nexus Repository Manager Critical Vulnerabilities Advisory

Sonatype Nexus Repository
1

Date: March 23, 2020
Affected Versions: Nexus Repository Manager 3.x up to and including 3.21.1
Fixed in Version: 3.21.2

Multiple vulnerabilities have been discovered in Nexus Repository Manager 3, including one which allows remote code execution by any user, including anonymous users. We have mitigated the vulnerabilities in version 3.21.2.

We recommend all instances of NXRM 3.x upgrade to 3.21.2 or later as soon as possible.

Groovy Scripting Disabled by Default:
As part of making Nexus Repository Manager more secure, we have disabled (by default) the ability for users to create or modify Groovy scripts via REST or scheduled task. For more information about this specific change please see this support article.

Credit:
The vulnerabilities were discovered and reported by Github Security Lab team member @pwnster (Alvaro Muñoz).

Frequently Asked Questions:

Q: What is the risk associated with this vulnerability?

A: NXRM can be compromised, allowing an attacker to use the flaw to execute code outside the scope of the NXRM server.

Q: What preconditions must be met in order to be vulnerable?

A: An attacker must have network access to the Repository Manager instance, as well as a user account access to the Repository Manager to send the malicious request.

Q: Are there implications associated with this advisory itself?

A: Disclosure unfortunately means bad actors may try to take advantage. While we have initially limited the information to the minimum details necessary for users to affect an appropriate fix, this merely slows down a would be attacker. As such, we are advising all organizations utilizing Nexus Repository Manager to immediately assess their individual impact and take appropriate action in response.

Q: Where can I obtain more information associated with the vulnerability?

A: At this time, and in the interest of best protecting our user community, we are limiting the information released to that absolutely required in order to assess impact and affect remediation.

Q: Why is Sonatype making this information available?

A: This is part of a responsible disclosure process. Given NXRM is an open source project with widespread usage, notifying the user base will invariably lead to broad dissemination. We are taking a concerted and proactive approach in our outreach activities and an effort to achieve the most rapid remediation possible.

2

Hello
While I understand the security risk running an outside script against the Nexus API can pose… I’m not sure if the Rest API is up to par wrt provided functionality.
Namely, my colleagues and I are relying on:

  • blobStore.blobStoreManager.exists
  • blobStore.createFileBlobStore
  • blobStore.getBlobStoreManager().delete
  • repository.repositoryManager.exists
  • repository.createProxy
  • repository.configureDockerAttributes
  • repository.createRepository
  • repository.createMavenProxy
  • repository.createNpmProxy
  • repository.getRepositoryManager().update
  • repository.getRepositoryManager().get
  • repository.getRepositoryManager().get("string").getConfiguration
  • repositoryManager.browse().collect
  • repositoryManager.delete
  • security.securitySystem.listRoles().collect
  • security.addRole
  • security.securitySystem.searchUsers
  • security.setAnonymousAccess
  • security.securitySystem.getUser
  • security.securitySystem.updateUser

to provision a Nexus instance, we send over the script (using the Rest API), and Nexus is all setup for our needs; think Jenkins Config as Code in a way.

Last time we checked (6 months ago) most of the API that we needed was not available via the Rest API; so we had to use the scripting API.

Now having a look at what 3.21.2 offers (a lot of beta API, hoping it remains in future versions), the situation has much improved; but still, I’m not sure things like:

  • blobStore.blobStoreManager.exists
  • security.setAnonymousAccess
  • repository.repositoryManager.exists
  • repository.getRepositoryManager().get("string").getConfiguration

can be done or reworked using solely the Rest API.

Anyway, here is our feedback on this move; we wished something like Jenkins Config as Code was available to bootstrap new Nexus instance; we thought scripting API was a good replacement (if only we could keep that one, not using the rest API, but telling Nexus to load from local filesystem instead), but apparently not.

Thank you for considering those aspects.

1 Like
3

@anthonydahanne Thanks for your feedback; I agree that the REST API doesn’t cover all of your use cases.

If your situation is that the NXRM administrator can be trusted to have the same access as the underlying OS account that runs NXRM, there’s no problem in re-enabling the groovy scripting, as described in our knowledge base article.

1 Like
4

Further to that, @anthonydahanne, do look at a few endpoints that may let you cover the uses cases you identified as gaps. These aren’t 1:1 replacements, but I believe these endpoints contain the information you’re consuming:

/beta/blostores (which will tell you if blob stores exist)
/v1/repositories (which will tell you if repositories exist, and their configuration)

5

If we look at the same problem from a different angle… all we need is to provision a nexus instance with some initial seed configuration, so that we don’t have to do it manually. Using groovy scripts or REST API for that is rather clumsy, and it requires Nexus admin credentials too. A much better option would be a way to supply some bootstrap YAML or CasC configuration, which would be picked up by Nexus on the first run and applied before bringing the Nexus instance online. That way, we’d only need to mount a config file (or a kubernetes config map) into Nexus container.

Looking for something similar, I have just stumbled across this: GitHub - sventschui/nexus-casc-plugin: Configuration as code plugin for Sonatype Nexus Repository Manager . I wonder if there’s any plans to add anything like that into the core product?

1 Like